Failure Modes of Team Based Scrum

My take is that when you stop thinking about Scrum in terms of roles, ceremonies, and artifacts… it opens up the conversation to look at what’s really going on with your struggling Scrum implementation. No longer are we lamenting the absence of a product owner… we can discuss why the organization finds it so hard to articulate a clearly defined backlog for the team.  No longer are we talking about how to get better burndown charts… we can discuss what about our team structure has made it impossible to make and meet commitments sprint over sprint.  We aren’t talking about the rules for better sprint planning… we can talk why the team is struggling to get enough shared understanding to deliver a working tested increment of product every couple of weeks.

At some point, I’m going to write a post on the difference between activities and outcomes, but I think we have a broader societal issue at play here.  With Scrum, we know we need clarity, accountability, and the ability to measure progress on frequent intervals.  At some point Jeff and Ken instantiated a set of rules that helped people get those outcomes. Once Scrum started to go mainstream, all people seemed to remember were the rules. They forgot the meaning behind the rules. I say this is a societal problem because I think people do this in lots of different areas… not just work.. not just agile.  Think about all the areas of your life where folks are just going through the motions without any real understanding of what they are trying to accomplish.

The rules are important. The rules without the meaning are meaningless.

Where does that leave us today? Today I want to talk about some of the more common failure modes of Scrum. These are the ways that I see folks repeatedly failing when they try to implement Scrum.  True to the spirit of this post, I don’t want to talk about how daily standup meetings go bad, or the ways that people mess up user stories, or why it’s a problem that the Dev Manager is also the ScrumMaster. I want to talk about some of the underlying patterns that I think are consistent across teams and make Scrum harder than it has to be.

The Backlog

In my experience, the failure to produce a well-groomed prioritized product backlog is the root of nearly every problem on a Scrum team.  Let’s start at the end of the sprint and look at all the things a poorly formed backlog will do to a Scrum team.  Failure to deliver at the end of the sprint, poor sprint reviews, bad retrospectives can almost always be tied to a poorly articulated backlog.  If the team can’t understand what they are supposed to build, they typically don’t get anything finished, and nothing at the end of the sprint works.

What about the middle of the sprint?  Ineffective daily standup meetings, inability to swarm, inability to burn down linearly during the sprint… all of these result from poor planning meetings.  Why do we have poor planning meetings you ask?  That that takes us to the beginning of the sprint.  Poor planning meetings almost result from a poorly formed backlog.  If the backlog isn’t clear coming into the sprint planning meeting, the team will spent too much time inventing the ‘what’ and not nearly enough time on the ‘how’.

Without understanding the ‘how’, it is very difficult to get to a commitment.  Without the ‘how’, it’s very difficult to figure out how we can work together or collaborate.  If we aren’t collaborating, everyone is working on their own stories.  If everyone is working on their own stories, they aren’t finishing early in the sprint.  If we don’t finish early, we are deferring done to the end of the sprint.  Deferring done makes it hard to do the testing, get feedback from the product owner, and we end up missing stories. Missing stories caused velocity to destabilize and the team isn’t predictable.

Missed stories make for missed commitments, bad demos, and even worse retrospectives.  It’s all interconnected.  If the backlog isn’t there, nothing else in Scrum works.  Many teams don’t have a backlog at all.  Some teams have a backlog full of technical tasks that they created themselves.  Some teams have backlogs that are full of large ambiguous user stories that are not nearly well defined enough.  Some teams have backlogs that don’t meet all the INVEST criteria.  All of these things make Scrum nearly impossible to do well.

What’s underneath a bad backlog?  Sometimes it results from the absence of a Product Owner, but even in the presence of a Product Owner, these problems are rampant.  Solving this is about figuring out who in the organization has the knowledge and skills to break down the work, make tradeoffs, and help the team develop a shared understanding of the product.  Sometimes is the fact that the organization has no strategy or is thrashing with too many external commitments. Sometimes the solution is a good Product Owner, sometimes it’s better program and portfolio management, sometimes we need better executive leadership.  Solving the problem can happen at lot’s of different levels.

The Team

Team formation is another huge problem trying to implement Scrum in most organizations.  I became passionate about this issue back with I worked for VersionOne.  I’d go to train client after client and see people matrixed across multiple teams, teams with tons of external dependencies, and teams with missing subject matter expertise… basically, teams that didn’t have everything to deliver a working tested increment of product.  If you can’t build proper Scrum teams, I’d suggest you find a different way to build software.  It’s that important!

