Seven Ways to Fail at Scrum -- Part One

I've watched and participated in Scrum teams that were successful -- teams that were self-organizing, promoted trust, delivered regularly and produced a high-quality product.  But I've also seen teams "fail at Scrum".  The quotes here are intentional, because, in most cases, it was not Scrum or Agile that failed, but the teams or the environment around them tried to do Scrum-like things, but failed to actually do Scrum.

The simple truth of the matter is that Scrum works -- but you have to actually do Scrum to make it work.  Doing things half-way or picking and choosing the parts of Scrum that seem palatable to you is destined to fail -- because Scrum is a framework, a support structure.  If you don't include all the pieces, or cheapen some of them, the structure falls apart.  Most groups that have seen "Scrum fail" have actually failed to do Scrum.  This isn't to say that Scrum works everywhere and in every culture -- that kind of thinking isn't Agile -- but it is a framework that works well when the environment is suited to it already or can be tailored to it.

Over the next few days I'll present seven things I've seen in product groups that claim to be doing Scrum, but aren't.  Elsewhere in Agile literature you'll see these things referred to as "smells" -- things that people do in the name of an Agile practice, but that just smell wrong.

Smell #1: Teams formed by Project Managers/Product Owners

I've seen a few shops where the members of Scrum teams were chosen by the Product Owner so that the PO essentially had a go-to team where they could park their pet or customer-sensitive features.  This resulted in a sort of A-Team where all the high-visibility and cherry features went while the second-string teams got all of the defect work and "add a new field to page X" stories.

This is a Scrum anti-pattern, plain and simple.  It flies in the face of the core concept of Scrum: the concept of self-organizing teams.  Team composition should be organic and the teams should be organizing themselves around the whole of the product backlog.  Sure, an initial set of team assignments by the team lead or Scrum Master makes sense with a group that is just learning Scrum, but those assignments should be balanced, mixing levels of experience and proficiency throughout, and those assignments should be considered temporary.  While team stability is important for establishing and maintaining velocity, team members should still feel the freedom to move among teams on a single product to find the mix where they work the best.

The fallout of following this anti-pattern is huge.  One of product groups I'm observing currently is experiencing cross-team jealousies, defeatism, feelings of favoritism and a lack of trust.  Everyone knows who the "A-Team" is -- sadly, the teams are labeled "Team A", "Team B" and "Team C" and correspond to the levels of confidence that the product managers have in each.  Inexperienced developers are not paired with experienced developers, meaning the former are not getting the training they need and the latter are not getting the injection of outside-the-box thinking that they need.

Smell #2: QA Musical Chairs

This is another anti-pattern related to the first item.  The way this works is that the Quality Assurance engineers for this group are essentially matrix-managed by a single QA Manager.  This, in and of itself, is not a bad thing.  In fact, matrix management of Scrum personnel, especially when there are dedicated areas of expertise, can be a very good thing.  A strong QA Manager, for example, can be working with all of their direct reports on their career objectives and personal growth in a way that a typical Software Development Manager can't.

Where this becomes an anti-pattern is when the QA Manager involves herself with the assignment of QA personnel to specific teams.  Just as with Smell #1 above, the Manager is interfering with the teams being able to form organically and self-organize.  In this case, the Manager is not making the selections based on proficiency, but appears to be intentionally moving team members around as a way to keep them cross-trained on the application.  While this sounds like a good idea, the fact that the manager is interfering with the team organization is the source of the bad smell.

Here she is somewhat tied up by what is already happening with Smell #1:  if the teams were organizing themselves around the whole of the prioritized backlog, rather than having work assigned to each team by the Product Owners, she would probably not feel compelled to mix things up in this way.

"Okay," you may be thinking to yourself, "so it's a bad smell, but it's for a good purpose, it seems.  Where does this go wrong?  What are the consequences?"

There are a couple of consequences that come to mind right away.  The first is that all of the teams' velocities are being thrown askew, since changes in team composition always affect velocity.  This particular Manager would disagree with me, because her teams also correlate story points directly to man hours, which is another Scrum anti-pattern.  (See Smell #5 in an upcoming post.)

The other issue is that the QA personnel are not forming good working relationships with the Software Developers on their teams.  They see their tenure on any team as being temporary.  The upshot is that the teams are not building trust from within and an "us vs. them" mentality is maintained.

Next time we'll look at the Quality Assurance Wall anti-pattern.