So, what exactly is a sprint?
I don’t think the people behind Scrum and other agile methods participated in sports very much. They seem to have borrowed a lot of sporting terms but haven’t used them very wisely.
The phrase “Sprint” is a good example of this. In athletics, a sprint involves individuals trying to run faster than everyone else over a short distance. This might be how your team feels at the moment, but it probably isn’t a good picture of where we would like to be.
About agile in Cornwall Council
We are starting to adopt more agile ways of working. My role involves helping people develop their skills and apply agile techniques to improve the services we provide to the public. This series of posts is adapted from the articles I write for our internal teams. They cover some common agile terms and what it all really means.
Mixed metaphores
In product development, a sprint is a repeating cycle of activities which is designed to manage risk and deliver a steady flow of business benefits. By regularly finishing small pieces of work and receiving fast feedback, teams can learn what works, deal with problems quickly, and use this experience to improve in subsequent sprints.
Sprints vary in shape and size but most people start with the suggestions in the Scrum Guide[1].
At the start of each sprint, the team confirms what work it intends to complete and how the work will be done. During the sprint, the team does the work and has regular, short meetings to keep on track. At the end of the sprint, the team reviews both what has been completed and how it was done. Lessons from these reviews are fed into planning the next sprint.
The Scrum Guide is very short and only covers generic good practice. It doesn’t cover everything that a real team might need to do, so you may come across some challenges or myths when putting sprints into practice. Here are a few common ones:
Sprints are only for teams writing code, aren’t they? It is true that a lot is written about sprints for software development, and software engineers think they created these ideas, but the principles are much older and were initially developed for traditional manufacturing processes.
Only plan for the next two weeks? That’s crazy! Sprint planning does focus on the next sprint, but sprints aren’t always two weeks long and, anyway, this isn’t the only type of planning that a team does.
What about all the good stuff I learnt from working on projects? Agile techniques (like sprints) are good for handling certain types of risks such as uncertainty and volatility. Traditional project management techniques are good for handling other sorts of risks such as large, unfamiliar investments. They can work together and many teams find that they have both types of risk and need to dip into both sets of techniques.
Where to go next for more
More of a visual learner? There are loads of great resources you can find with a quick search. For example, there are videos[2] on fundamental principles of a Scrum which are less than 10 minutes long!