This article is part of the “No dogma” series. Do not forget to read the other articles on this topic.
As I wrote before, I spend much of my time reading stuff from pm.stackexchage.com (PMSE). A typical question on PMSE goes like this (not a real question, but close):
My team and I are doing Scrum, and we are going well most of the time, but it happens that we fail to complete all the stories planned for the current Sprint. In this situation the story is rejected and sent back to the backlog. When we do so we stop working on the item, then we have a Sprint Review Meeting, a Sprint Retrospective, (a weekend) and a Sprint Planning Meeting that inevitably re-plans the story for the next Sprint. Only then we can finish the job. Since our stakeholders do not seem to need a precise synchronization point exactly every two weeks (we do 2-week Sprints), I don’t quite see the interest of keeping this fixed timebox for Sprints in our Scrum implementation. What am I missing? Why should we keep using fixed timeframes?
and a typical (and caricatural) answer is like “Scrum uses fixed timeboxes. This is how we do“. This is what I call the massive lobotomy of guru/dogma-driven thinking.
I’ve already talked about it before, but I wanted to be more explicit here. So if you allow me this Morpheus-style statement, my answer to this question would, in short, be “Free your mind”.
Let’s forget about Scrum just one minute. Let’s even pretend that Scrum does not exist at all and assume that the question is more like
My team and I implement an iterative, agile-minded, software development process with fixed timeboxes for each iteration. We are going well most of the time, but it happens that we fail to complete all the stories planned for the current iteration. In this situation the story is rejected and sent back to the backlog. When we do so we stop working on the item, then we have an iteration review meeting, an iteration retrospective, (a weekend) and an iteration planning meeting that inevitably re-plans the story for the next iteration. Only then we can finish the job. Since our stakeholders do not seem to need a precise synchronization point exactly every two weeks, I don’t quite see the interest of keeping this fixed timebox for iterations in our process. Should we keep using fixed timeframes? Why?
An obvious answer is now : “You’re right! If you do not need fixed timeboxes for business reasons and think your team can deliver new features continuously with a more floating deadline, why not giving it a try? Just be careful that your team does not work on too many items at once and still focuses on finishing them, now that the deadline pressure has been released.” You are about to invent Kanban!
I’ve talked about Scrum a lot here but that is not my point. What I am trying to say is that every dogma once was just a solution to a particular problem that their guru, who was just a simple software development manager then, tried. Then the guy thought “Hey! That is working pretty well! I’m sure many other teams could use this method as well” and he became a consultant, wrote a book, animated training camps and master classes, launched certification programs, etc. Little by little people, followers, adepts have forgotten the why part, the very reason why the now-guru has tried it for the first time, and started focusing on the how part. They stopped thinking by themselves. They just wanted to implement the new method. We have to do it like this. It’s written in the book. The Certified Coach said so. Etc.
Think by yourself. Try things. Learn from your mistakes. Become the next guru…
If you read this article down to this point, you definitely want to read Pawel Brodzinski ‘s Agile Bullshit: Agile Thought-Leaders Know It All : quite the same topic, but treated by a much more experienced project manager than your humble servant.
2 thoughts on “The massive lobotomy of dogma-driven thinking”