Building the Right Thing
delivery is the gold standard
Agile flipped the conversation from one about locking down the specification, to one about building the right thing. In the old school, the cost of changing specification was identified as a major problem, and being able to deliver at all was the gold-standard of success. Agile pioneers sought to mitigate the risk attributable to specification change through a re-conception of the process, to accommodate rather than thwart change.
The Agile Manifesto
To understand Agile, start by re-reading the 2001 Agile Manifesto. It’s a straight-forward declaration of 12 principles, summarized in 4 cardinal tenants. It fits on a letter size piece of paper, sufficiently brief that we should take conversations along the lines of “textbook Agile” with a grain of salt, because there is no such thing, nor is there a need for it. Everything else you’ll read about it, including this post, is just someone’s interpretation; some of it valuable, some not so much. When in doubt, don’t hesitate to ask for evidence.
Without data, you’re just another person with an opinion.
— W. Edwards Deming
Proposals for practice changes are going to consume resources, so it’s not too much to ask how success will be measured.
Frameworks from Scrum to the Scaled Agile Framework are prescriptive, and sometimes have a negative impact for teams that come into contact with them. Ironically, they can end up influencing organizations to value the process and tools over individuals and interactions, and to inculcate team members in following the plan over responding to change. If a framework works for you, great, stick with it! Just try not to get bamboozled by Agile mumbo-jumbo.
I fear those big words, Stephen said, which make us so unhappy.
— James Joyce, Ulysses
The Agile Fluency Model
The scaling problems of large organizations are better served by patterns than frameworks, which leave a little more space for the core principles of Agile to breathe. Improvement depends on getting the observations and insights of everyone, including the most junior member of the development team. When team members are trained to the framework, it becomes tough to escape when senior members infuse their preferences as if they are the process. The framework has a tendency to become a façade for the kind of top-down management, where the observations of the development team are generally unheeded.
When the Process is the Problem
The process should always be subject to question because the process is not our value stream, it’s what produces value. When the cause of turbulence is the process itself, then the process is the problem. When the process is prescribed by a framework, then people tend to defer to the framework rather than questioning the process. When things go wrong, a classic anti-pattern is to imply that the team didn’t follow the process, when fixing the process might be a more sensible attitude.
Producing Value for the Organization
When the process is rooted in principles, following patterns, and the observations of the most junior member of the development team simply have the weight of merit instead of seniority, then the organization gains whenever the process is amended to help assure quality, based on feedback from the team. Our purpose is not to live up to the ideals of the process, but to produce value for the organization.
The Agile Manifesto provides us with a standard reference of principles that have held up quite well over nearly two decades of otherwise crushing change in software development. Re-read the Manifesto and ask yourself: what would you add or remove, to bring it in line with the times?
Someone is sitting in the shade today because someone planted a tree a long time ago.
— Warren Buffet
The real value of Agile is not in devising ways to make the team comply with the process, but in providing context to inform the choices teams face as they figure out which of the many challenging technical practices are best suited for their particular circumstances. The measure of success is improved capability to build the right thing.
He who leans against a good tree finds good shelter.
— Miguel de Cervantes
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.