What is Agile doctrine?

Strategy and plans are not enough

Mark Bonchek and Chris Fussell write about why strategy and plans are not enough:

Strategy doesn't give employees enough guidance to know how to take action, and plans are too rigid to adapt to changing circumstances. In rapidly changing environments, you need fog lights to get closer to the ground.

...where "fog lights" is doctrine.

Doctrine creates the common framework of understanding inside of which individuals can make rapid decisions that are right for their circumstances... If strategy defines objectives, and plans prescribe behavior, then doctrine guides decisions.

In other words, doctrine allows us to safely decentralise decision-making by establishing consistent decision logic.

NATO defines doctrine as...

Fundamental principles by which the military forces guide their actions in support of objectives. It is authoritative but requires judgement in application

So I wonder...

What might Agile doctrine be?

What are the fundamental principles by which Agile practitioners should guide their actions in support of objectives, that are authoritative but require judgement in application?

Is it just the Agile Manifesto?

The most obvious candidate for Agile doctrine is the Agile Manifesto.

I have problems with this for the following reasons:

• It was not really the intention of the Agile Manifesto to act as doctrine... despite that many new Agilists treat it as such
• The Agile Manifesto was the result of compromise, the lowest common denominator set of values and principles that a group of people could agree upon.
• The Agile Manifesto hasn't been updated since 2001 (i.e., as of this writing 12 years).  To borrow a phrase from John Boyd: Don't treat the Agile Manifesto as doctrine because an awful lot has happened in 12 years.
• 12 principles is a lot to keep in working memory... and I'd prefer a doctrine that most people will remember without having to look it up... at least for the base version.

What about Extreme Programming?

Instead, I'd prefer to look at a concrete Agile method.  Because of my own history, my preference would be Extreme Programming:

Software is too damned hard to spend time on things that don't matter. So, starting over from scratch, what are we absolutely certain matters? … Listen, Test, Code, Refactor. That's all there is to software. Anyone who tells you different is selling something.

Kent Beck

Listen, Test, Code, Refactor seems too programming-centric to be suitable for general Agile doctrine so let's pull it up a bit...

A proposed Agile doctrine

1. Reduce the distance between problems and problem-solvers

I first heard a version of this from John Sullivan, but he described it as reducing the distance between customers and developers.

There are two types of distance that I'm referring to here:

1. Physical distance
2. Conceptual distance, that is, how conceptually accessible the problem is to the problem-solvers.  This leads to things like making the problems visible, better techniques to model the problem, etc.

2. Validate every step

• What is the desired outcome?
• Why are you taking this step? Does it move you toward the desired outcome?
• How would you know the step was done and successful?

In other words, in the words of every effective Agile practitioner:

Do you have a test for that?

3. Take smaller steps

…many of the most important improvements in product development, such as concurrent engineering, rapid prototyping, and agile software methods, are recognizable as batch size reductions. 

Don Reinertsen in The Principles of Product Development Flow

Smaller work packages, smaller releases, etc. all follow from this.

Because avoiding transaction cost is typically the main reason why larger steps are taken, reducing transaction costs is a big part of this as well.

4. Clean up as you go

Leave this world a little better than you found it. 

Robert Baden-Powell

 "Clean up as you go" is awareness of and dealing with technical debt and generally leaving things a little bit better than you found it to incrementally address entropy.  Technical systems degrade over time without maintenance and so do human systems.

So what?

Is doctrine a useful concept?

Is this the right doctrine?

Compared to other sets of principles, will this doctrine be easier to establish, easier to maintain, and be more effective in supporting appropriate decision making that is recognisably Agile?