20

Run sprints not marathons

The initial board created in Section 17 enables you to capture your work and track it as it progresses. It allows you to view quickly your future work and pull the next task through as you complete others and as priority requires. This gives you a continuous real-time workflow that you can track and helps you to manage the act element of the learn – act – review cycle.

To increase the opportunity to learn and review regularly, agile breaks down a workload into time boxes of planned activity called sprints. Originally developed within software development by Jeff Sutherland and others in the 1990s as part of the scrum development approach, batches of activity are selected and actioned within a set period of time. At the end of the time box, work is reviewed and the next period of activity is defined. These chunks of activity are commonly referred to as ‘sprints of work’. A key benefit of working in sprints is that it structures work into short cycles of development and then time, to respond to change, rather than react, at a given time. Instead of the goal being seen as one long marathon, it is a number of short sprints (Figure 20.1).

Figure 20.1 Sprints versus a marathon

Agile has established that, rather than work as if you are running one big, long non-stop marathon doing everything in one go, it is better to work in short sprints of activity with time to stop, reflect and plan regularly.

Scope to change

By working in sprints, at the end of each one there is time to stop and review what has been achieved during the sprint, measure the impact and decide what activities are best to action in the next sprint, based on current information. This enables you to make small incremental steps towards your goals, monitor progress and make changes to the future work that has been scheduled. Working in sprints provides the opportunity to review and revise priorities regularly, based on feedback and to change direction if needed.

Work within a sprint is defined through a sprint planning meeting, where time is taken to schedule the next batch of work from the backlog of future work. Typically, a sprint is between one week and three, to allow for continuous refinement and change. The sprint length should be an appropriate length so that planned work can be changed regularly, but not constantly. Regular ongoing reviews of the board and the progress should be undertaken throughout the sprint to manage work in progress and identify any issues that may stop the work from being completed.

Focus and control

Working in sprints can help to control inbound work by using the inbox on your board for the receipt of new work and ideas. To help maintain focus on the work in hand and avoid interruptions and disruption, items added to the inbox should be reviewed in batches, rather than as they appear, which helps to focus on current work in progress.

Ideally, once the work is set for a sprint, this should not change until the next sprint to avoid too much disruption from constant change. If ad hoc work is likely to occur, then slack should be built in: for example, only 30 rather than 40 hours’ work per week to allow for 10 hours of ad hoc work. This will help to protect focus on the current work in progress and avoid constant change.

Once a structure of working in sprints has been established, this helps to manage expectations and requests for new work. There is a clear time when change can be considered and new work can be added in-between sprints of work at sprint meetings. This means that, while a sprint of work is in progress, you are able to focus on completing the current batch of work.

By working in sprints, at the end of one sprint, or perhaps two or three sprints, there should be deliverables that can be shared to obtain feedback on progress. Metrics can be reviewed to ensure that work is on track.

Case example

A proactive and busy sales director of a growing website development company had an ad hoc approach when handing over new work to the development team. Following an increase in volume of work and the growth of the team from two to four developers, this began to be a difficult system to manage, which left the team feeling pressured at times, given the volume of work expected.

The director would walk into the office and announce a new urgent piece of work, and the team would have to abort current work to work on the new project. This meant that other projects became delayed and, as the volume of work being won escalated, projects were started yet fewer were completed. The sales director recognised this as an issue and identified an agile approach as a potential solution.

The team adopted an agile dashboard on a large whiteboard in the office to manage workflow and show the activities of the development team scheduled for the coming week. The team started working in weekly sprints and pulled through a week’s work at a time from the backlog of future work, based on priority. The sales director was included in weekly meetings, which gave a channel to pass new work onto the development team. If the work was urgent and given to the team in an ad hoc way, this triggered a stand-up meeting at the board to discuss the size of the urgent task and decide what was to be removed from the board to enable resources to be freed up, so that the urgent project or activity could be completed.

Beyond the improvements in structuring and organising work that the dashboard brought to the team, the dashboard also helped to communicate with the sales director and raise awareness of the impact of ad hoc urgent work on the team and the flow of work. This led him to be more mindful when setting client expectations. By being part of the weekly review at the end of each sprint, he was also able to relay progress back to the customer more thoroughly and regularly. As a result, the team became less distracted and less pressured and, in turn, more productive and happier. As a bonus, since the team were recording their time spent on projects more accurately, they increased chargeable time by 20 per cent to the customer but, overall, reduced the project cost to the customer.

It is better to run short sprints with time to take a breath and compose ourselves in-between them, than attempt to reach our goal in one long marathon.