I was very taken this week with David Joyce’s presentation of “Agile for Executives”. He takes core principles from agile software development and lean, and generalised them to be relevant to senior managers who are less interested in the intricacies of software development.

For example, agile development advocates small, independent deliverables to allow the backlog to be reprioritised at short notice. David presents something abstracted up a level:

Develop a capability to respond to unfolding events.

He also provides an alternative view for each principle, which describes the status quo. In this, for example:

Or are we assuming that change is limited and manageable, and therefore we don’t need an adaptive system?

This all terrific stuff, and it’s a tool I’m going to stash in my corporate toolbox. I’d also like to add a couple of thoughts…

1. Alternatives need to be credible. If we want to introduce change (and particularly if that means moving to a high trust culture, which is one of David’s tenets) then then I would present each change and its alternative as evenly as possible, to ensure that a vote for the change is as honest (and therefore as lasting) as possible. In David’s list of thinking points the alternative to “Create feedback loops…” is “Or do we assume we are right first time, every time…?” That’s a bit too much of a straw man for my liking, and I’d expect an audience to pick up on that immediately and therefore reject the whole thing. A slightly more even-handed alternative might be “Or do we expect to learn lessons informally, or that lessons are only to be learned when very obvious problems force us to change?”
2. Show what change looks like. If we’re going to take these principles and move them beyond thinking points then it’s valuable to show the tangible difference between change and the status quo: how would we recognise it? For example, while one of David’s principles is “Foster a high trust culture” it’s easy for a manager to claim that’s already in place. Having tangible signs helps us. Examples here might include: fewer or smaller contracts, senior staff providing less detailed instruction to junior staff, simpler project proposals, and so on. It would vary by organisation.

Go look at “Agile for Executives” because it’s a good read. I’d be interested to know if there are any principles that you think you’d change. (Or do we assume David Joyce can speak for everyone?!)