All organizations are plagued by dysfunction—those impediments or obstacles that stand in the way of realizing their full potential. One of the benefits of an agile process like Scrum is that it helps expose these dysfunctions.
Although finding and addressing dysfunctions is ultimately in every organization’s best interests, some organizations have no appetite for it. In fact, some organizations become quite uncomfortable when a bright light shines on their problems. So uncomfortable, in fact, that they are more likely to adjust Scrum (the light) than to confront their problems head on.
Organizations that resist the urge to obscure their dysfunction, and choose instead to bravely face the brutal facts that Scrum reveals, tend to experience much more success.
Let me give you an example. In my training class I often make the following remark:
“Programmers and testers should be on the same Scrum team. Their goal should be to produce features that have zero known defects by the end of each sprint.”
In one class, immediately after I relayed this advice, a lady in the back raised her hand and said, “That won’t work here.”
I asked why and she responded, “Well, I’m the manager of QA and all of the QA people report to me. You just said I should assign all of my people to Scrum teams and that they should help ensure that their teams produce zero defects.”
I said, “Yes, that’s right. I know that’s an aggressive target that you might not achieve initially, but why not have it as your long-term goal?”
She replied, “No, that won’t work because we compensate our testers based on the number of defects they find. If they have zero known defects at the end of the sprint, their compensation will actually be less.”
I waited to see what she would say next—because how she responded to this realization would be an important indicator of whether or not this company could be successful with agile.
She might have said, “So you can see why I could never assign my QA people out onto cross-functional Scrum teams. We’ll just have to do things differently.”
If she had, it would been equivalent to her saying, when the bright light of Scrum exposes an impediment, instead of addressing the impediment head on, we will just change Scrum (e.g., not form cross-functional teams) so that the impediment no longer exists. In other words, we have no appetite to deal with the difficult problems; instead we will carry forward with what is arguably a crazy policy: compensating people based on the number of defects they find.
(Speaking of which, how does a policy like this one not lead to collusion? Let’s say I’m the developer and you’re the tester. What’s to prevent me from saying: “Hey, I’ll put defects in, tell you where they are, you “find” them, I’ll take them out, and we will split the bounty!” But I digress.)
But she didn’t say that at all. Instead, she said, “Since we clearly need cross-functional teams, it sounds like I need to have a conversation with the VP Engineering and the Director of HR about how to change the compensation policy for my QA people.”
I breathed a quiet sigh of relief: So she does have the appetite for dealing with the real impediments!
Notice that in this example, Scrum isn’t the cause of the impediment—the bad policy to compensate testers based on the number of defects they found was hiding in plain site. And Scrum doesn’t offer guidance as to how to remove that impediment, per se. Scrum does, though, persistently shine a bright light, which in this case exposed an impediment to cross-functional teams (and arguably good coding practices). What your company chooses to do in the presence of Scrum’s bright light will ultimately determine the degree to which you will be successful.