Zombie Scrum

A year ago, your organization adopted the Scrum framework. Scrum helped you break down functional silos, improve communication with stakeholders, increase collaboration on your team and across teams, and facilitate cross-disciplinary skill development among staff members.

It was exciting at first. Everyone was engaged and everyone was enthusiastic.

Stable teams were established, and work was allocated to teams as deliverables were completed. People began to spend their days in team spaces designed as collaborative work centers, rather than sequestered in cubicles like so many hermits.

In every Sprint, teams built trust with stakeholders and learned more about the business domain and the technologies in play than they had previously imagined possible. Delivery effectiveness, stakeholder satisfaction, and team morale improved over the next six months.

Laissez le bon temps rouler

Life was good.

And the clock ticked on. And on.

And on.

After learning all there was to know about the types of work their stable teams carried out, people began to wonder when or how they might get the chance to learn something new. Life took the shape of an endless series of User Stories, mostly comprising the same sorts of changes to the same parts of the same codebase over and over again.

And the clock ticked on.

What about collective ownership? Self-organization? Retrospectives?

Yeah, sure. Collective ownership of the same sorts of changes to the same parts of the same codebase over and over again. Self-organization regarding exactly how to carry out the same sorts of changes to the same parts of the codebase over and over again. Retrospectives in which the same issues are raised time and again, and all the remedies lie beyond the team’s purview. As far as anyone on a delivery team can see, the root cause of the issues is Scrum itself, if not life itself.

Everyone is disengaged and everyone is apathetic.

Like zombies.

Management and business stakeholders don’t really see the problem. After all, delivery is steady and predictable, and much more efficient than it was before Scrum was introduced.

Portfolio and Program teams (or their equivalent by any other name) don’t really see the problem. After all, the delivery teams are accepting prioritized User Stories and delivering them on a steady basis.

If there were issues, the teams would report them, wouldn’t they? That’s the model, isn’t it? The only reason a person would hesitate to report an issue is if they didn’t believe any good would come of it. Scrum is good by definition, so that can’t be the case.

But there’s trouble in the trenches. If the technical staff can’t change their organization, they’ll change their organization.

Send in the coaches

It’s a good thing you have agile coaches to help you! What do they have to say about the situation?

They say things like this:

You’re a self-organizing team! You can figure it out!

• Bring up the issue at the next retrospective. Don’t forget to create an action item!
• If you can’t solve the problem at the team level, escalate!
• Agile people are passionate about their work. Look within and find your passion!
• Stare at this inspirational poster about Scrum until you feel better.

Well, okay, that last one was a little snarky. But only a little. The sad thing is it isn’t too far from the truth. It’s more-or-less the Scrum equivalent of the traditional mantra, “The beatings will continue until morale improves.”

Certification overload

Informally I’ve been told more than 400,000 people have gone through a formal Certified ScrumMaster (CSM) course offered by the Scrum Alliance. On the Scrum.org website, that organization claims over 100,000 people hold Professional Scrum certifications. That’s a lot of certifications.

Why, then, are there so few agile or Scrum coaches who can take it beyond the novice level? It may be a case of “too much of a good thing.”

People who are interested in Scrum but not too sure what it’s all about tend to look for certifications as a form of assurance that they’re listening to the right people. ScrumAlliance and Scrum.org are happy to offer certification programs. Many agile coaches hold the basic certifications from one or both these organizations, and many have experience in getting teams and organizations started with rudimentary Scrum practices. Their career path consists of getting one organization started, then moving on to another organization to get them started, then moving on…well, you see where this is going. Most agile and Scrum coaches have never experienced a situation beyond the initial stages of getting started with agile in general or Scrum in particular. They have not seen the problems that normally occur after a long series of Sprints.

Is something wrong with the certification process? Well, not really. You have to start somewhere. But the base-level certification, Certified ScrumMaster (CSM) is surprisingly easy to obtain. A colleague told us he had his child take the exam, and he passed on the first try. The child had never taken a CSM course, and was only as interested in Things Agile as any other child would be (that is, not very).

The ease with which a person can obtain a CSM credential has led many individuals to take the CSM class who have absolutely no experience in IT. They’ve never written code, tested software, analyzed business problems, managed a project, administered servers or networks, worked with database systems, or worked in operations or production support. When they are coaching a delivery team, they have no way to relate to the practical challenges the team faces. Credit where due: They’re pretty good at sticking things on the walls.

Zombie Scrum is a perfectly normal and predictable stage in an organization’s development. Most coaches don’t know how to advise zombie Scrum teams because they’ve never stayed with the program long enough to see the problem manifest.

And the Scrum literature doesn’t talk about zombie teams. <understatement>It wouldn’t be a very strong selling point.</understatement>

