Using Asana for Sprint Cycles: A Retrospective Journey

Our team utilized a sprint cycle methodology for completing tasks throughout the project. For those unfamiliar with the sprint cycle, it’s a theory of project management that goes a little bit like this:

A sprint cycle diagram from our friends at Agile Learning Labs: http://www.agilelearninglabs.com/resources/scrum-introduction/

Sprint cycle is a pretty common methodology for project management amongst software companies and something everyone on our team was familiar with prior to PoE. As such, we were all familiar with readily available tools for sprint cycle management, such as Trello.

An example Trello board demonstrating sprint cycle managements

Being weird and crazy people who like to experiment, we decided to try a totally different project management tool that none of us had used for sprint cycle management before: Asana.

Asana is a project management and tracking tool similar to Trello except that it conveniently shows you only the tasks that have been assigned to you, rather than all of the tasks for the whole team. This is in theory nicer than the boards above, which can get cluttered and hard to decode. Rather, Asana is supposed to look like this:

Our ReFilament Asana Project

Now, this may look worse than the boards above, but it gets a lot nicer when you select “My Tasks” and Asana shows you just the tasks you need to accomplish, like so:

The Tasks I have left to do for PoE….Yikes!

Using Asana throughout our PoE project was an interesting experience and one that had its pros and cons. To that end, the list below is a number of key takeaways from our attempts with Asana.

1. New software is hard. Despite some team members having previous experience with Asana, it still had a learning curve and that can be hard for a project on a deadline
2. High-level organization matters. For the first two sprints, we organized each one as a separate project in Asana. We thought this would make it easier to separate sprint goals, but in reality it just abstracted what we needed to do and meant that less people checked Asana :(
3. Tasks need to be as small as possible. This holds true for almost everything in life, but our whole team worked a lot better with a massive tasklist of easily accomplished tasks. Breaking a massive thing down into 100000 tiny things isn’t bad if each of the tiny things can be completed quickly.
4. Don’t set deadlines realistically. The sad fact of human nature, as we learned, is that even the best among us wait until the last moment before a deadline to begin working in earnest. To combat this, I often set the Asana deadline for something a day or two or even more before it actually needed to be done (and wow did things go smoother!).
5. There isn’t one perfect tool, its whatever works best for you. Throughout this project, our team used Asana for task management, google drive for file documentation and collaboration, github for code documentation and collaboration, and messenger for communication. None of these services did all of the things we wanted and that’s okay because people worked best with what worked for them.

All told, Asana worked out pretty well for our team as did the sprint cycle. In the future, we would probably front load sprints more: using the first week as the main work week of a sprint and then tidying things up in the second. Oh well, I guess I have a kaizen ready for my next project…