In Ken Schwaber and Jeff Sutherland’s (two of the original founders of scrum) Scrum Guide, they describe it as “a framework for developing and sustaining complex products.”
Scrum consists of self-organising, cross-functional teams. Simply put, this means that the teams consist of a group of people who each have different areas of expertise but work together for the same outcome. A project manager does not control them, since their expertise empowers them to make decisions collectively.
The teams work in iterations, which allows the business the flexibility to change their requirements but still gives the development team the certainty it needs to deliver a working piece of the product. This is one key thing that makes scrum powerful.
Scrum takes its name from the analogy to rugby where a team work together in a chaotic environment to keep control of a ball. This can be compared to a team working together in a chaotic environment to keep control of a project.
Scrum Theory
“History repeats itself, unless you do something about it!”
The framework is based on empirical process control theory. The idea is very simple so do not let the name worry you. It consists of three principles: transparency, inspection and adaptation. The idea is that the scrum team, agree to be transparent (honest) in all that they do on the project.
(NOTE: Struggling to understand the basics of scrum quickly? Get the Power of Scrum Audio Book. You can use it to get a complete overview and foundation in scrum fast, before even having to “roll-out” a single scrum practice to your team. Check it out here.)
Being transparent means that functionality is not ‘done’ until it meets the development team’s definition of done. Transparency builds trust between the team members. Once the team have agreed on transparency, they agree to consistently check up on progress (inspection) and make improvements based on what they have seen (adaptation). These can be improvements in practices, sticking to values, communication or otherwise. This is powerful stuff in industry, the ability to consistently inspect and adapt. In that way they are improving time and time again before, during and after the release of a product. This is something that was not possible with the waterfall model of development.
Scrum Skeleton
The scrum skeleton is a very quick and easy way to explain the process to someone, so I will use it to explain the process to you.
We start with the product backlog, which is nothing more than a list of all the features (and their acceptance criteria) that the business desires for the product. A subset of that backlog, called the sprint backlog is taken on by the team, broken down into tasks, and worked on in an iteration called a sprint. A sprint is a period of time less than thirty days in length and in that time, the team work on their tasks until they develop a working increment of the product.
Remember those mini phases of the waterfall I described earlier? Well this is where it all takes place. There is some requirements gathering and specification update before the sprint, then design, implementation and testing. Above the large sprint circle, you will see a smaller circle. This represents the fact that every day the team meet to inspect on progress and adapt their plan for the day in a daily scrum meeting. At the end of a sprint, the potentially shippable increment of the product is delivered. The business can review the increment in a sprint review and then release the new feature(s) to the world if they so wish.
The team then discuss (transparently) their progress during the sprint in a sprint retrospective (inspect) so they can improve (adapt) on things that need improvement or retain things that are going well. The cycle then begins again and repeats until the product owner has nothing more to add to the product backlog.
The scrum skeleton demonstrates the simplicity and power of scrum as a mini factory, churning out shippable features each sprint.
(NOTE: Struggling to understand the basics of scrum quickly? Get the Power of Scrum Audio Book. You can use it to get a complete overview and foundation in scrum fast, before even having to “roll-out” a single scrum practice to your team. Check it out here.)
