Define and improve our team workflow, why and how? Part I
Note : this post and its successors won’t be quite as technical as you would expect from this blog.
A little introduction
In any growing business, there comes a time when the old and/or comfortable way of doing things is not working as good as it did before. This may be because the main goal of the company changed or in a very much more simple manner, because the team grew in size and thus must now compose with a different reality. This time came for us to review how we do things and to redefine our workflow. While doing this, we thought of sharing little bits of our experience in the form of small articles. In these articles, I will be able to document what problems we encountered in the methods we use while working and, of course, how we solved these problems.
In this first part, I’ll be showing you how the process of sharing and completing a project and its tasks can go completely wrong in a matter of weeks and how we solved the problem.
Task lists and emails
Here at La Grange, we receive (and send) pretty much every direction, bug report and even wireframes from clients by email. The thing is, it is VERY easy to forget to forward an email, or just to forget to put a team member in the CC field. On some projects, this led to thinking a team member was aware that something needed to be done, but in fact, never was even included in the email discussion with the client. You know where this led us: straight in a wall. By the end of the project, one out of the three people mainly involved got from knowing everything to not knowing at all what was going on. We had to do something, and quick.
Time for some task managing
Note : I know that in the next few paragraphs I’ll sound quite a bit like a fan boy, but don’t worry; all in all, it’s a preference choice and you can go with whatever system you like the most.
As a part-time freelancer, I used a lot of task managing tools. For numerous projects I went from simple Excel sheets to complex applications like Trello, KanbanFlow and Asana, including a bit of indie ones too. The one that I stuck with was Asana. I found it to be quite easy to understand, but to have that level of complexity that other free task managing tools don’t have. With that experience in hand, I then proposed Asana to everyone here at La Grange and together we decided to use it.
Our commitment to it is not perfect, but we try to have everything up to date on it. Even our Art Director is on Asana, making it easy for him to give us corrections to do on a project while he looks at it, and even assign a task to a particular team member. This is a much better alternative to just forwarding emails to each other with the risk of losing one in the bunch.
“Why?”, I can hear you think. Here are a couple of reasons:
- Tasks are classed by projects.
- Tasks can have subtasks that can also be marked as done.
- Tasks can be filtered or sorted by tags, priority, assignee and can even be shown in a calendar.
- Tasks can be timed in real-time, giving you insight on what you did quick or not.
- Projects and tasks can be archived for later revision.
- You can see the whole team’s calendar.
- You can add comments and screenshots to a task.
But wait, there is more <insert Ron Popeil's face here />:
There is an option in Asana to share the project you are working on with somebody who is not a part of the current organization and this is, if you ask me, one of the best features of this tool as it allows us to have them enter corrections or bugs, comment on topics, ask questions, etc.
Think of it like you were your own client. Would you like to see whether the bugs you found or corrections you thought needed to be done, get checked off a list? Like any normal customer, I’m pretty confident you would. Anyone likes to see their project is going in the way it should be : forward.
But what if the project is slowing down or starting to get problems with a feature? The client that checks the list will most likely be aware of it. Is this a good thing? Some might say no, but surprisingly, I found myself to think the other way around. While I do think that in general, a team of developpers will have much more expertise than the client in the technical field, I think it’s great to get feedback quickly on features that cause trouble. Heck, the client can even set priorities on task to help us concentrate our efforts and deliver the best product we can to satisfy him in a given time.
Another plus side in my opinion would be that in general (and this is even more the case in big companies), few team members are in direct contact with the client. Now, each one of us can interact with him and he can interact with us too. I feel like putting faces on an abstract team working on your project is great, and would I be a client, I would love this.
All of this together make the act of sharing a project directly with a client so worth it that it deserves to be the best feature in Asana and one of the best features of our workflow. Does this mean we don’t use emails anymore? Of course not. Emails are way better to communicate hard to explain bugs and questions than a task managing system is. As for sharing projects with clients, we don’t always need to do it, but when the project becomes large enough, or is in a client testing stage, it can certainly be handy to have such a tool.
TL;DR : What did Asana do to help us?
In the end, we got to a stage where we have much less problems knowing what are the other people of the team doing at any given time (therefore not duplicating work) but also to keep track of the advancement of a project. It also gives us the advantage of easy communication with the client concerning bugs and corrections, with possibilities of adding tags, screenshots, descriptions and comments to tasks. Asana clearly helps us maintain a neat workflow and solve many of the problems we had with our previous system.