The other day I got my hands on the Scrum Guide 2011. It’s a updated version of how Ken Schwaber and Jeff Sutherland looks at Scrum, it’s practices and state today. It’s well worth a read – especially if you haven’t read up on Scrum in a while.
And let me here in the outset of this post also state that I have use Scrum a lot and it helped me and my teams a lot as well. I like Scrum to be short – but (had to be one right) I think that some situations doesn’t fit perfectly with Scrum.
After that short side note, let’s get back to the real thing. After I read the article I had an opportunity to sit down with Morgan Ahlström, a fellow lean / agile coach here at Avega Group. We started to discuss about the things we read in the document and finally arrived on the question; can Scrum, as described in the document, actually be done?
The rest of this blog post are inspired by Morgan and written by me. Any strange stuff and faults are just my own and any great stuff is probably Morgan.
It’s Scrum ™ or it’s not
The conclusion section of the Scrum Guide 2011 states (my highlighting):
“Scrum is free and offered in this guide. Scrum’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.”
So if you call it Scrum ™ – it has to be done exactly as described in the Scrum Guide 2011, or at least with all the practices described therein, additions are welcome. If you are not – then it’s not Scrum. Simple and to the point.
The guide starts with stating that Scrum is lightweight, easy to understand but extremely difficult to master.
When Morgan and I discussed this we asked ourselves what was the best Scrum we’ve seen was like? Between us we have about 14-15 years of Scrum experience. Sadly the best Scrum at least I’ve seen didn’t do all of the prescribed components of the Scrum framework, and the same was for Morgan.
Common Scrum Pitfalls
We went back and forth and started to list the most common deviations from true Scrum ™ we’ve seen. Not that this only based of our experience and I would be happy to be corrected on this.
This is our short list:
- The product owner is an unicorn
- Deliver business value each iteration is hard
- Not doing retros and not following up on actions
“The product owner is an unicorn”
This heading is actually a quote from Torbjörn “DrunkCod” Gyllebring said at LeanKaffeSump gathering in Stockholm. The reasoning behind it is one that I supports to 100% – a product owner (as described in the document) doesn’t exists. And for that matter – do we really want one?
The product owner should be “The Product Owner is one person, not a committee” that in order to succeed “… the entire organization must respect his or her decisions”. Among the product owner responsibilities are:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Ensuring the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next;
- Ensuring the Development Team understands items in the Product Backlog to the level needed
Man – that’s one steep order indeed. So she is to understand the business well enough to be the Development Team’s (new term in Scrum 2011, to my knowledge) single source of truth in questions about the product. And then to be able to prioritize the backlog according to business value on such a fine grained level that the items fit in a Sprint or less.
I have never met a Product Owner ™ to that definition. I have meet proxies in front of a group of people that together constitute those skills – but then you loose the speedy communication needed in short sprints and an agile projects.
I’ve also met PO that hold a lot of these properties but doesn’t care about the low level stuff that the team cares about.
I have never been in a project where the PO was close to the team physically. One floor above is the closest I ever got, but then it was an IT-person that proxied some business users.
I cannot help but making yet another connection here. I am very much into Specification by example and one of the early questions or remarks that Gojko Adzic makes is that many teams expect their customer/product owner to create the backlog for them. That is bad since you in essence ask the customer to design the system for you. It’s much better to harvest the whole teams collective knowledge and write, prioritize and create the backlog items together. The customer can then input and guard that the business values not get lost but leave the discussions of solutions to better suited people in the team.
Not doing retros and not following up on actions
The second most common pitfall or inability to live up to true Scrum is to do retrospectives. This is probably the most important meeting but is so often down-prioritized and skipped. I don’t know why it’s skipped actually, but I think that teams fail to see the possibilities to change and improve their process.
And even if the team are doing retrospectives the actions that comes out of them are seldom followed up or implemented. Common causes for this, that I’ve seen, are the brick wall of the organization in which the Scrum team are acting. This is not Scrum ™ fault per se, but Scrum doesn’t give much advice and help on how to be better in doing this either.
Deliver business value each iteration is hard
Another thing that is very common is that the deliverables is not of business value each sprint.
- You have to do upgrade a database
- a new version of the ORM-mapper has been released and need to be integrated in our code base
- in order to squeeze the user story into a single sprint we mock out the external dependencies (and do it “for real” in the next sprint)
These are all example of things that is not of business value but still needs to be done. And after a while the requirement of the stories being of business values easily fades a way, leaving the product owner behind. Maybe even the team start to decide that “a new database” will give us business value.
This is not at all what Scrum intended but I’ve seen it happen in many of my teams. Again and again. Probably reflect my coaching skills – or is it just to hard ro do?
Scrum as a –ism
Putting all of these together and I must ask if Scrum has become an “-ism”? To clarify my thinking I will take you back to a project I was on about 5 years back. On that particular project we had a Swedish girl that was very left wing indeed and a guy from Cuba. The Swedish girl was convinced that communism could work and you can guess what the Cuban guy thought about that… having fled the country as just one example why he hated communism.
That discussion had me thinking – the basic ideas with communism is not bad, right? It just cannot be implemented right. Or to put it another way; show me the best implementation of communism in the world – and I’ll show you a dysfunctional country, a ruthless leader or other horrible things. It’s an idea that’s good but it doesn’t work. In reality. On humans.
Ok – quickly out of the politics (I hate politics) and back to Scrum. Is Scrum an –ism? A great idea that simply cannot be implemented (correctly, Scrum ™ style). In reality. On humans.
And does that matter?
Is ScrumBut bad?
Scrum-but is a term that is used to describe Scrum implementation that does some of Scrum BUT not all.
- “Yes, we do Scrum … but we don’t have PO”
- “Yes, we do Scrum … but we don’t do retrospectives”
- “Yes, we do Scrum … but we don’t deliver business value each sprint”
The term is, of course, frowned upon by the Scrum community. But is it really bad?
Take 100 projects. Say that 80 of them failed. Some are probably not using Scrum, some are probably using Scrum-but (parts of Scrum). And some are probably using Scrum ™. Yes – good people, you can fail using Scrum.
And the 20 that succeeds. I bet you that not all of them are using Scrum. I’ll bet that some of them are using Scrum-but. And some are probably using Scrum ™. So where does that leave us? It’s seems like it doesn’t matter if you use Scrum ™ or not. It seems like you can fail and succeed either way.
Yes – but the important thing is what you do with that failure. I have from time to time called Scrum and other agile methods “problem finders”. They are used to find problems in your organization. But from there you have to intervene and DO SOMETHING ABOUT THE PROBLEM. You (the team) are the only one that can act and improve.
That’s the important thing and the way I sum up agile; get fast feedback and act upon it. Scrum ™, Scrum-but, Non-Scrum or Kanban doesn’t matter – what you do with the feedback does.
Conclusion
So if you cannot do proper Scrum ™ as described in the Scrum Guide 2011 – why is it important? It isn’t! Not to us that is – it probably is if you have invented Scrum and are making a living of it.
Scrum ™ can also be used as a nirvana state. A goal we’re striving for but never reach. And on the way Scrum-but can be used.
That’s my two cents on the subject. Hope you got something out of this discussion.