Published on | Prototyping: From UX to Front End — Medium Tim McKenna

I started using Asana in 2012 when I joined the Pennsylvania Academy of Family Physicians. It was my project management tool that I used in my design process. As my projects grew and the number of people I had to work with on a daily basis grew, I saw the need for project management as a discipline and practice that is essential to design. Since my days at PAFP, I have used several other project management tools in different organizations: Trello, Wrike, MS Project, Planview, etc. but for me Asana is still my preferred tool. I’ll walk you through my basic process for how I use Asana in an agile production sprint.

1) Kickoff Meeting: Once the product team convenes to have a kickoff meeting, part of that meeting is to define MVP and project scope. Instead of lengthy scope documents written in MS Word, the product manager writes the scope directly in the description for the new project (or if it’s an existing project, we’ll add them as iterations). Initial project setup works like this.

a. The Product Manager will create a new project, name it, choose a layout (I prefer lists), and make it public (I default to public unless absolutely necessary to be private).

b. Once we have a project, the product manager will set up the project template. There are many templates you can use to break down tasks, but I tend to use the Human Centered Design Process to break up my tasks in each phase (Empathize, Define, Ideate, Prototype, Test, and my additional phase Support).

c. At the very top of the project, the Product Manager will create a task heading and tasks for describing the project, the scope of work, and any early identified iterations.

2) Now the Product Manager will assign tasks to the correct people for the team and will capture any new information or requirements in the Project Task via comments. It’s encouraged/required for practitioners to have Asana open throughout the day to be able to check on any new updates, comments, and completing their tasks.

3) Over the course of a week, each practitioner will provide input, status updates, and attach any attachments, documents, screen grabs as needed to create a robust project repository. The rest of the agile production sprint will happen accordingly with all of the feedback and updates going to Asana versus email updates or something like Confluence (which is more of a knowledge base, instead of PM tool)

4) As the project/iteration comes to a close, a new task will be created for the project retrospective and the team will discuss what worked well, what didn’t work well, what could be better. Those points will be used to help plan the next project/iteration.

Pros of this approach

Asana makes it pretty damn easy to follow the progress of a project. The fact that it’s admin-less allows team members to assign projects to each other, create tasks and subtasks as needed, and move tasks between phases as appropriate…which is really handy in an agile production sprint. Asana is pretty intuitive and takes the user experience incredibly important thus; it’s super easy to use. Asana also allows for integrations with other tools like Zapier, Harvest, and a ton of other productivity tools so even those folks who are used to a different way of working (say really good at Google Calendar or Google Docs), the integrations existing to allow them to use Asana without changing too much of their own workflow. Asana is really set up to accommodate agile development and waterfall.

Cons of this approach

Complexity can really bog down a project and it requires a product manager, project manager, or team lead to basically live in Asana to ensure stuff gets done. People tend to overcomplicate the hell out of a lot of things, so it’s very easy to complicate a project in Asana with little to no oversight. Asana’s flexibility can be considered a downfall for some because it leaves a lot up to the project owner or the organization to setup how to use it….it’s less prescriptive, which some folks might like a more formalize approach from the tool.

Verdict

Personally, I am a big fan of Asana, because of its flexibility. I like the integration with Harvest for time tracking, but I have always found time tracking to be a productivity killer, so I generally don’t use it unless required to. I also don’t use their mobile app because frankly….I just don’t want to be that connected to work that I would need it on my phone, but I appreciate the fact that I can use it natively on my smartphone. Out of all of the PM tools I have used before, Asana allows to work quickly because I can manage Asana, it doesn’t manage me. Personally I use Asana for household projects and professionally I use it with my team to manage all of our CX projects. I would suggest trying it out because it’s free up to a certain number of people to collaborate on projects.

<a href="https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href">https://medium.com/media/b85dfbb5286d8a25cf2e754b9462cf45/href</a>

Process: How I use Asana in my Production Sprints was originally published in Prototypr on Medium, where people are continuing the conversation by highlighting and responding to this story.

Process: How I use Asana in my Production Sprints

Cool stuff, every week

More Articles