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 ↑
Interesting article and something I have thought about as well. However…. I believe it is vital to remember that truly busy software teams need an outlet to improve and further discuss that improvement. You mention that retrospectives are outdated, but the discussion about change and improvement cannot just happen any time we please or it jeopardizes the entire teams time. Retrospectives give our teams the time and forum to talk about the improvement and decide whether it needs to be added to the team improvement backlog (if it is something that cannot be immediately addressed).
Yes, it could be argued that the standup is outdated, but remember the age and maturity of the team need to be considered as well. A brand. new team or even a team working on a new project NEEDS daily scrum in order to keep the project on course. A team that is 3 years old on the same project could likely forego standup at times, but too many situations necessitate the daily scrum that I would never abolish it.
Great article – I enjoy your blog and visit often. Keep up the great thoughts!
Dan King (CSM, SASM)
Thanks for reading through my article and providing counter points. Usually in a retrospective, per the scrum guide, you evaluate “individuals, interactions, processes, tools, and their Definition of Done” to improve a teams effectiveness. Where I am coming from is if there is a problem in any of those areas, that means there is an impediment. And what we are asking the team to do is hold on to that impediment until the end of the sprint so that they can address it in the retrospective ceremony. What I am advocating for is the impediment should be addressed as they come up just like any other impediment to a team’s work. I haven’t seen this approach be disruptive to the teams work as may have been imagined. In a high performing team, there is very minor adjusting needed anyway, as they have gotten through the traditional three stages of team work (forming, storming, norming) and are in the performing phase of Tuckman’s model. Even in newly formed teams, I think a lot of this can be addressed as they run into it rather than asking them to work through it and address it at the end of a sprint.
On the issue of a stand up, I think it comes down to evaluating how a team is already communicating. The daily scrum’s objective is listed as “Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.” If a team is already communicating that through various online channels like an online sprint board, slack or teams communication, what happens is your daily scrum becomes an update meeting. I’ve seen the most success in these cases where the product owner is specifically embedded with that team and proactively communicating and working with the developers throughout the course of the sprint. Adjustments can be made in real time as they come up rather than wait a day for the next sprint.
All I am saying here is that if you have a highly communicative team, you are achieving the objectives of the ceremonies listed, but in a more responsive way. Where teams fall short in that, then sure, fall back on the scrum ceremonies to achieve that level of communication necessary. I view scrum as a starting point rather than and endpoint. Ultimately the team should evolve to handle the work and environment for that specific team. In that view, I’m more aligned with what is being advocated for in either Disciplined Agile or Amplio Development practices. But thanks again for reading and providing your points. I really appreciate the feedback.