The strengths of Scrum
OK so you might think after the last post, that I’m against Scrum and I think it’s worthless. Not true at all. I use it a lot and have a lot of respect for it. There are definitely some strengths of scrum for software development. I just think it’s worth being aware of its weaknesses. To help balance things, I’ll put forward what I think are the strengths of scrum.
Scrum separates scope from work
One of the best rules of Scrum is also one of the simplest: a clear separation of scope (Product Backlog) from work (Sprint Backlog). This is so important and so many people don’t understand it and get it wrong. Maybe the Scrum guide doesn’t explain it clearly enough or explain the why behind it.
The Product Backlog is scope and is owned by the product owner
To clarify, the Product Backlog is the domain of the Product Owner. The Product Owner oversees and rules the Product Backlog, completely. That’s the job of the product owner: to own the vision, roadmap and scope of the product. To choose what goes in it, what won’t, and what the priorities of scope are. The development team have no say about what goes in or out of the product backlog. Their job is to not to define scope, but to turn scope into work.
The Sprint Backlog is work and is owned by the developers
The Sprint Backlog is the collection of work for the current sprint. It is looked after by the development team (that’s the mini team within the scrum team, made up of “developers” only). The Product Owner has no say over what goes into the Sprint Backlog. The Scrum Master has no say over what goes into the Sprint Backlog. It is up to the developers to choose a certain amount of scope. They decide how much scope and which scope, read the Scrum Guide if you don’t believe me. They can then put it into a sprint and work on it. Once it goes into the sprint, it has turned from being “scope” to being “work” and is now in the domain of the “developers”.
Why is this important?
This distinction is important for various reasons. Firstly, it gives the Product Owner free reign to define the scope for the product, which is good because that’s their job and they have complete accountability for it. Secondly, it gives the developers free reign to choose what of the scope to build and how to build it. Most of the “Agile is micromanagement” complaints you hear are because people don’t understand this, and think the PO and the scrum-master get to “tell the developers what to do”. They don’t and can’t (according to Scrum).
Scrum enforces iterations
Scrum enforces iterations. It calls them “sprints”. Scrum doesn’t tell you how long the sprints should be, though suggests they should be between one and four weeks long. It is quite strict about sticking to the iterations i.e. timeboxing them and not going over the length.
Regular timeboxed iterations are good for a number of reasons:
- It improves your ability to predict when things will be delivered. If your sprints are always two weeks and you always delivery 6 or 7 stories in a sprint, then you can roughly figure out when things will be delivered
- It shows stakeholders and team members that you can get into and keep a stable routine
- It improves your ability to use metrics and reporting to find opportunities for improvement. Some metrics are bad but some are good. Read more about this here: Agile metrics – the good, the bad and the ugly
- It will build trust in the process from senior managers. If you don’t keep to regular timeboxed iterations, they will suspect (rightly so) that you are moving the goalposts, i.e. continuously extending sprints where required to fit extra stories in. Which defeats the point. The purpose isn’t to “win points” and “squeeze more stuff in”, the purpose is to set up short regular cadences and stick to it.
Scrum protects and empowers the developers
Scrum gives a huge amount of power to the developers. This is good because they are ones actually doing the work. That’s not to say that the scrum-master and product owner sit around doing nothing. They have plenty to do. But fundamentally, Scrum is a process for developing working software, and the developers are the ones developing the working software. The job of the product owner is to describe some series of problems or value statements that can be solved by working software. Of course if there’s a quick cheat way to do it without software, do that instead!. The job of the scrum master is to remove anything that stands in the way of the developers from building the software. The job of the developers is to build the software.
If you hear stories about scrum teams that are micro-managed, pushed around and told what to do by managers, consultants, stakeholders, or anyone else, they are not following scrum. The scrum guide is explicitly clear on this:
- the developers choose what work goes into the sprint
- the developers choose who does the work i.e. which developer does which task
- and the developers choose the way in which the work will be delivered. If you don’t believe, go read the Scrum guide.
Empowered teams are successful and happy teams. Empowered developers are successful and happy developers. This isn’t hippy mumbo-jumbo, this is what decades and decades of research tells us. Go read Drive if you want to read more about that.
Scrum puts business and technology together
One of the best strengths of Scrum is the fact that the product owner is in the same team as everybody else. That might not seem like much but it is huge. It helps break down the artifical barriers between “business” and “technology”, it reduces communication loops between the stakeholder (or stakeholder proxy) and the people doing the work, and it gets away from the awkward finger pointing and blame gaming that can go on if projects go wonky.
The product owner is part of the scrum and the scrum collectively own responsibility for the success or failure of the work. It is important for the product owner to understand and accept that. The product owner has to be part of the team, attend all the rituals, go to the standups, and so on. If the product owner won’t or can’t, get a new product owner or disband the scrum. This is crucial.
Scrum is extremely simple
Scrum is a simple framework. It basically consists of three roles (Product Owner, Scrum Master, Developer, that’s it), four rituals (Sprint Planning, Sprint Retrospective, Daily Scrum, Sprint Review), and three artifacts (Product Backlog, Sprint Backlog, Product Backlog). There is also a lightweight set of rules about how those roles, rules and artifacts work and who can do what. That’s about it. And that’s one of the key strengths of scrum: you can learn it quickly. Sure it takes a lifetime to “master”. But to be honest, a lot of the mastery around Scrum is mastering either things that are abstract and not in the Scrum guide. Things like people skills, emotional intelligence, coaching and influencing. Or specific technical practices (TDD / BDD, CD / CI) that are not in Scrum either.
It does not take years to master the rules in the Scrum guide, it takes months or less. You can pick it up, learn it and apply it quickly and easily.
Scrum encourages (some) good agile practices
One of the strengths of scrum is that it encourages some good agile practices. More specifically, it encourages:
- business and technology working together, by putting the product owner in the scrum team
- inspect and adapt, by enforcing a regular sprint review, where the increment is inspected, and that information used to inform further work
- continuous improvement, by enforcing regular retrospective, where the team try to improve not what they have built (that’s the sprint review), but how they work.
These are all good practices and essential to Agile ideals. However some would say that Scrum does not go far enough, and does not mandate some of the more specific technical practices that say Extreme Programming does, such as Test Driven Development or Pair Programming. This deserves a blog post in its own right, but my take is that Scrum probably goes not far enough in this area and Extreme Programming probably goes too far. Nobody should force you to do TDD or Pairing if those don’t work, aren’t suitable or aren’t effective. Do what works!
