Jeff Sutherland on the History and Structure of Scrum
By Jacob in Agile Development on August 15, 2011
As you might have noticed lately, we’ve been talking a lot about Scrum – we’ve done a great post on Learning Scrum in 10 Minutes, and for those of you in Wellington, we’re even running free Scrum workshops.
All of this is really useful, really interesting information, and we hope that you are all getting value from it. From these posts, and through our Twitter stream one of the questions we’ve been getting most frequently is about the history of Scrum – where did it come from and why did it turn out the way it did?
To answer this question we’ve got a video straight from the source with one of the founders of Scrum, Jeff Sutherland.
Check out the video below to learn about the history and reasoning behind Scrum.
Where did Scrum come from?
The logic behind Scrum as a development methodology is really very interesting, and Jeff Sutherland does a great job of explaining it. There are a few key points I find particularly interesting, and that are reflected in Scrum processes as we see them today:
- Specialised silos of activity leads to slower communication and add lengths to the development process – this makes sense as there is not enough communication between people with different roles so it makes it hard to achieve the goals or development milestones that they have committed to
Why other systems don’t work:
How they developed Scrum processes
-
The roles of Scrum
- To simplify the process they created teams with just two roles – a team and a team leader (aka The Scrum Master)
- They found that the needed someone who truly understood the requirements of a project as well as representing the users, and so they came up with the role of Product Owner. This way every development cycle would add value for users and the business, and the team would have someone on hand who understood the requirements of each piece of functionality and could explain the reasoning each part of the project
The meetings of Scrum
- Experience shows (and anyone who works in a large organisation can testify) that too many meetings slow down the development process; in order to speed up the process, the needed to reduce the number of meetings to a minimum amount
- They found development should be done in short cycles of 2 to 4 weeks (aka sprints) – essentially so there is good communication, and each development cycle can be well estimated
- You need a meeting at the beginning of a sprint to define what you are going to pull from the product backlog (as managed by the Product Owner), how you are going to implement and track each item from the backlog
- Research from Bell Labs showed that teams were driven by daily meetings, but they wanted it to be a very short meeting of no more than 15 minutes, so all members of the team knew what was going on, what they were going to achieve and how they could help other team members
- At the end of a sprint, you would demo real, working software to get feedback from the product owners and stakeholders of the project, so you know what’s working well and what’s not – that feedback cycle (aka a Retrospective) is what helps teams to improve and help development go faster
Reporting in Scrum
- They needed to do a rethink of how reporting would occur in software development as the traditional method of using Gantt charts simply didn’t work as too many changes occur. They came up with the concept of a Burndown Chart so you could see a glance how fast the team was going, how much work was remaining and how much time was left to do it
- They left the Burndown Chart up on the wall as a method of self reporting. Everyone could see the state of the Scrum at any time, and immediately know how much work was left to do.
- They used a visual workspace (again, up on a wall) so you could see what needed to be done, what work was in progress, and what was done and tested at any moment in time
Scrum in a nutshell
So that’s more or less how Scrum came about – quite an interesting story really. Jeff Sutherland is evidently a very interesting character, and the thought that has gone into making Scrum as efficient is really very apparent.
Does this match up with your own experiences of Scrum? How does Scrum work for you? Did you enjoy your history lesson? Be sure to let us know in the comments below.
Want to learn more about Scrum? Be sure to sign up for our RSS feed, or follow us on Twitter and Facebook for more great information. Thanks for dropping by!


