What is Agile doctrine?

Migrated from my old blog.

Mark Bonchek and Chris Fussell wrote 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?

Is it just 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 20 years). To borrow a phrase from John Boyd: Don’t treat the Agile Manifesto as doctrine because an awful lot has happened in 20 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?

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

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

  • 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 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?

Senior Agile Coach at Spotify, ex-ThoughtWorks, ex-CruiseControl