Going back to basics with Agile, what would we find? The Heart of Agile

Posted on by

In a world with non-software Agile and Agile at scale, what is Agile? I think Alistair Cockburn has hit the nail right on the head with his recent HeartOfAgile.

That’s not Agile!

“That’s not Agile!” is a refrain I hear more and more. Sometimes directed at me but more often I’m just an observer in an exchange by others. Of course the accusation presupposes a definition of Agile – the definition held by the person doing the accusing.

Unfortunately there is no common definition of Agile. At best there are some broad principles. As Agile moves outside software and is used at a scale bigger than a single software team I do see a need to identify the core of Agile. The basics. If we were to go back to the Agile basics, where would be we end up?

Embellishments on Agile

As you probably know I’m not a fan of Scrum so I read Klaas Ardinois’s post I’m done with scrum with some interest. Ardinois finished by saying that instead of Scrum we should go “back to basics”. For Ardinois the basics are:

  • First and foremost: ship it. Small-ish hypothesis –> software –> measure result –> tweak
  • If you’re going to be religious, be so about measuring and displaying results. All hypothesis must come with ways to validate them, build them into your system and make these visible
  • Automation is king (and yes, the results of automation testing, deployment etc go on a dashboard that is highly visible)
  • Unclean code is not an option. Ever.
  • Communication happens in many forms. Talking is just one option
  • Behaviour of a team is a consequence of productivity, not the other way around. Or put bluntly: teams who get shit done are usually happy, but happy teams don’t necessarily get shit done

I agree with everything Ardinois said but disagree that these are the basics – the core of Agile. Ardinois has a developer-centric view of the world and that leaks into his definition. “Software” and “Code” are specific to the development context and have to be left out of any common definition.

I’m a huge fan of automated testing, but “Automation” is an embellishment on Agile, not core. Often people commenting on Agile confuse their favourite embellishment with the core, the essence. “You don’t have a Scrum Master. You’re not Agile!” “You’re not doing Sprint Planning. You’re not Agile!” “You’ve got a Project Manager. You’re not Agile!”

The Agile Manifesto

The Agile Manifesto seems like a good place to look for the essence of Agile. The values inherent in the manifesto are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

I believe these values are still relevant and I’m not alone. At Agile 2011, the agile manifesto signatories reaffirmed their belief that these values represent the foundation for “better ways of developing software” (Langr & Ottinger, 2011).

These values and principles are great, but there it is again, that word “software”. This word, and implicit constraining context, undermines the manifesto’s ability be the essence of Agile. Given Agile is applied outside software I’m looking for something that is more widely applicable.

I’ve another problem with the Agile Manifesto – it is big. Well, the manifesto itself isn’t but it is backed up by 12 Agile Principles. In total that is 16 points (values or principles) to consider when deciding whether something is Agile or not. Even if you agree with all of them (which I do), that is quite a lot. What we need is a condensed version. An Agile manifesto light. Sure enough there is one. Woody Zuil (@WoodyZuill) tweeted (6 Feb 2013) a definition of Agile which is basically this Agile Manifesto light:

#Agile: Individuals + Interactions + Customer Collaboration + Emerging Requirements + Early, Often Delivery of Working Software.

I like this. I like it enough that I might stick it on a poster next to one of my Kanban boards. But software is still right there, front and centre, in the form of “requirements” and “working software”.

The Heart of Agile

Luckily Alistair Cockburn, probably the most theoretically rigorous of the Agile Manifesto signatories, has a definition that is both widely applicable and scalable. In his post Using the Heart of Agile on the problem of scaling Cockburn explains:

The HeartOfAgile is a return to the center. Scraping away, for a moment, all the decorations that have grown around agile implementations, I find these four actions neatly describe the heart, or the spirit (?), or the center (discussion: Re: Shu Ha Ri Kokoro) of agile:

  • Collaborate
  • Deliver
  • Reflect
  • Improve

Like!

Heart of Agile

Heart of Agile
Source: Alistair Cockburn

References

Ardinois, K. (2013, 21 May). I’m done with scrum. ardonio.com.

Cockburn, A. (2015, 22 May). HeartOfAgile. Author.

Cockburn, A. (2015, 13 June). Using the Heart of Agile on the problem of scaling. Author.

Langr, J., and Ottinger, T. (2011, September). The Only Agile Tools You’ll Ever Need: A Sanity Check on the Use of Tools.