Using Teamwork Projects and Weekly Sprints to Get Things Done
Today, we’re sharing a guest post by Andy Pearson, Managing Director of White Fuse. He is sharing how he and his team use Teamwork Projects in a unique way to cater to their bespoke blend of agile and sprint methodologies in their workload. At White Fuse, we build websites for charities. We’ve used loads of project management methodologies over the years and one of the most effective has been weekly sprint planning using Teamwork Projects. When you are managing a small team spread thinly across multiple projects that each span several months, with dramatic peaks and troughs of activity, this approach is very powerful.
Beg, steal, and borrow
We’ve stolen from various methodologies. Over the years, the most helpful approach we found for delivering multiple medium-sized web projects simultaneously was a broad rigid structure of milestones and then, within each milestone, a more flexible approach. We use all terminology loosely, but have found something that works by hacking together some of the old waterfall approaches with agile thinking. We love the lean startup methodology too and this influences our overall company strategy, though we’ve not found it so helpful for day-to-day projects because we aren’t building brand new systems. What we emerged with is a very structured project timeline with dated milestones from start to end. Each milestone is aligned with a week, and within this week we focus on delivering the best stuff we can for the deadlines scheduled for that week.
The crux of the matter: how to manage workload
We’ve always been sold on the value of having some central system for managing tasks. If you aren’t doing that, you should definitely check out Teamwork Projects and you’ll find loads of ways to build efficiencies into your organisation just by getting all the ideas out into a shared system and organising them well. However, the big challenge for us has always been managing workload. How do you promise lots of things to lots of clients and then deliver your promise without burning out your team? We’ve never seen overtime as an option. It didn’t fit with our ethos to push this issue on to our staff. So, we had to find a different solution. There are loads of tools out there for managing schedules, but we found that none of them really worked for us because we don’t allocate the team’s time neatly by half days. We are working on too many projects simultaneously for this to work and it felt overly prescriptive.
So, we chose to manage time in Teamwork Projects, but this resulted in some challenges we had to wrestle with:
Task lists can be overwhelming and priority systems are very hard to implement across multiple projects with different project managers pushing their agenda.
It’s hard to know how much you can achieve in a week. True agile methodology deals with this by removing hard promises on what will be delivered, but this didn’t fit well with our approach of speccing things out clearly.
When one project is delayed, it can be hard to evaluate the knock-on impact. When renegotiating the project timeline with the client, it’s important to know that the new milestones don’t stretch the team too thin on any given week.
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 understanding of how realistic larger project milestones and deadlines are. While much of process doesn’t look like agile development, we grabbed this element to deal with the schedule management challenges we had. 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.
Harnessing the power of ‘milestones’, ‘estimates’ ‘due dates’, and ‘workload’ in Teamwork
Milestones – our overarching rigid structure
We promise clear delivery dates to our clients. Tracking these through milestones gives us a range of great reports and overviews to see this big picture client focused view. But how do we manage the scrappy day-to-day challenge of meeting those deadlines? Enter estimates, due dates, and workload.
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. Vague tasks were not allowed! On the other end of the spectrum, the tasks couldn’t be too small, otherwise the admin associated with creating tasks, assigning an estimate, and then recording time against them became too arduous.
The next step was assigning tasks to the next sprint. Because we run many projects concurrently for different clients, 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 Projects’ 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 Projects 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 is that we prioritise tasks which are dependent on other tasks (another brilliant feature of Teamwork Projects).
The icing on the cake of this new way of working is Teamwork Projects’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. We had to push Teamwork Projects hard and it took a lot of thought and experimentation. Hopefully, some of these ideas will help you explore new ways to get more out of your team with Teamwork Projects!