Think about all the stuff that a broken Scrum team breaks in Scrum.  Let’s assume for a minute you’ve solved the Product Backlog issue, what does sprint planning look like?  You are trying to understand the story without everyone in the room?  You are trying to break down the work without everyone necessary to solve the problem?  You are trying to commit to a sprint when you don’t have all the external dependencies worked out and there is no shared ownership?  How do you estimate in the face of all this uncertainty and can’t get to done no matter how hard you try.

Once we leave the planning meeting, the team members mysteriously go off to work with their other teams during the sprint.  When they are needed by the team, they aren’t there. Team members are waiting on stuff they don’t have, but necessary to deliver a working tested increment.  When a team doesn’t have everything necessary to be successful, it erodes the sense of urgency around getting done.  Velocity destabilizes and no one cares.  No one is accountable for making progress on the product and the team becomes a victim.

I don’t think we spend nearly enough time as a community giving organizations guidance on how to form teams.  Sure, we have the notion of a complete, cross-functional teams… but what does that mean in large enterprises.  How do we form these teams at scale when it takes many teams to build the product?  How do we coordinate across the teams?  What do we do when we have to form feature teams and component teams and what specifically do we form them around.  I think I said this was the topic of my next post.  Now many be as good a time as any ;-)

I’ll say it one more time… we really, really, really, really have to get serious about forming teams if we want to be able to do Scrum properly.  I’d have a hard time if you asked me what was more important… getting a good backlog or forming teams.  They are both such common failure modes… LeadingAgile has gotten to the point where the first step in any engagement is helping the organization define teams and define the backlog creation process before anything else gets started.  Training the wrong teams with no backlog is an effort in futility.

The Product Increment 

I leave the product increment to last, because I do believe that if you can solve the first two problems… it’s much easier to work out the third.  My experience is that a complete cross functional team, with a really good idea what they are building, in the presence of a well articulated backlog can pretty much figure anything else out.  They might need to be given *permission* to do the right thing because they don’t feel they have time to test, or work on the build environment, of the branching strategy… but it’s a solvable problem.

If we assume for a minute that we have a good backlog, and we have a well formed Scrum team… and the group is *still* struggling to produce a working tested increment at the end of the sprint, that is when you started looking into things like technical practices and team dynamics.  I’m no expert on technical practices, but I’ve generally found if we can get anything close to a daily build, get testers working side-by-side with developers (with automation or not), and get developers working together on a daily basis to deliver user stories… you’ve got a shot.

Again, assuming a good backlog, a well formed Scrum team, and maybe the bare minimum of technical practices.  The most common challenges center around getting people to work together to deliver early and often during the sprint.  Many developers like to work alone.  Many don’t want to have to collaborate with their peers and their customers.  It gets frustrating having to endlessly debate how things are going to get implemented.  People just want to go off in a corner and code.

Working together during the sprint allows the team to get more things finished rather than ending the sprint with a bunch of stuff only partially done.  Team collaboration results in a more predictable sprint, a more stable velocity, developed software that can be tested, finished features that can be demoed, and feedback that can be received on how the product is progressing. All this results in a sense of accomplishment and a sense of ownership and a sense of camaraderie in the team.

Summary

These are such important challenges to solve… and such a common failure pattern… I can’t promise this will be the last thing I’ve got to say around this.  I feel like I could go on forever.  I really wish that all of us could stop focusing on the ceremonies, artifacts, and rules of Scrum.  I wish we could stop focusing on the 10 tips to be a better ScrumMaster, or the 5 essential qualities of the perfect Product Owner.  I wish we could stop focusing on the rules and dogma of Scrum and refocus on what we are really trying to accomplish.

In my opinion… it’s all about having shared understanding around what we are going to build.  It’s all about having teams that have everything necessary to deliver a working tested increment of product.  It’s all about the team producing the working tested increment without carrying forward technical debt and defects that make it impossible to get the product out the door.  It’s not about what we do in Scrum or who does it… it’s fundamentally about what all those things were originally intended to accomplish.

That is what will fundamentally help us succeed in the long run.

Check out the next post, Structure, Governance, and Metrics on Large Scale Agile Teams.
Check out the previous post, Underlying Mechanisms of Team Based Scrum.