Since we have moved from Basecamp for task tracking to Lighthouse our workflow has changed significantly. Our workflow improved not just because of using a new task tracking system, but also due to learning from mistakes and figuring out what works best for us. It’s something that did not happen over night. We have made numerous small improvements over time and achieved much better productivity. This article is a small insight in the practices we use.
Communication is the key
In order to make products like Beanstalk, Newsberry and Postmark, you need to have great communication in the team. Without communication, projects would quickly lose their pace. We made a bunch of small improvements to keep everybody on the team happy:
Quiet time
When we are working, our goal is to not disturb each other, so we don’t break the persons “mojo”. Every piece of communication that can wait is not discussed directly through IM. We use Basecamp, emails or tasks for this, depending on nature of the topic which needs to be discussed.
IM Status
IM status can be a really handy piece of information. It can help you figure out whether person is working, whether a person is super busy, when a team member will get back or whether someone is just hanging around after the work day. Although IM status-es are easy to use and pretty obvious, we started using them more intensively just recently.
Discussing features
When we are discussing features, we use Basecamp and include everyone in the team on topics, even if they are not assigned on the project. You never know if someone has a great idea.
Release notes
When we started using scrum, we started using release notes too. Release notes are quite handy. They are not just valuable for Chris (team lead), but it’s also a small retrospective of the work a team member has done over the last iteration. They give an insight for all members of the team about how the project is doing from a high level.
Posting plans
Another great method is posting plans for the work in previous 24 hours, progress at the moment and plans for next 24 hours. It’s one more benefit of using scrum in our virtual team. We tend to post plans in our morning meetings in Campfire.
Managing tasks efficiently
Managing tasks in a task system is never easy. After time tasks pile up and it gets harder and harder to maintain them. We added a couple of rules to our process to avoid this.
Use simple states
We had a long discussion on which states we would use in the task management system. The more we talked about it, the more states we came up with. Hristo sugested that we use simple states, like
- not started – nobody is working on the task at the moment
- in progress – someone is currently working on the task
- complete – task is complete and deployed to production site
and it proved to be the best choice for us. By using three simple states, we could easily define the state and have a clear view on the status. We added three more states (which I will mention later), but basically these three states are the ones used most of the time.
Assigning tasks and Milestones
When no one is working on a task, the task is not assigned. That is usually happening in the Backlog. We assign tasks to a person in case we know that person will work on it. Assigning a case is also a way of notifying the person by email about the task. Tasks are usually assigned when we are creating new Milestones. Milestones contain all the tasks you will work on, and usually last between one and three weeks. Two weeks is kind of optimal. If milestones stretch for too long, they get harder to maintain and deploy.
By the end of the milestone, all tasks in the Milestone need to be finished. Now, this is not always possible. Sometimes tasks in a milestone simply get out of hand and can’t be finished in time. In this case we move them to another Milestone, estimated with other tasks in hand.
Backlog and On The Radar
The Backlog is where we hold all of the tasks we plan to work on in the future. When there is a huge list of tasks, the backlog tends to turn into a place where tasks will “die” after a period of time, and will never be implemented. That’s why we try to look over the backlog after some time and clear it up. In addition to the Backlog, we use a milestone called On The Radar, in which we store backlog tasks which we will work on in the near future (next month or so). On The Radar can be handy when you need to figure out the next Milestone for the project.
Small things that make life easier
There is a variety of very small things that can make your everyday workflow easier. Here are some that help us out:
Additional Task states – approved, hold, invalid
I mentioned that we are using a few additional states next to the three basic states:
- approved – task is finished and reviewed on staging, but not deployed yet to production
- hold – task is on hold due to a variety of reasons
- invalid – the task was canceled out for some reason
I find the approved state above the most important. This state happens after we have completely finished the task, but did not deploy the updates to the production website. The task is marked approved and assigned to a developer. When updates are deployed to production, the task is assigned to QA, who checks the production site and marks the task complete (or not).
Allowing the team to be creative
Working on something different and new from time to time can boost your creativity. That’s why we introduced Open Source Fridays and Paired Milestones:
Open Source Friday
Open source Fridays allow team members to work on something different every other week, and to release the product of their work to the open source community. You can read more about OS Fridays in this post.
Paired Milestones
We’ve also started to explore less rigid work flows. An example is Paired Milestones. With this concept, we define some general high-level goals for a project and assign two people to accomplish it in two weeks. This could be a designer / developer pair, two designers, or two developers depending on the goals. Instead of having a project lead and specific tasks, the pair is completely responsible for organization, detailed ideas, and the outcome without outside influence.
What’s next?
We have no idea. When we take a look back, our workflow was completely different and we just can’t image how we could live without some of the improvements we have made. We are constantly improving and would probably say the same when we take a look back one year from now.