Running a HALO product development team(blog.tallhamn.com) |
Running a HALO product development team(blog.tallhamn.com) |
Twice now, I've witnessed a roomful of highly skilled, intelligent people scratching their heads and shouting over each other trying to accomplish simple tasks with Asana. There's an excess of terminology, an even bigger excess of features, and a serious mental mismatch between "the Asana way" and just organizing some information within a team.
On the other hand, https://trello.com/ is an absolute delight.
Hell, the article even goes on to explain how to shoehorn a Kanban board in to Asana. Meanwhile, Trello essentially is a Kanban board.
As a user of Asana, this is strange for me to read. What did they argue over? Asana has projects, and you put tasks within the projects. If you want you can use sub-headings to separate things within a project. How is that complex?
Asana has actually been the one project/task management tool that I've stuck with. In contrast to you, I'm baffled how anybody manages to use Trello productively. Different tools for different people I guess.
People argued over whether or not a particular sub-project should be a project or a section. People argued over when to use sections vs when to use tags. People were uncomfortable creating "tasks" for things that don't have a singular notion of "done". People argued over when to use subtasks vs top level tasks. It was just silly.
Ignoring my complaints about Asana's UI/UX, simply choosing more abstract words, such as "boards" and "cards" alleviates a great deal of cognitive dissonance when creating organizational systems for new teams and domains to be organized.
Joel wrote a great article about how this sort of thinking leads to a very different product design, and Trello's approach specifically: http://www.joelonsoftware.com/items/2012/01/06.html
Also, I can't see the project that the various tasks are in, so all I have is a giant group of tasks without any organization or context.
It's not that these are insurmountable issues, but I can't imagine a situation where I would want to assign a task to someone but hide from them the tags and project.
Personally, I think it's harder to get an overview of what's going on in Trello - especially on a small screen. I also think it's too complicated to move things around in Trello, and that the structure doesn't lend itself well to things that are not processes/pipelines.
In the end, the tool is just there to support the principles/processes that are there to support the people. Hope you got something out of the article that you can use in your tool of choice!
We have one project called Kanban board, with all the features for web, iPhone and Android app (8 people use it). This board has several headers:
* To Production -> All tasks that are ready to be deployed
* To Test - Second test (5) -> All tasks that have to be tested a second time
* To Test - First test (15) -> All tasks that need to be tested
* Development - Finished (10) -> All tasks that have been comitted, but haven't been deployed to the alpha sever/app.
* Development - Working (7) -> All tasks that developers/designers are working on.
* Pending - Bugs -> All tasks that need to be fixed.
* Pending - Analysis -> All tasks that need to be analyzed (improve description, break them into subtasks)
* Pending - New (20) -> All tasks that need to be done
* Backlog -> All future tasks / features / suggestions
We use projects to indicate if the task is for web, iPhone or Android; and tags if it's urgent.
There can not be more tasks that the number between parenthesis. If there are 12 in Finished for example, we know we have to deploy to the alpha server/app.
My feeling is that it's maybe more important which states and principles one has and that everyone understands them than whether they reside in one or four projects. Personally, I think it's a bit easier to focus if I only have to look at the stuff that is relevant at the moment, but I see where you're coming from.
How did you chose the number of slots: 5, 15, 10, 7 and 20?
It seems like anything that requires a bit of thought or self controlled structure people seem to tag as complexity. In a cyber world where usability and simplicity is defined by a users lack of need to think much as they are using the app, this totally makes sense. But as a user of asana myself, I have found once you get past that "feeling of complexity" - which is just a matter of deciding your own conventions, then asana is a beautifully simple collaborative tool. Flexibility is not complexity, although it may feel like it is because it requires more effort on our own part to establish the workflow.
You need the abstraction somewhere in order to build a general purpose tool for a large variety of teams and use cases. Realize that as a bunch of hackers, we're great at linguistic abstraction. Average people are much worse at it, but are pretty decent at abstraction of physical, spatial things.