How we Work part 2: Staying on task with Asana
Andrew Moore-Crispin • July 17, 2014if( has_post_thumbnail( $post_id ) ): ?>
How we Work is an ongoing series where we talk about the software and services we use every day to communicate, collaborate and generally get the job done. In this second instalment, we’ll take a look at Asana, the one app that keeps us all on track.
In the previous instalment of How we Work, we discussed development on Ting happening in two week “sprints.”
In these sprints, the product, design, user experience, customer service, front and back end development, marketing, content and other teams all contribute to get features that are planned for Ting off the drawing board and onto the live site / service.
Asana, which operates with the tagline “teamwork without email,” is what keeps us all on the same page.
Asana gives the various teams working on Ting a place to communicate and stay organized. In addition to being a handy personal task and to-do list, Asana gives us one centralized place to get together online.
The key benefit of Asana is that everything is kept in one place and every comment and discussion that’s relevant to a specific project remains tied to that project. Compare that with email where different people get cc’d at different points along the way. Late additions miss out on all the context unless they take the time to read through a wall of email replies and forwarded messages.
Within our Asana space, the main “Ting backlog” is where the Ting team all come together to collaborate on things that affect Ting as a whole. That could mean new services being added to Ting’s offering, new or re-worked features of the Ting homepage, Ting account dashboard and so on.
The main backlog is further organized into several different staging areas.
If anyone on the team has an idea or recommendation, this is where it goes. It could be a suggestion from our customers or an idea that occurred to the person while riding in to work that morning (which is not at all uncommon).
Suggestions receive a single line title, ex. “Coverage map and tools improvements,” along with some detail on the scope, the goal and why it’s a worthwhile thing to spend our collective time on.
This section is a bit of an anachronism if we’re being completely honest. It was intended as a holding tank for suggestions that merit further exploration. It’s bypassed more often than not.
This section is skipped altogether too. In fact, I’m not even sure why I mentioned this one. Or the one before it. Too bad my backspace key is broken.
Ready for PM
Now, things start to get real. Members of the product management team pick up new tasks here, ready to usher them through the development process. In Asana, tasks can be assigned to any member of the team. In this case, the person who’s taking responsibility assigns it to him or herself and bumps it up to the next stage.
This is where all the groundwork is laid. Meetings are arranged (or more likely, the assignee just kinda drops in on a bunch of people) and the project is fully scoped out, with input from all affected departments. If design comps are required, they’ll be taken care of here.
Asana lets the team communicate easily: Adding an @Brad Coates tag, for example, will let Brad know (via email) that he’s been referenced in a task. In this way, the team can alert a specific person to a comment, can ask for an expert opinion and so on.
Throughout this process, new “followers” are added as appropriate. Wireframes, illustrations, new elements, copy and so on are generally contributed at this stage.
Ready for dev
This is the area where the development team picks up the tasks they choose to work on next. When this list is running low, we hear about it in the 11am stand-up meetings mentioned in the previous instalment of this series. The development team can also ask questions or get clarifications along the way.
This area is for tasks that are being actively worked on. Teams continue to communicate through the process.
Anything the dev team needs that might be outstanding is requested and attached here. For example, an FAQ that explains a process, explanatory copy, missing images and the like.
Ready for acceptance
This is the the staging area for tasks that are completed and just need a stamp of approval from QA and the person assigned to the task before they’re queued up for release on the live site.
Ready for live
This is the culmination of the team’s work and where updates live before they’re packaged up and rolled out the the main Ting codebase. Once that happens, tasks are archived and we start again.
Success in Asana
One of our VPs found Asana and pushed teams to try it out as a collaborative place to keep everything organized. Up to that point, those of us that had been here since the very beginning had developed ad-hoc processes that didn’t scale well. Or at all.
For the Ting team, we’ve found that Asana’s efficacy is tied to how foundation is laid, meaning how the workspace is organized. The stages above work for Ting. As mentioned, a couple of them probably wouldn’t be missed if they disappeared.
Next, it comes down to how tasks are created: Too broad and they limp along through the various stages that we’ve outlined above until we’re sick of seeing them. Too pinpointed and the task list quickly fills up with minutia. There’s a balance to be struck between items that appear in the main backlog and tasks that only live in our individual task lists.
Questions, comments, thoughts or opinions? We’d love to hear them in the comments below.