Scrum is good, Scrum is bad: planning
Both biggest strength and weakness of Scrum
Both biggest strength and weakness of Scrum
Cet article est également disponible en français.
Planning is at the very heart of Scrum. In Scrum you plan pretty much everything. And when you can’t plan properly, well obviously you don’t force obtuse planning but instead you update the plans as often as needed.
Look, I think I can easily coin “plan” into the description of everything that is related to Scrum.
Product Backlog: plan what the product will be like
Product burn-up: plan when the product could be out the door
Sprint Planning: plan what can we expect by the end of the sprint, but also plan how each item will be proceeded on
Daily stand-up: plan for the day and update the plans made in Sprint Planning
Sprint burn-down: check how accurate the plans made in Sprint Planning are, and if necessary adjust both plans made in Sprint Planning and plans for the day
Sprint Review: review and update the plans about the product and about when it could be finished
Retrospective : plan how the team could improve
Let’s say that Scrum is all about planning. What’s your point?
First I’m not saying that this is bad. I just want to warn you that it can be bad.
Scrum is old now. For many, Scrum has been the main entry-point into the Agile world. Well, vanilla Scrum is still a very good way to start an Agile transformation.
I’m adding the word “vanilla” because much too often Scrum is not properly implemented, leading to disappointing results and the idea that Scrum is just the old way of doing dressed up with fancy names. I have already discussed this idea at length in a previous rant.
Actually, Scrum is the main Agile software project management method used, and by a long shot.
But how come that Scrum has gained such a popularity? Exactly because it relies on planning.
Properly-implemented Scrum do not share much with waterfall. However, Scrum is very compatible with “the old way of doing”.
For instance instead of a single hard date for the end of the project, you provide a possible range of dates and you update the range at each Sprint Review. But the core idea stays the same, trying to answer to the following question: “When will it be ready?”
Why am I bothered? Think about it, there are many other interesting questions that could use some attention. For instance, why not trying to answer to this one instead: “How will we delight the customer?”
The answer to this last question is not just about the content of the product backlog. Because one of the hardest parts is to find out how to delight the customer. You simply don’t know what to put in the product backlog, instead you must devise strategies to find out. This is Lean Startup and Getting Real territory.
Keep in mind that you’ll get what you’re after. So start by looking after what you really want.
I’d be surprised if shipping an arbitrary product by a specific timeline is what you really want.
Scrum is about empiricism…
Scrum Theory
Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk.
Scrum is a huge improvement over waterfall because everything is done to reduce the delay before getting feedback and acting upon it, and because it embraces the empiric, unpredictable nature of software development projects.
Or does it? Is embracing the unpredictable by doing lots of planning, actually embracing unpredictability?
Well, writing this last sentence made me double-check on the quote from The Scrum Guide a few paragraph earlier. Indeed, Scrum do not claim to embrace unpredictability. I did make up this one. Scrum only claims to make unpredictability more manageable.
Scrum is an improvement over waterfall thanks to iterative development but the fundamental mindset is not that different.
In the end this post was just meant to bash Scrum, right?
Oh, hell, no! Bashing Scrum is not my point.
My point is, Scrum is really great to get started, but at some point you should check if Scrum is still helping you or if it is getting in the way.
Also, Scrum has never been intended to be the one-size-fits-all solution that the industry seems to think it is. Have a look at the Scrum Team pre-requisites from The Scrum Guide — they are often ignored:
The Scrum Team
The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity.
In other words, Scrum teams are meant to be Feature Teams, teams that can handle a complete project from end-to-end, on their own without any dependency. Many, many “Scrum” implementations simply do not fit this pre-requisite of Scrum.
Let’s say you do not fit this canonical Scrum Team definition. Using Scrum as a learning tool is OK for me. But then you definitely should keep in mind that Scrum is just a learning tool for you.
The organisation around the team
That’s where the crunchy bits are: in the organisation surrounding the team, interacting with the team, requesting things from the team.
Again, Scrum is great at first because the basic contract between the team and the organisation do not need any significant change. Sure the Scrum Master and the Product Owner will educate the stake-holders, the partners and the customers. But the fundamental contract stays the same: “When will things be done?”
Indeed, the way the question is asked and answered will be done in a healthier, more transparent way. But that’s still the same question.
And by sticking with Scrum, there is no incentive to work around that fundamental contract of “When will things be done?” No need to change it.
Enter Kanban: welcome to the world of pull
Process experts like to describe and compare Scrum and Kanban by using the words push and pull.
In Scrum things are pushed to the team and into sprints in order to get a product at the end.
In Kanban the team pulls things at their own rhythm, resulting in a product when the team is done.
Such a fundamental change of mindset completely shifts the behaviors of everybody, both in and out of the team.
In push (Scrum), the team struggles to find its rhythm, being as fast as possible while avoiding to neglect crucial elements like quality, improving tools, staying up to date. On the other hand it is rather easy on the organisation.
Push on the team and it will get things done. Does it sound like traditional management?
In pull (Kanban), it is very easy for the team to find its rhythm, since the whole idea is to drive the process from this rhythm. Then, obviously, that’s not that easy for an organisation used to push teams with deadlines.
Pull requires a mindset change from the team, but also from the organisation.
What’s your take on Scrum?
What do you think about planning in Scrum? Is it a good or a bad thing? What’s your experience with it?
Go ahead and hit the comments!
Did you like this article?
Follow me to be notified of my other articles!
And don’t forget to click on the heart 💗 to support me, and to share the article: these like are what makes me putting my heart and soul into writing.
Thank you! 😄