If Agility is a set of behaviours, then Scrum is a framework that can be applied on top of these to implement high quality working software. It’s a framework which uses three pillars to support itself. These are:
- Transparency. A team that is using Scrum should be completely transparent. They have no secrets! They’re clear with themselves and their stakeholders about what is going on in the team, how they’re working, what they’re working on and why.
- Inspection. While the team is working they collect data on how they are performing. How many bugs are they generating or fixing? How many pieces of work are being completed and how long is each one taking for example. As a team evolves the metrics they collect may change too.
- Adaption. Data isn’t much use unless you do something with it. Teams use the data they collect to make changes to the way they’re working and adapt their processes to try and improve things. They may experiment with a slightly different way of doing something, continuing to collect their metrics and then review whether it was a good change or not. If it was they’ll keep it (or maybe refine it further) or they may revert to the previous way.
There are 5 values that Scrum teams should be embodying all the time. I’ve always thought that these are pretty generic and should be applied to anything you’re doing in a professional environment.
- Commitment. Do what you said you were going to do and look like you care about it too.
- Courage. Be brave enough to make suggestions, change the status quo, voice your opinion and support your teammates.
- Focus. Concentrate! Don’t get distracted on other things.
- Openness. Share your thoughts and opinions. Be open to other peoples ideas and ways of doing things.
- Respect. Treat other people like you’d wanted to be treated… or better!
One of the things that makes Scrum so light weight and flexible is the few roles that it defines. There are just 3
- The Scrum Master owns the Scrum process and is responsible for making sure the team follow it. He holds the team to account for their decisions, protects the team from outside interruptions and drives change both at the team and organisation levels.
- The Product Owner is the voice of the customer in the team. A PO is responsible for what the team is working on, prioritising the Backlog (see below) and resolving queries and questions from the Team.
- The Team is responsible for turning the business requirements given to them by the PO into working software. They are self-organising, co-located and should contain all the skills they need in order to get the work done.
Teams using Scrum work in Sprints. Simply put, a Sprint is a box of time which is always the same length. Most teams use a 10 day sprint. For example, the team I’m working with at the moment finish their sprint on a Tuesday afternoon and we start a new one in the morning of the next day.
The goal of every sprint is to have one or more pieces of working software that we can ship to production. We might choose not to ship them but we could 🙂 Each of those pieces of software is complete and has value. If we did put them into production they’d actually improve things somehow.
A team can keep sprinting indefinitely. They control their own pace and although they try to get faster they work at a sustainable pace. They don’t take breaks from the sprints at the end of projects – they just roll off one piece of work and on to another.
Every sprint has the same structure which helps us get into a rhythm.
- Sprint Planning. The start of every sprint is the planning meeting. Everyone meets and the PO presents the candidate pieces of work for the sprint. Everyone discusses them and the team work out what the necessary tasks are to implement them. They agree how much work they can do in the sprint based using their data and capacity and form a sprint commitment.
- Daily Standup. Sometimes called a Daily Scrum, this is a short meeting where the team get together to review the progress made in the previous day and plan what will happen today. It’s an opportunity to ask for help, confirm that everything is on track to deliver what has been committed and report any disruption.
- Sprint Review. At the end of each sprint the team and their stakeholders gather together to review what has been achieved. They’ll get feedback on what they’ve built which may result in more items being added to the Backlog. At the end of the Review everything that has been accepted as Done can be promoted to production.
- Sprint Retrospective. At the end of the sprint the team reviews the way that it has gone about working in the sprint and makes changes to improve their performance. They will refer to the data collected throughout the sprint and will also generate insights and discussion during the meeting. At the end they’ll have a set of actions that they can carry out in the next sprint to improve things further.
Scrum defines 4 basic artifacts.
- The Product Backlog is a prioritised list of work that the Product Owner maintains. The most important work is at the top and should be nice, small items that are well understood and ready for the team to work on. The further an item is down the backlog the less well understood and the larger it is. Very large items are broken into smaller pieces to reduce the risk, complexity and uncertainty and allow them to be delivered separately.
- The Sprint Backlog is one of the outputs of Sprint Planning. It is a set of tasks that the team will work through in order to deliver the sprint commitment. The contents of the Sprint Backlog are owned by the Team and they are the only ones that can add to it.
- The Definition of Done (DoD) is a checklist of criteria that a piece of work must meet before it can be counted as completed. Anything that doesn’t meet the DoD cannot promoted to a production environment because the quality cannot be guaranteed.
- A Potentially Shippable Product Increment is a slice of fully working software that, if the team and shareholders choose, can be shipped to a production environment.