Running a HALO product development team | Hacker News Reader

Running a HALO product development team

blog.tallhamn.com

26 pointsgvr11 comments

Asana is complex. Too complex.

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.

Author here: I agree Kanban boards have benefits. I've helped other people implement the system I described in Trello as well.

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!

> Asana is complex. Too complex... 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.

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.

My boss created a project and assigned me tasks, and tagged them all. I could see all the tasks, but not the tags, so I re-tagged everything. Now he has two of every tag.

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.

Asana's vocabulary is concrete, but the UI is abstract. In contrast, Trello's terminology is abstract, but the UI is concrete.

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.

The word "project" has meaning, as does the word "task". Not everything you want to track is a task and not every grouping of tasks is a project.

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

I've used Asana and Atlassian's jira. Jira is far and away easier to use and has much better control. It's always clear to me which issues I need to work on first and which versions of the product they'll impact.

We also use Asana and Kanban. However we have a simplified use in Asana. I've found that you have too many projects and places where to look.

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.

Thanks for sharing your structure!

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?

we started with some that seemed reasonable, and then we modify them after some weeks of use.

I don't think I would say asana is complex as far as usability. The interface and shortcuts are all pretty intuitive in my opinion. I do think though that asana's lack of opinion or convention and freedom of how to structure the tasks is what some people may feel is "complex".

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.

Reply on news.ycombinator.com