Seven Ways to Fail at Scrum -- Part Two

In my previous post, we took a look at two of the "bad Agile smells" coming from product groups I've observed.  Today we'll look at another.

Smell #3: The Quality Assurance Wall

The QA Wall is essentially any structural practice that tries to maintain one or more levels of separation between Quality Assurance Engineers and Software Developers.  It's based in Waterfall SDLC and is a strong odor for any Scrum team.  

The wall can take many forms: a separate QA team, who plans its work in its own set of sprints away from the development teams;  QA Engineers who are "embedded" within a development team, but have no input into the development process; the list of different forms can be quite extensive.  Most of these practices cite a perceived need to keep some distance between Development and QA as an audit control.

The teams I'm observing currently have a different form of wall:  QA maintains its own source control rail (there are no branches, so it's not a trunk) that developers merge their code into from the "Development trunk" as stories are completed.  Testing cannot begin until code has been built from this QA rail and the final product delivery is made by QA from a build using the QA rail.  There is no Continuous Integration environment in place.  (CI is technically an eXtreme Programming practice, not Scrum, but it is a highly recommended practice.)  Additionally, the QA teams' cubicles are all co-located -- adjacent to the developers, but not mixed in with them.

As you can probably imagine, keeping the QA rail and Development trunk in sync is paramount and involves a lot of extra, and I would argue unnecessary, labor.

What makes this a bad smell for Scrum is that the effort involved in keeping the QA rail updated generates and reinforces bad practices on the part of the Developers.  They delay merging their changes because it is such a painful process.  As a result, QA Engineers don't get their hands on most things until near the end of the sprint and any mistakes made in the merge process by the Developers create build headaches for the QA engineers who aren't build experts to start with.

This practice, combined with the lack of inter-mixing of workspaces and the issues resulting from Smell #2 all combine together to reinforce the "us vs. them" mentality.  That mentality is causing bad blood between the two groups and has completely inhibited any environment of trust.

Contrast this with the Scrum teams I've run, which have had amazing levels of camaraderie, trust and quality software releases.  On those teams, QA performed most of their testing from the Development staging servers, which were staged automatically by the Development build server from the Development source code trunk. Stories are tested often the same day they are checked into source control, or by the next morning at the latest.  When possible, the QA staff were sitting mixed-in with the Developers, who were available to help the QA engineers with coding questions.  (The majority of my QA engineers have been Computer Science graduates doing a mix of manual and automated testing.)  When my QA staff has been remote, we've fostered an environment of "Instant message often, call on the phone more, email less" to keep people in constant contact.  When a current story fails acceptance testing, it's turned around to the Developer immediately by talking to them over the low cubicle wall or by a quick phone call.  My QA staff has as much input into the development process and tweaking of user stories as anyone else.  Retrospectives, as a result, are honest, frank and based on the ability to trust the other members of the team.  My QA people, who all report to me, actually like the Developers they work with.  There is no "us vs. them".  

In summary, a good Scrum team is able to perform QA reliably and faster when there are no walls in place.  Faster QA means earlier detection of software faults, faster turnaround of defects and a higher-quality product.

Bottom line: Don't create the QA Wall!

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.