SCRUM is awesome.
We love it for its clarity and the invaluable help in the war against waterfall (not that waterfall is so bad, but this is a topic for another post). Scrum makes things somewhat easier – we don’t have to plan two years ahead, we don’t need to write specifications, we just code and get things done. Wonderful, isn’t it?
SCRUM is probably the most popular Agile project management method. Yes, but it doesn’t work. If we want to be precise, Scrum is actually a framework, but this is a long discussion, so we will skip it.
Before the armies of SCRUM-warriors go after me, I’d say that it works, but only to some extent. I find SCRUM somehow artificial as if it is forcing people to do things without too much understanding. The authors of Scrum are amazing people, and I believe that they have done the right thing at the time, but things have changed since 1990.
If recipes worked back then, engineers nowadays need something different. They need a purpose in their work, they need to be heard, to be part of something bigger. Unfortunately, SCRUM is just a recipe and its days in its pure form are numbered.
After this traumatic and overly-negative prediction, let me share why I say what I say. I will talk about the three Apostles that betrayed SCRUM and because of which the IT society crucified it.
Apostle #1: The Roles in Scrum
Surprising, isn’t it?
Many claim that the clear role definitions are one of the best things about Scrum. Well, I don’t buy that. I believe in self-organized teams where we don’t need roles, but rather contributors. If you have a great idea – go ahead and share it. You don’t have to be a product owner to generate great ideas, right? You don’t need to be a Scrum master to be a guardian of the process, right?
Focusing the entire responsibility on something into a single person (or even two or three people) leads to the trap of “this is not my job” attitude. Instead of figuring out ways to involve everyone in what we are doing, we are creating silos and artificially dividing the team.
It’s not the Scrum master’s responsibility to chase down people who are late for the daily stand-up, neither is the product owner’s responsibility to check that the software works (usually at the demo meeting itself). It’s the team’s job to make things work and the sooner we start helping each other, the better. So let’s have a better stand up meeting.
Apostle #2: Commitment
Managers love that. I mean the old-fashioned managers (with all my respect for them). They need to know that the team is committed to delivering what’s in the backlog. I used to be a manager of a Scrum team (for a very very short time) and I loved the feeling of security that the commitment gave me. I could sleep tight knowing that my guys will do whatever they have to do to get the items out.
You know what? That sucks. I need to know that my team will do whatever it takes to keep the product in a good shape, that we will not let our technical debt grow, that we will be super-fast to address customer issues and that we will help each other when things go bad. I don’t care about the commitment, not at all.
Moreover, if a team fails to deliver what they have committed to a few times in a row, this will almost certainly make them commit to less next time. Just in case… you know?
p.s. I’ve heard that the commitment was gone from the latest SCRUM guide, but I never cared enough to actually go check that myself.
Apostle #3: The Failed Sprint
I can write a book on this topic alone, but let’s not bore the audience to death. I will be short here.
THERE IS NO SUCH THING AS A FAILED SPRINT
Whew, now I feel better 🙂
If the team was able to move their stories or features one step closer to completion, if they’ve learned something, if we are better prepared for the next release – this is not a failed sprint. This is a failed plan of a sprint. We know that planning is by definition imperfect and the only thing we can do is to learn to plan better.
But, please, let’s not blame our team for failing the sprint, shall we?
You don’t agree with me? I would love to hear your feedback in the comment section below.
If you want to find out more, check out this infographic about Scrum and Kanban.
Happy Kanbanizing!
Kanban vs Scrum seems more of a religious dispute. Here is the counter opinion. 🙂
Thanks for the comment Krasimir!
For some reason the link to the article is not displayed correctly, so there it is: http://scrumcrazy.wordpress.com/2013/02/04/kanban-vs-scrum-kanban-is-not-for-software-development-but-scrum-is/
I think there is value into what Mr. Bradley is saying, but Kanbanize is the living proof that you can do product development by applying Kanban only. Scale does matter though and we will talk about that a lot when the new features that we work on right now come out 😉
Cheers,
Dimitar
Pingback: Who Betrayed SCRUM? | Kanbanize Blog | Agile | ...
Pingback: From SCRUM to Kanban HOW-TO | Kanbanize Blog
“If you have a great idea – go ahead and share it.”
Indeed, but with a plethora of great ideas you need someone to make the priority call, which ones get included. That is why you have a Product Manager. I think you are caricaturing the roles here.
“They need to know that the team is committed to deliver what’s in the backlog.”
I think you misunderstand the backlog. The backlog is a big unordered list of all the things that could be done. The agile process ensures this list is reviewed and the priority items are defined and then put into sprints. Nowhere have I read that the entire backlog must be committed to, and nowhere in my practise have I required commitment to the backlog. Developers commit work to sprints, but implicit in what work they commit to are the things you believe they should commit to. Technical debt needs to be in the backlog too!
I’m not sure what your last point about failed sprints relates to. If you blame your team for not achieving its goals for a sprint, you are telling them they have failed. That is bad and I agree. However, you can fail to achieve your commitments to a sprint which triggers one of two things, either you stop mid sprint and replan, or you do a quick post mortem to identify what happened. This is not blame, this is course correction. This is not failure per se, but an opportunity to understand better the blockers the team have.
It is legitimate to engage the team in an analysis of why it didn’t achieve its commitments because you are typically only defining one or two week’s commitments and if you’ve done collaborative planning you should have a pretty good idea of what you can commit to.
The implication otherwise is that we should not ask for commitments at all, just let the team work.
If you have the right team, that is the best way to go. If you do not, you need to be explicit about commitments because it’s important if you want to grow them into the kind of team where, yes, you don’t have to ask them to make specific commitments.
Good stuff Adrian, thanks for commenting!
I do agree with all that you say on a theoretical level. My point though, is that in reality things are rarely as they should be.
Quite often we have the PO not prioritizing all great ideas but rather pushing on theirs, just because the team does not feel empowered enough to contribute.
Regarding the backlog, the word is misused, I agree (and I will fix it). My point is more general, that the team commits to work on what is to be done, but you are right, the usage of the word backlog is not proper in this case.
What you state about the failed sprints is the perfect case scenario and if everyone out there were doing what you suggest, I wouldn’t be writing this article. My point is that teams often “fear” committing to stuff, because they may “fail”.
Still, good stuff!
You have made a great job and I find the use case model very useful I am impressed by your lectures. Please, can you let me know your email address for I would like to speak to you with regards on Scrum Process. I recently read about this new agile methodology. I found similar articles in this http://www.scrumstudy.com/scrum-principles.asp I read it twice with the modified version of Scrum and Agile Method. I believe it will help you as well. I believe you have covers more on Scrum.
Hi there,
thanks for reaching out and for the kind words about our post!
Please get in touch with me with what you have in mind and I will be sure to route you to the right person to speak to about it.
My email address is monica@kanbanize.com, you can reach me there at any time.
Cheers,
Monica