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?
Yes, but it doesn’t work. 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 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 about 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 into 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.
Apostle #2: Commitment
Managers love that. I mean the old-fashioned managers (with all my respect to them). They need to know that the team is committed to deliver 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 to 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 learnt 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 comments section below.
… and happy Kanbanizing!