At White Fuse Media we have been exploring ways to introduce elements of agile project management into the way we manage workloads across the company. We recently introduced the idea of a weekly sprint and have found it very helpful so I thought I would share our experiences.
The success of the change is very much due to the functionality of the team collaboration tool we use, Teamwork (you can read our brief review of Teamwork here) though hopefully much of what follows is relevant to users of other systems too.
Hacking the agile methodology
Agile methodology grew up in the software development world and is a lot easier to apply when you are working on one product. At White Fuse Media we tend to have around 20 external projects running at any one time and numerous small internal ones. Using agile methodologies in this context requires some hacking of the pure concepts.
Benefits and shortcoming of using task lists to manage workload
At the heart of our workload management systems is the task list. Most of the popular online collaboration tools are in some way based around projects and tasks. Teamwork is no exception – it has projects, task lists and tasks. Tasks can each have a priority, estimate and due date.
We see task lists as crucial to effective working. By getting tasks out of people’s brains and into an organised structure we leave our brains free for creative thinking. Ideas can be captured for later evaluation and we can prioritise our time effectively. However, over the last year or so we have become aware of the shortcoming of using task lists alone to manage our workload.
First, task lists can quickly become overwhelming. While Teamwork’s priority functionality allows us to focus on the most important tasks it can be daunting to be faced with an unending task list.
Second, it proved very hard to know how much we would get done in any particular week. Each member of the team would work through tasks in their task lists but there was no way of tracking whether it had been a good week or a bad week on the productivity front, except by gut feel.
Third, we struggled to effectively record our time. We see time recording as crucial to check that we are running project to budget but the accuracy of our figures depend on individuals in the team having easy ways to record their time.
Key concepts in agile project management methodology include the breaking down of large tasks into small tasks and assigning each small task a time estimate. A reasonable number of small tasks are then allocated to a person or team over a period of time (a ‘sprint’). The rate at which these tasks are ticked off is measured (the ‘burndown rate’) and this allows the team to get an understanding of how quickly work is being achieved and how accurate estimates are. This information can be extrapolated to get an undertanding of how realistic larger project milestones and deadlines are.
We chose a one week period as our sprint period. Rather than attacking our whole task list each day, we decided to start each week by considering priorities for that week and pulling an achievable number of tasks into a specific task list for the week.
TeamworkPM’s ‘workload’, ‘estimates’ and ‘due dates’ functionality
Although Teamwork is not specifically structured around the agile methodology (there are a whole wealth of systems which are) it has a number of extremely useful features that we used to introduce the agile concept of a sprint into the agency’s company wide processes.
The first step was to start assigning estimates to all of our tasks. This takes some thought since to fit with week long sprints each task must be defined with sufficient granularity to be achieved within a particular week. On the other end of the spectrum, the tasks couldn’t be too small otherwise the admin associated with creating tasks, assigning and estimate and then recording time against them because too arduous.
The next step was assigning tasks to the next sprint.
Because we run many projects concurrently for different client it was still very important to track project progress on a per-project basis. This meant we couldn’t actually create a separate task list for the sprint. Instead, we decided to use Teamwork’s due date functionality for this. This requires a slight shift in understanding of ‘due dates’. Due dates become the final day in the next sprint cycle, which is often slightly different to the intuitive purpose of due dates on a task (we have shifted to using ‘milestones’ to track important client deadlines that then inform our sprint priorities).
After we have set a due date for the week’s tasks, we then use the ‘everything’ tab in Teamwork to view all active tasks that are due by the end of the coming week. That is our agenda for the week.
One huge advantage of this approach to task management is that it gives individuals much more control over what tasks they choose to do at any particular time. It doesn’t matter which tasks are done first as long as everything gets done in the week. One caveat to this is that we prioritise tasks which are dependent on other tasks (another brilliant feature of Teamwork).
The icing on the cake of this new way of working is Teamwork’s ‘workload’ feature. This gives a snapshot of the whole team’s workload for a particular time period. By setting this for the coming week it is possible to get a quick view of how busy the team is and how well everyone is doing with their week’s tasks.
At the end of a successful week this system gives the deep satisfaction of looking at an empty task list!
This is all still very much a work in progress so please share your own experiences below.