Why "doing things right" should lead "doing the right thing"
Posted on August 09, 2013 by
So another Agile Conference in North America is over. Once again, perhaps for the 7th year running, we've heard a number of leaders in the Agile community promoting the idea that you should focus on doing the right thing - discovering what customers really want and need - rather than focusing on building and deploying working software. The argument goes that there is no point in "doing the wrong thing faster." This sounds bite always makes the speaker sound very smart and it catches attention. It's also used to sell a variety of requirements solicitation and discovery techniques as well as various flavors of product management (or methods for product ownership to use arcane tribal Agile language.)
I deeply disagree with this and I have done since 2005 when I first heard it suggested by one of my fellow co-founders of the Agile Project Leadership Network. I truly believe that building capability to "do things right" must take the lead. Here is why...
I first introduced the use of a kanban system with a department at Microsoft because it would provide predictability and it would prevent overburdening and the disruption of interruption to provide input and insight on speculative future work. Kanban systems restrict the quantity of work-in-progress and require the adoption of deferred commitment on items of work. Kanban systems are one example, of improving capability at delivering with predictability and reliability. Agile techniques such as test-driven development, continuous integration and automated deployment, are all enablers of better delivery. They are focused on "doing things right" in terms of quality, and predictability of delivery, and "doing things better" in terms of quality and speed of delivery.
Why are these things important?
The starting position is often one of low social capital. There is no trust between business people who come with ideas, and IT people who implement those ideas. The lack of trust comes from a failure to deliver with reliability and sufficient quality. Building trust is an event-driven process (from a neuro-psychological perspective) hence, frequent repeated acts of competent performance and acceptable behavior will build trust. Small gestures performed often have a greater effect than grand gestures more seldom, and unreliable and unpredictable behavior undermines trust. Trust is an asymmetric problem. It must be built incrementally through many small acts, while it can be lost completely through a single breach. If you don't believe me consider your own behavior, building and preserving personal relationships that matter to you. You will see on reflection that building and preserving trust is event-driven and asymmetric.
Trust and directly related to it, predictability and quality of delivery, are keys to enabling deferred commitment and the use of real options theory. Deferred commitment aids predictable delivery so a virtuous cycle is created. Deferred commitment is vital to relieving over-burdening which enables higher quality so a virtuous cycle is created.
When there is no trust and no underlying capability to make real options valuable, there is a tendency to compensate with early commitment and over-burdening of a system. If I can't trust that you will deliver what you say you will, when you say you will, then I will need to hedge my bets by asking you for several things in hope of getting one or a few that actually meet my needs. Needs aren't just about functionality but also about timeliness of delivery. A pizza delivered accurately with the correct flavors but after 2 hours and cold on arrival does not delight me. I want a hot pizza, delivered quickly with the correct ingredients! If I can't trust you can do this, I may need to hedge my bets by heating something from the freezer or order an alternative fast food from an alternative delivery service. This costs me more and creates waste.
A lack of reliable, predictable, high quality deliver ends up costing more and creates waste! A lack of reliable, predictable, high quality capability to deliver technology leads to over-burdening and every earlier commitment. A vicious cycle ensues. The challenge for any intervention in a system with a vicious cycle (or negative reinforcing feedback loop) is the question of how to break the cycle? What is the leverage point that breaks the cycle?
I contend that "doing the right thing" - the process of correct understanding my requirements is not a mechanism to break the vicious cycle. We will still have an over-burdened system that produces poor quality, with a lack of predictability and reliability. Trust in the system will not be repaired and the effectiveness of the system will not improve.
On the other hand, improving capability to deliver, and "doing things right" creates the circumstances to enable deferred commitment. Deferred commitment enables better predictability and faster delivery and a virtuous cycle ensues. Deferred commitment forces hard selection decisions and creates a focus on how selection is done. Combined with the limited WIP of a kanban system, deferred commitment raises awareness of the scarce resource of engineering capability. This is turn focuses attention on how to best utilize that scarce resource by "doing the right thing."
Hence, "doing things right" must lead "doing the right thing" if the vicious cycle is to be broken and the correct circumstances created to enable a virtuous cycle of continuous improvement.