In this first post of three looking at the basics of Scrum, I introduce the Scrum Framework and where it came from.
Scrum, according to the official guide, is “…a framework for developing, delivering, and sustaining complex products.”
It was created specifically for software development teams as an alternative to the more traditional waterfall development methodology but it is increasingly being used within the wider business world and beyond – including in education.
Scrum was developed by Jeff Sutherland and formalised, with Ken Schwaber, in 1995. It was built upon a wide range of ideas and influences, not least of all on a paper written in 1986 by two Japanese academics, Hirotaka Takeuchi and Ikujiro Nonaka, while they were Visiting Professors at Harvard Business School. They inspired the choice of name for the framework when they likened recent trends in development practices in Japan and the US to the game of rugby and the scrum formation in particular.
The core philosophy behind Scrum is the theory of empiricism – that is, making decisions based upon what is known. To explain this a little further, let’s take a look at one of the key issues with the old way of doing things.
At the start of a large and complex project there are many unknowns, for example:
- What is the real-world capacity of the teams involved in delivering the product?
- How will that vary over time as team members get used to working with one another?
- How will it be impacted when individuals join and leave?
- What will be the impact of unforeseen technical challenges, which inevitably occur in any complex project?
- How will delays and issues in one area of the project impact other areas?
- How well does the customer understand what they need from the product during the initial planning stage?
- In what ways will the world and consequently the customer’s requirements change during the life of the project?
- What overheads are required to manage the many different parts of the project?
- What is the most efficient way to communicate between the different areas of the project?
In the old-fashioned waterfall approach, the project planners either ignore the potential issues or they attempt to estimate their impact. Because every project is different, these estimations are effectively guesses, leading to a plan that fails to predict anything useful. Consequently, projects, if they are delivered at all, are frequently delivered late and over budget – often failing to provide anywhere near the value that was promised at the start.
Rather than trying to understand the entire mountain up-front, Scrum minimises the impact of the unknowns by taking on the challenge in small chunks (called ‘sprints’ – lasting between 1 and 4 weeks). After every sprint, the team, the customer and other stakeholders learn something new about the product, the environment and the performance of the team, allowing for corrective adjustments to be made. This leads to a cycle of continuous improvement.
Realisation of Value
Another big advantage with Scrum is that it’s capable of delivering a working, useable product to the customer almost immediately or soon after the start, whereas waterfall projects typically only deliver something at the end, which can be many months – even years after the project begins. During these long projects, investment becomes tied up and only turned into value for the business when everything has been completed. Scrum allows the business and its customers to realise the value of their investments much sooner.
Also, if a ‘wrong turn’ is taken during a Scrum sprint, the impact is small (typically no bigger than the sprint size) and the resolution quick to apply. In waterfall, errors can go unnoticed for long periods of time and their correction can have significant negative impact on the plan and the budget.
In the next blog I look at the main elements of the framework as defined in The Scrum Guide.
Comparison to Rugby: https://medium.com/serious-scrum/scrum-s-connection-to-rugby-597405fed5ec
Hirotaka Takeuchi and Ikujiro Nonaka’s Harvard article: https://hbr.org/1986/01/the-new-new-product-development-game