The shackles of Bad Scrum!

Just a few days ago, I had another conversation with a developer who got in trouble because he was complaining about Scrum. Before you say, "He's uncooperative - fire him!", let me tell you just a little more: This person has worked in agile teams for years and truly enjoys working in an agile fashion. He was just one more victim of Cargo Cult Scrum - adopting the form of Scrum, without any agile substance beyond.

I need to deal with the aftermath of Cargo Cult Scrum very often - indeed, so often that I feel compelled to write this post. It's the shambles I have to clean up after inexperienced Certified ScrumMasters have wreaked havoc in organizations.

Developers confine to me how their CSM's mess up the team rather than supporting it and how they reinforce and cement traditional cultures rather than fostering agility. I rarely hear stories about great Scrum that makes a positive impact on the world of work, yet I frequently listen to complaints how Scrum messes up functioning careers, teams, structures and organizations. How Scrum makes intelligent, creative people miserable - how it messes up successful organizations - how it turns great products into trash - and why people would "rather not".

Please note that while none of these problems are inherent to Scrum, they are so widespread that it is safe to say they are associated with modern Scrum.

If you see one or more of these in your organizations, there is a high chance that the brightest developers are either preparing their next career move or have done so already:

Dogmatic Scrum

Scrum is enforced based on the Scrum Bible ("Scrum Guide"), in complete disregard of the outcome. Rather than identify communication impediments and help the organization resolve these impediments, Scrum itself becomes the biggest impediment towards collaboration. For example, the ScrumMaster might prevent non-team members from providing essential information outside the prescribed ceremonies.

Key question: "Which problems are we solving with Scrum?"

Command and Control Scrum

The ScrumMaster wants to know who is working on what, checks progress, assigns work - and might even go as far as defining the content of Retrospectives for the team: The team has to do Scrum the way management wants. Scrum is enforced top-down, but isn't supported bottom-up.

Key question: "How much does the organization outside the team change when the team needs it?"

Meeting Madness Scrum

Scrum is being abused to fill the developer's calendars with standard recurring appointments, yet developers don't see the value of these ceremonies. There is no valuable outcome of the meetings, so they end up being distractions from work instead of supporting the work.

Key question: "What do you personally get out of each of the meetings?"

Masterless Scrum

The ScrumMaster conducts ceremonies, takes busywork (e.g. setting appointments, writing post-it's etc.), but does little to advance the team. Team members don't understand why the ScrumMaster is even needed, much less why they should receive more than minimum wage. This version is typically associated with cross-career path ScrumMasters who have no understanding either of personal coaching nor of the team's domain, i.e. software development.

Key question: "How well does the ScrumMaster help the team identify and overcome engineering challenges?"

Non-team Scrum

The team is composed of people doing work towards a shared objective (or, even worse: on a common backlog without a shared objective), but the team doesn't grow - much less grow together. It's just a group of individuals working on the same topic.

Key question: "How far would you trust your team mates?"

Silo Scrum

Scrum is done in Development, yet not in collaboration with other organizational units. In the worst case, we see "Water-Scrum-Fall" where a Scrum team implements work defined by an Analysis team and hands that work to a test team. It's bad enough already when developers are isolated from business stakeholders and have no way of communicating directly.

Key question: "How close is your relationship with your stakeholders?"

Hamster Wheel Scrum

The team is pulling through a neverending list of work items, and when one is done - the next item needs to be done. There is no time to breathe, no room to advance in skill, mindset, character.

Key question: "When you look back 1 year - how much have you advanced?"

Traditional Planned Scrum

Scrum teams are being assigned work from somewhere in the organization rather than deciding what needs to be done. Scrum teams are just the execution factory of a classic separation between "planners" and "doers".

Key question: "To what degree are you in control of your work?"

Visionless Scrum

Team members do work, but don't understand the "Why". They are unaware of the long term goal they are working towards. Nobody cares how well developers understand how the work affects others and what difference their work makes.

Key question: "Why do you go to work every morning?"

Mediocrity Scrum

Ever heard about T-Shaped people? Force specialists to abandon their competitive edge by working on tasks outside their expertise rather than invest time into keeping ahead of the game. Press geniuses and luminaries into the mold of a jack-of-all-trades, and you're well set for mediocrity. Your team may deliver more, yet the outcome will deteriorate.

Key question: "Am I getting closer to mastery in anything that matters to me?"

What should you do?

Search yourself for the answers to the above questions. When you find the answers to the above questions unsatisfactory - do something about it! Depending on why and how long this is happening, the chances quickly wane that your Scrum can still be remedied. The first step is to have an open conversation. If you can't fix it, you need help:

• If you are a ScrumMaster or Product Owner and discover that you're stuck with Bad Scrum: get help from an experienced agile coach!
• If you're a team member who is stuck with Bad Scrum and can't find a solution - don't hold your breath. Try talking to a real coach outside your workplace to discover how to move forward: It doesn't even have to be an agile coach.
• If you're a manager and see Bad Scrum around you - bring in a seasoned management coach, and expect that coach to work with you first!

Conclusion

Bad Scrum doesn't make anything better. It creates a mess. It's your choice what to do with that mess. My advice is: change the company - or change the company!