The Scrum Framework is a simple and popular Agile approach to organising teams to help them create valuable things in complex environments on an adaptable, regular and collaborative basis.
Origins
It was first theorised in Japan by business professors Hirotaka Takeuchi and Ikujiro Nonaka in 1986, before being put into practise and codified in the mid-1990s by Jeff Sutherland and Ken Schwaber in the United States.
It has since taken over the world, spreading far beyond its original domain of software development. It has gone on to help teams in a broad range of sectors, from law, to HR, to research, the military and many more to create things ranging from websites, hospital data systems and mobile phone software to Spotify, AWS and BBC iPlayer to factory warehouses, academic curricular, cars, planes and even tractors.
It has helped reshape the world we live in and it can help you too.
The Three Scrum Roles
In order for Scrum to work, the team organises into three roles: a Product Owner who sets out the product priorities, the Developers who turn these priorities into valuable things on a regular basis, and a Scrum Master to coach the team into higher performance and help them adhere to the Scrum framework.
There are no hierarchies. Everyone is equal regardless of experience, rank or position.
The Product Owner is one person, the Scrum Master is another person, and the Developers number no more than eight people, to keep the team small, collaborative and nimble.
Otherwise, if a team gets too big, all sorts of issues start to creep in and erode effectiveness (like communication overheads for a start).
The Three Scrum Artefacts
The Scrum framework also involves three things called ‘Artefacts’. Two of these are like living documents (the Product Backlog and the Sprint Backlog), and the third is the valuable thing that your team is producing on a regular basis (the Increment).
The Product Backlog belongs to the Product Owner and includes a shiny Product Goal (an ideal future state of the Product that the team can work towards) plus an evolving list of work items and features that contribute towards achieving the Product Goal.
The Product Backlog is arranged in order of priority with the most valuable items at the top of the list, with more detail. Less prioritised items are further down the list and have much less detail. They tend to only get the comprehensive discussions, details and planning when they are higher up the priority list and closer to their planned delivery date.
The Sprint Backlog belongs to the Developers and consists of the Sprint Goal (the team’s current target), the list of Product Backlog Items they have currently committed to delivering, plus the plan for how they’re going to deliver them. They organise themselves so they choose what they’re committing to and how they’re going to do it. They’re not told what to do. If you haven’t worked in a self-organising team before it’s very refreshing when you get used to it!
Then finally, the Increment is a tangible thing that the team has produced, completed or delivered that takes them closer to the Product Goal. They ideally produce these valuable things on a regular basis (and at least once per month).
The Five Scrum Events
As well as the Scrum Roles and the three Scrum Artefacts that the team plan their work around, the framework also has five events that the team participate in.
The first event is called the Sprint. It’s a repeatable cycle of time, one month or less – and many teams use cycles of one or two weeks.
All the activities take place within this cycle, and it repeats indefinitely, one after the other. When one Sprint ends, the next one begins.
The other events are all collaborative meetings.
Within the Sprint, the first meeting-type event is Sprint Planning. This is where the team get together, assess the top priority in the Product Backlog, commit to delivering the most important items and plan how they’re going to do it by the end of the Sprint. At the end of this event, they will have produced a Sprint Backlog and will get on with delivering it.
Then, every working day during the Sprint, the team gets together to look at their progress through the Sprint Backlog and collaborate on how they are going to get closer to the Sprint Goal over the next 24 hours. These daily meetings must take place in 15 minutes or less to increase focus and maximise non-meeting time for getting work done.
At the end of the Sprint, the team gets together with key Stakeholders in an event called the Sprint Review where everyone sees what’s been built, achieved and learnt over the course of the Sprint.
The Stakeholders provide feedback, the Product Owner might update the Product Backlog when they find out more about what users and customers want, and everyone learns about what’s going on in general. It should be collaborative. If the stakeholders are just sitting there in silence watching a demo, it’s not enough. Everyone should get involved, ask questions, see what’s being built and share insight.
It’s the one time when Stakeholders are actively encouraged to collaborate with the team – otherwise it usually helps to keep them apart so they don’t distract the delivery focus of the Developers.
Then, after the Sprint Review, the team gets together for the last event in the framework to collaborate on how they might improve how they work. This meeting is called the Sprint Retrospective. Don’t skip it, it’s possibly the most valuable meeting of all. Agree to at least one measure you can try out together and see if it enhances your performance. By doing this once a Sprint you get into the healthy habit of always getting a little bit better on a regular basis. It’s a built-in mechanism to help you achieve high performance as a team.
Scrum Theory
The Scrum Framework is built on things like Lean Thinking and Empiricism (learning from observations), which itself is built upon the pillars of being transparent about what’s happening, inspecting things in detail and adapting on what is learnt and observed.
The Scrum Values
To help teams adhere to good working practises and to make good choices in varying circumstances, the Scrum Framework also has five values to guide its practitioners:
- Commitment: commit to a goal, to a product and to always getting better.
- Focus: focus on your top target and don’t move on until it’s completed.
- Openness: be transparent with yourself, your teammates and your stakeholders.
- Respect: respect one another, respect the users, the customers, the profession, and the tried-and-tested durability of the framework itself.
- Courage: have the bravery to stand up and call things out when they aren’t working and remember that it takes courage to accept flat hierarchies; admit mistakes in the pursuit of learning; and to adopt the framework itself.
How to get started with Scrum
The best way to understand how Scrum works is to actually experience it and learn your lessons along the way, but an absolute must-read is the official Scrum Guide itself.
Other Notes
The Scrum framework has lots of purposeful gaps to make it flexible enough to bend around lots of different working situations. I have compared it to a fishing net in the past.
Leave a Reply