Eric's Arcana and RiderX

I’ve been attending our local lean coffee agile lunch (“lean lunch” sounds like something different…), and our discussion last Wednesday included something that I was meaning to write up for a couple of months, so here it is.

The setup is that we were discussion why agile adoption – XP adoption specifically – was so poor when the results were so obviously better.

This issue is the way management culture works and the way the incentives are structured. Let me posit two different groups.

The first lead – let’s call her Traditional Teri – does the existing company methodology well. Her team does code reviews, they do decent designs, they fix the right bugs first, and they take corrective action early.

The second lead – let’s call her Radical Rachael – is an agile advocate. Her team does decent agile; they do pairing, TDD where appropriate, story-based design, incremental releases, experimentation, etc.

Just to pull some numbers out of the air, Teri is about 20% better at getting software to market than her peers, and Rachael is about 100% better.

Who will be more successful at most companies?

We would all love for the answer to be “Rachael”, but the answer is, in fact, “Teri”. Almost universally. Because the cards are stacked against Racheal:

• Rachael is doing something different and therefore risky. Just like “nobody ever got fired for buying IBM”, “nobody ever got fired for using the same slow and bug-prone development methodology”. If anything goes wrong, Rachael is at a big risk regardless of whether it is a result of her process choices or not.

• They have different levels of peer acceptance. Teri is better than her peers, but only by a little bit and her peers can see how to get to that better level. Rachael makes her peers *look bad*. If she is doing the right thing, then they are clearly doing the wrong thing, but her peers don’t understand how to do what Rachael does nor do they want to. This is a built-in incentive for her peers to actively make Teri less successful or appear to be less successful because it makes them look better.

• Teri is a joy for her manager Susan. Teri is never the problem team on projects, she has extra time to help out others, and Susan’s world is consistent and understandable. Rachael is a big pain for Susan, as she makes waves. Susan is forced to deal with different processes across the teams and field questions that come from outside the group as to why Rachael’s team is different. The outside discussions are very bad, as they make Susan look like Teri; now Susan has to convince *her* peers that what Rachael is doing makes sense, which isn’t good for Susan’s career. And like Rachael, Susan is running the same risks if anything goes wrong. The best thing for Susan to do is to actively hide what Rachael is doing, which means that Rachael won’t get credit for her team’s success.

• Rachael is running a “no drama” team; because of her team’s process choices, they write very few bugs and they don’t have to work extra hours to get things done. But that looks like a team under the conventional process that is lazy and not working very hard, and since it takes a lot of effort to understand how objectively hard a team’s work is, the feeling that they aren’t working hard overshadows her team’s productivity. This is frankly a bit of a problem for Teri as well, but to a much lesser degree.

The end result is that Teri has much better career prospects at her company. It’s *easy* to make a case why Teri should get a promoted and why she would be a good choice as a second level manager, and the discussions that Susan has to have to convince others that Teri should be promoted are comfortable. And Rachael won’t get that promotion because Susan not only has a harder time making the case to Susan’s peers, it is not conducive to Susan’s career aspirations to have those process conversations.