The Four Pillars of Agile Adoption

is no limit to the number of agile unit tests that can be written for a given code base. [4] You can make the tests as fine-grained as you need. But they will require effort (cost) to maintain.

There is a constant tension between how much technical debt you allow into the code vs. how much effort you put into your agile testing strategy to combat it. This cannot be managed effectively from outside the team. It requires a deep and constant familiarity with all aspects of the code. Only a cross-functional core team will have the skill and judgment to do this efficiently. This is why testers need to be part of the team, and why the team needs autonomy to decide how the work, and the testing, will be done. [5]

Agile technical practices give the team new skills to take the bug risk far closer to zero than they could have before. Still, it is for managers to own the fact that accidents can happen, and they must be prepared to untangle the resulting traffic jam if an accident does occur. This is what Deming names "common cause variation", variation intrinsic to the system that is not due to any mistakes made by those working within the system.

Particularly in software development, insufficient early investment takes a very heavy toll. The problem is that it's hard to say definitively just how much specification detail is enough, or how much requirements analysis is enough, etc. agile teams solve this problem by following a simple rule: In every iteration deliver tested, working code that customers can directly evaluate. That means deliver whole usable features, not mere technical components.

Takeaway Lesson
Every agile team needs to be able to produce bug-free code. To the extent that you have bugs, your project is out of control. The product owner and line managers of the Comet team members should have owned the bug risk by defending the decision to pay down the technical debt incrementally. If they had fully explained the risk and its mitigation plan to higher-ups beforehand, the incident with the Legal department needn't have been so damaging to the agile adoption programme.

Problems With Pillar #2: Empowerment
Partnership between team and stakeholders is fundamental. If one side can never say ‘no' to the other then it is not a partnership–it is a master-slave relationship where neither side can ultimately get their needs met. Partnership is what opens up the entire domain knowledge of a whole team and places it fully in service to the organization. Only autonomous teams can take full ownership of a goal, relieving managers of tedious unnecessary control tasks.

Two things are needed for a core team to step up to their role in this partnership:

• Autonomy over their work, with a practical way to make decisions as a group
• Mentoring to continuously improve their skills in the technical work itself

Empowerment of agile teams is not optional; it is crucial for the high degree of focus and dedication necessary to produce bug-free code sustainably. Mere process rules that a company may institute cannot make people engage to the degree necessary for producing such high quality software. Their commitment, creativity, passion, and energy are needed - not just their obedience to rules! No externally imposed discipline is any match for self-discipline. This is the key to agile (and to Lean Thinking), which is completely missed by so many would-be adopters. [6]

Let's look at how issues with empowerment surfaced for the Comet team. There are many problems stemming from this, and in my coaching experience that is common– empowerment