I love Scrum. There, I said it. Yes, I know I am a married man, and I should not have another love next to my wife, but it is true and I am proud of it: I love Scrum. Every time I read the Scrum guide, I get butterflies in my stomach. It is like that one hot summer back in your teens, experiencing your first summer love. I love it. I may even be addicted to it. Last year, I wrote a blog about the Zombie Scrum apocalypse. I wrote about how we all should fight it. Heal the Scrum zombies and return to the heart and soul of Scrum. And to the butterflies in your stomach.
Why do I love Scrum so much? Because it is a clearly defined project management methodology which everybody can understand. It is simple, clever and it has a simple and down-to-earth goal: deliver a working product. Every sprint, again and again and again. Everybody can understand the basics of Scrum as described in the Scrum guide. It can be applied to all sorts of projects. Not only software development benefits from it, but every organisation looking to deliver a project can use it.
But I must face the facts. As appealing as Scrum may be on the first, second and third read, there are some caveats. Every organisation is different and runs into its own problems when implementing Scrum. Last year I described some issues like teams going through the motion of Scrum, but missing out on its core. Sure, they deliver a working product. Sometimes. They have a Scrum Master too – running multiple teams by the way, but hey, how hard can it be? They have a Product Owner, who acts as a project manager but also likes to dive a bit into the requirements (not too deep though, the ‘team’ has to create the product, right?). And this is just naming a few of the problems that Scrum teams run into. I can imagine you can come up with more.
According to many Scrum enthusiasts like me and many Agile coaches, the answer to these issues will be: more Scrum! And that is not a bad answer. If you have the time, the dedication and a motivated team, you will get there eventually. But it takes a lot of courage and a lot of blood, sweat and tears. It is no longer like that summer love. It is turning into a hard-working marriage. As a Scrum enthusiast and married man, I can tell you that both are very much worth working hard for. It is very rewarding to see a team blossom in a healthy, living Scrum environment.
Now, what I am going to try to say in the next two paragraphs is a bit like swearing in a church. I have seen a lot of organisations doing Scrum. I was hired to join a team as a tester for a short period, usually six months to one year. I have tried to help development teams to do Scrum, but I am not a wizard, and I cannot change the ocean steamers that most teams are and easily turn them around. What I saw was that most teams have adopted Scrum and are working reasonably well according to the Scrum guide. But they also sin quite often against the Scrum bible. They prolong the sprint by a few days to get something extra done. Next to their development work, they do some unplanned operational stuff. They allow the Product Owner to function a bit more as an old-fashioned Project Manager, because that works for them.
So I came to think: maybe, just maybe, we must loosen the leash a bit and let teams adopt Scrum, but also let them be a bit pragmatic in the way they implement it. Sometimes it works better for the bigger organisations if the Scrum Master or Product Owner acts a bit like a Project Manager. Some teams also need to do some operational stuff. Let them do it. Maybe even plan a certain amount of story points for it every sprint. Let them prolong the sprint a few days every now and then to be able to really deliver a quality product. What I am trying to say is: let us not be too dogmatic about Scrum, but let us be a bit more agile about it. But whenever you do so, discuss it with the team first and look back on it in the Retrospective to see how it worked out. Because without communication, even pragmatic Scrum is doomed to fail.
Am I wrong? Feel free to respond to me in the comments section below.