Many of us are familiar with the Agile approach to Project Management. Agile is a methodology characterised by delivering projects or building products using short cycles of work which allows for rapid production/delivery, and constant revision. Essentially, Agile seeks to manage projects more efficiently through breaking them up into several phases – this allows for a continuous process of planning, executing, and evaluating. Agile can be a highly effective form of Project Management, however, often, organisations that claim to be Agile are not optimising the full potential of this approach.
For context, one of the terminologies often applied within Agile is ‘sprint’. A sprint is defined as a period of time in which people attempt to get as much work completed as possible, working towards a goal. This work tends to come from an already established list of tasks that needs to be done. After each sprint, the open list of work is assessed in line with current customer needs and the pieces of work are selected for the next sprint. This often includes work that was not completed in the previous sprint. Consider Microsoft Word’s progress over the past twenty years as an example. In the years it has been available to the market, Word has changed significantly, however, the changes have been completed in such small, incremental steps that the user can barely recognise the development taking place. The changes to the software will be in line with a vague goal along the lines of ensuring the product remains current or maintaining market dominance. These subtle changes can be carried out through continuous automatic software updates. Ultimately, the product is never finished; it is ever evolving. In this environment, simply maximising the work completed is usually the right course of action. However, the Agile approach becomes less helpful when there is a product with a clear scope which needs to be completed by a certain date.
If you asked the average person on the street what a ‘sprint’ is, their reply would very likely reference to the 100-metre sprint in athletics. We all know that in the 100 metres, competitors line up, and when the gunshot sounds, they run as fast as they can. Their aim, of course, is to be the first person to cross the finish line. In project terms, the beginning of the project is marked by the gunshot and the scope is represented by the finish line 100 metres up the track (distance and direction). The project tasks are therefore the steps taken by the runner.
However, in Agile a sprint refers to a set time to deliver work from a prioritised list of tasks that need to be done. The list is typically broken down into smaller pieces of work. If we follow the 100-meter analogy, this would mean that all the competitors stand on the start line, and when the gunshot goes off they run as fast as they can in any direction until another gunshot sounds 10 seconds later. The person furthest away from the starting point is the winner… this seems crazy! But if we change the context from a 100-metre sprint to a game of hide and seek, then running away from the starting point as fast as you can in any direction to avoid being found would absolutely be the right strategy.
Regardless of the type of project methodology, the idea of a ‘sprint’ is a good one when you look at the logic: to work on a few tasks and get them finished quickly. An athlete wouldn’t try and start a discussion during the 100-metre sprint, and the people playing hide and seek wouldn’t stop for a snack whilst the seeker is counting…
So, before you decide how to organise your sprint, you must decide what kind of project you are working on; are you running the 100-metres where finished scope is important (it’s 100-metres to the line), or are you playing hide and seek where time is important (you have a limited time to hide). If we relate that back to business, developing a physical product is more like running the race, and providing software as a service is more a game of hide and seek. Sprints work well in both environments but with subtle definition changes. In both environments it is helpful for project work to be broken down into smaller pieces of work.
Where the scope is king, the sprint should be centred around time. Create sprints by breaking the project down into deliverables that are scope-limited and have a duration of 5-10 days to deliver the scope as quickly as possible. When work is completed earlier than expected, move onto the next sprint; when the work takes longer than expected, keep working until the full scope is delivered.
Where the project is based around the continuous development of a product, use time based sprints structured around a list of ‘releases’. Within the release, you must define the tasks that need completing. The release is the sprint. In execution, work as fast as possible on completing the tasks until the sprint time limit has been reached. Then, move on to the next sprint. Any work that has not been completed should be assessed to see whether it should be carried to the next sprint. The crucial, common elements to both types of sprint are to work as fast as possible, and to minimise multitasking. Using this method of Project Management should ensure you more output in less lead-time, but you must be aware of which type of project you are working on – and therefore which type of sprint you should be using.
Goldratt UK works with clients in both project and production environments to increase output, shorten lead-times and improve delivery performance. Agile is just one of the methodology’s we can introduce you to – if you would like more information on any of the topics covered, get in touch at [email protected].
By John Muncaster, Lauren Wiles