A simple google search will tell you that most of the companies focused on software development exercise scrum as their agile framework of choice. But, at this point, scrum is a framework that is now around thirty years old. It is time to question if the problems that it was initially solving really are still problems now. I contend that with the tools and capabilities we have available now, much of the ceremonies of scrum are outdated.
Sure the scrum guide gets updated every year. But, is that to respond to new tools and way of working? Or is it to keep the framework, and its surrounding cottage industry of consultants, trainers, and certifications relevant?
What is Outdated
Stand-up Meetings
Stand up meetings. In the early implementation days of scrum, having a stand up made sense. You were breaking up the silos and gates of information in traditional waterfall-oriented companies. You needed to have business and developers come together to discuss what is currently going on within the development team.
Now, in contrast to the silos existing earlier, anyone can see what everyone else is working on using JIRA, Azure DevOps, or a physical sprint board where boards always show the work and status of that work. There shouldn’t be a question of what you did yesterday, and what you are doing today. And, if there are issues that come up over the day, a truly agile organization should be able to communicate and collaborate on those issues before the typical cadence of stand-up meetings.
Retrospectives
You may think that retrospectives are a vital part of Scrum, and probably a vital part of any team’s practice, regardless of the framework used. You are right, but what I am arguing here is that a formal ceremony on a regular cadence may stifle change. If a team is responsive, and adaptive, why can’t the team address the needs for change in the moment it comes up? Why wait to propose a change at the end of an iteration? Teams should be able to respond to things in the moment.
The Three Things in Scrum to Keep
Ironically, the three things in scrum that all teams should employ are the things that are not applicable to the framework itself. That is the scrum pillars, Transparency, Inspection, and Adaption. If you want to create your own way to work. Which is something I encourage all teams to do, then hold on to these three pillars. In your process, ask if you have sufficient transparency. Are you taking time to inspect your process and your product? Are you able to adapt either your process or your product to fit the needs of your team and customers? If yes, forge ahead and keep iterating on both your process and your product. If no, change it up. Find better ways that work for your team and your situation.
Scrum’s Achilles Heel
Even though it advocates for adaption, the scrum guide is clear that it is not applicable to the framework itself. It’s an all or nothing approach where if you deviate from the scrum guide in any way, regardless of the benefit it may have for your team, you are no longer practicing scrum. It is something else. In the words of the latest scrum guide, “The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum.”
In a sense, being rigid with the scrum framework makes sense. You need a ridged framework to ensure that everyone has the same understanding in different business industries or contexts. But intentionally limiting teams to a prescriptive process will eventually limit performance.
Why Dogma Though?
The fact that you can’t question the process put in place is what leads me to label scrum as dogma. Is it a little tongue in cheek? Perhaps. Does it work? Sure. Does it go against some of the values of the agile manifesto by being so rigid? Yes. Remember, it is about people over processes. Not that process isn’t important, but if it is sacrificing the good will of the people to uphold something that clearly isn’t working, then yes, you lose agility in that framework. Serving a framework is second to serving the people that do the work or need the work.
What This Means for You
What I am saying here is that scrum can be a starting point for a team, but it shouldn’t be the endpoint. Teams should evolve over time to a process that works for the people involved. This would be living up to the first value of the Agile Manifesto – People over processes. This is also in line with the principle of mastery, Shu Ha Ri where eventually what you start out with doesn’t look at all with what you end up with (because you mastered the underlying principles and adapted your practices to further those principles).
Transparency, inspection, and adaption is meant for the product, the team, and the process used. A truly agile team or organization should consider everything. Not applying those principles to the process itself, like scrum, is a detriment.
If you found this helpful, please share with your colleagues, friends, boss, etc. Also, feel free to start reading my Agile Laws series here.
Thanks for reading!
Agile ↑
