Get the history of Scrum from founder Jeff Sutherland. In this video he discusses how the structure of Scrum was developed, and why.
As you might have noticed lately, we’ve been talking a bit about Scrum. We’ve done a post on learning Scrum in 10 Minutes, and for those of you in Wellington, we’ve run free Scrum workshops. From these posts, and through Twitter, one of the questions we get 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 from one of the founders of Scrum, Jeff Sutherland.
Check out the video below to learn about the history of Scrum and the reasoning behind the structure of Scrum.
What is the history of Scrum?
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:
Why other systems don’t work:
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.
How they developed the structure of Scrum
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. So, 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). This is 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. This would mean all members of the team knew what was going on. Specifically, they knew 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. The traditional method of using Gantt charts simply didn’t work as too many changes occur. So they came up with the concept of a Burndown Chart to show at 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.
They used a visual workspace (again, up on a wall). As a result 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 the history of Scrum — 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!
