We’ve all seen it – Scrum Gone Bad
I think we have all seen Bad Scrum and misuse of the Scrum Framework. Sometimes Scrum started out well with a solid understanding of Scrum, good leadership, an effective Scrum Master, an engaged and empowered Product Owner, and a hopeful and open-minded Dev Team.
But then somewhere along the way it went bad. Maybe the leadership changed or changed their mind. Perhaps the skillful Scrum Master left and was replaced by one who was ineffective. The team may have soured or felt like Scrum was used against them.
Other times, Scrum was just bad from the very beginning. Managers used the Scrum Framework against people. Tools like Jira were used to monitor and control Team members.
Teams were told to self-organize and then assigned work, or given fixed scope and fixed timeline commitments. Project managers were anointed as Scrum Masters, skipped the training, and then allowed to do what they thought was best.
How Bad Can Scrum Get?
The situation has gotten so bad that people are getting hurt by it. Some new terminology had to be introduced to describe it. Ron Jeffries, one of the original 17 signatories to the Agile Manifesto, coined the term Dark Scrum in this popular post.
Agile Leadership guru Michael Sahota refers to it as Weaponized agile, perhaps inspired by Chicago’s own Mike Marchi who coined the term Weaponized Scrum. Ryan Ripley also wrote about it years ago in Bad Agile Management Burns Scrum Teams.
My heart goes out to all parties involved in Bad Scrum. When Scrum is bad, no one is happy or sees the benefits of Agile and the Scrum Framework that they have hoped for.
Instead, there is pain, frustration, despair, and a quiet sense of resignation. Good people leave. Trying Scrum again for the second (or third) time is something few have the will or courage to attempt.
We Fix Bad Scrum!
And I’d like to help, somehow. I’m optimistic about even Bad Scrum succeeding when given a fair chance and when implemented with proper training and support.
It doesn’t work everywhere, but it does serve as a great tool for making organizational problems (like those noted above) visible so that people with courage can address those impediments. I truly believe that Agile and Scrum remain the best way to organize and deliver results.
The situation reminds me of signs I’ve seen over the years “We Buy Ugly Houses”. It seems that no matter what shape the house is in, someone is willing to buy it. It is that sense of optimism that attracts me.
How To Fix Bad Scrum
Fixing Bad Scrum is not trivial, but I think it is achievable. I would start by focusing on the following:
- Make sure Leaders in the organization understand and embrace Agile, Scrum, and the underlying Lean Principles. Confirm they are willing to go first and lead by example. If not, then there is little need to try to fix the bad Scrum that will inevitably go on there.
- Are leaders willing to attend training?
- Are leaders going to train everyone including teams, Scrum Masters, Product Owners?
- Will the leaders hire coaches?
- Work with the Scrum Masters, Product Owners, and Dev Teams to help them leverage the Scrum Framework as it is described in the Scrum Guide. Teach the “WHY” behind all the events, roles, and artifacts. And I know it may sound retro and simple, but the Scrum Guide can be used “As is” without a bunch of fine-tuning or local optimization.
- Apply Empirical Process Control
- Make Everything Transparent
- Support Teams to Self-organize
- Develop Effective and Skillful Scrum Masters (see our related post Hire Better – A Scrum Master Hiring Guide)
- Don’t fall for the trap of hiring Agile Project Managers rather than Scrum Masters
- Focus on Creating High-Performance Teams. Rather than simply assembling a group of people and labeling them a team, I would strive to create high-performing teams.
- Coach on self-organization and empowerment
- Aggressively co-locate the teams and keep asking why if I get pushback
- Confirm that teams are truly cross-functional and have all the skills needed for end-to-end delivery
- Make sure the teams are appropriately sized – 3 to 9 team members with a preference for smaller rather than larger teams
- Counterintuitive ideas about high performance like those described in this blog post – Slack Time Helps Create High Performing Teams
- Don’t use Scrum in ways it was not intended! Of course, there are too many of these to list here but a few examples include have been identified in other blog posts that we’ve written:
What do you think? Do you see the Scrum Framework being used and abused? What is the Bad Scrum that you see being practiced? Are there other steps that could or should be taken to fix bad Scrum?