All problems are management problems

Lest you point the finger of blame at underqualified and overcertified Scrum coaches and ScrumMasters, consider the wisdom of the old saying, “All problems are management problems.”

Scrum introduces a few unfamiliar concepts and roles. One of them is the role of ScrumMaster. Managers who have a traditional background often have difficulty with the concept of a ScrumMaster. When we simultaneously introduce the ScrumMaster role and reduce the importance of the traditional Project Manager role, it’s only natural for people to fill in the gaps based on their own experience. They re-title the Project Manager as ScrumMaster.

This mangled ScrumMaster role has two responsibilities, and the two are in direct conflict. One is the responsibility to help the team use Scrum effectively and to support them in their continual improvement efforts. The other is direct responsibility for delivery. The freshly-minted ScrumMasters inherit the latter responsibility from the deprecated Project Manager role, which management still believes is necessary.

Even in the best case, it’s hard to serve two masters. When you have the dual responsibility of delivery and team coaching, the delivery responsibility always prevails. Why? Because it’s often necessary to present challenges to the team to create learning opportunities for them. If you have responsibility for delivery, you can’t do that. You can’t help the team improve. You, yourself, are measured on steady delivery. You have to keep the team running on the treadmill non-stop. You have no choice.

That isn’t a coaching problem, it’s a management problem. Your role is improperly defined.

Can zombies be awakened?

One of the top Scrum trainers and consultants in Europe, Joseph Pelrine, describes a model of team performance he calls the Cooking Model. When you’re cooking, you don’t want the temperature to drop so low that the food congeals into a flavorless mass. At the same time, you don’t want the temperature to rise to high that the food burns. There’s an optimal temperature for cooking. Similarly, there’s an optimal “temperature” for a delivery team. Too much stress, and the team burns out. Too much boredom, and the team members turn into zombies.

Pelrine advises coaches to shake things up when they see the zombie team phenomenon starting to occur. Teams may miss delivery targets when this happens, but it’s all to the good. We want the teams to deliver predictably over the long term. Sometimes, that means allowing short-term variation in delivery performance in the interest of improvement.

Another factor to keep in mind is that most of the guidelines and practices defined in Scrum are meant to be a starting point for teams. As teams progress in agile and lean thinking, they will require progressively less process-management overhead. Coaches who have not seen an “advanced” agile shop tend to see the Scrum “rules” as an end state rather than as a starting point. When teams have outgrown the need for the rules, and they are required to continue following the rules anyway, they check out. Coaches who haven’t seen this won’t know how to help teams overcome the perfectly normal Zombie Scrum stage.

Imagine, if you will

These “starting rules” include some of the holiest-of-the-holy dogma in beginner-level agile coachery. Team collocation. Stable teams. Story sizing. Others.

All these “rules” have a purpose. Remember that Scrum was created in the early 1990s based on work published in the mid-1980s. Recall the state of the corporate IT world at that time. Matrixed organizations. Individuals assigned to multiple projects concurrently. Functional silos. Isolated, solo work. Indirect communication methods.

And the results: Very long lead times. High defect levels. Low customer satisfaction.

Scrum addressed all those issues in a practical way. By following the Scrum “rules,” 1980s-era organizations could break those nasty old habits and start to achieve better outcomes.

Do we really need collocated teams? Well, it’s better than having individuals scattered all over the place, not collaborating, and communicating only indirectly through “tools” and such. But the goal isn’t merely to sit in the same room together. The goal is collaboration. If people are interested in collaboration, they will find a way. We certainly have technologies today that support remote collaborative work. There’s no longer a need to force everyone to sit together physically. That was never really the point, anyway. It was only a means to an end.

Do we really need stable teams? Back in the day when people were measured on individual performance, there was little sense of team membership or shared ownership of results. You had no incentive to collaborate. In fact, you had every incentive to make everyone else look bad, so you wouldn’t be riffed in the next stack-ranked layoff sweep. The cure? Stable teams. People got used to working with each other and began to feel like a real team. What happens when people feel that way throughout the organization? Well, maybe there’s no problem letting people work on different things. They’re accustomed to smooth collaboration and transparency. There’s no more “storming and norming.” Collaborative work is natural for them. So, if someone wants to work on something other than the same sorts of changes to the same parts of the same codebase, it’s no problem.

Is there a point to this?

Well, yes. The point is the Zombie Scrum phenomenon may be a signal that the organization is ready to move beyond beginner-level practices, shed some of the novice-level process-management overhead, and mindfully bend or break some of the “rules.” Shake things up. Restore people’s enthusiasm. Grow.

Just food for thought. Meanwhile, all this typing has made me feel a bit peckish. Please pass the brains.