Wednesday, 21 May 2014

Bruce Lee and the Agile spectrum

I've been lucky enough to have practiced a range of the published Agile delivery methods: XP, Scrum, Kanban and now DSDM. And I've been doing this for 10 years now. Time enough to form some opinions.

Right now I feel that these techniques sit on a spectrum of Agility:

Winging it
Too few controls
Delivery at risk
more Agile <----- Agile -----> less Agile Not agile
Too many controls
Delivery at risk
Co-hacking Kanban Scrum & XP DSDM Trad PM
  • Intimate communication
  • Shared commitment
  • Inexpensive
  • Unconstrained
  • Uncontrolled
  • Foster a Co-hacking-like work-style
  • Owned externally to the delivery team
  • 'Bottled lightning'
  • Agile-friendly governance
  • Work-style-agnostic
Focus on rapid delivery of highest priorities Focus on inspect-and-adapt continuous improvement of product and team


Hacking is a complex knit of ideas. Getting things done. Rapidly. Dirtily if necessary. On the one hand unconstrained sparks of genius. On the other, spikes that become rabbit holes and technical debt. Doing it your own way. No constraints, no controls.

At its best hacking is a beautiful sweet-spot for any creative professional. It's what Picasso did with his brilliantly innovative lithographs of bulls, an act of creative discovery without a known end-point. Co-hacking is simply my term for two or more practitioners working together - a pair of coders, throw in an IA etc. It sounds the team developing BBC Playlister worked this way.

Co-hackers have the Agile Manifesto almost down to a tee. Individuals and interactions - check. Working software - check (we hope). Responding to change - these guys can pivot on a dime. Customer collaboration? The customer's probably part of the team, so can't provide an independent steer. Even if there is an independent customer, she may not have much pull with the team

So as sweet as that spot is, co-hacking is not Agile. It's not controlled to deliver business value. But it is an important part of the spectrum.


I was a Scrum practitioner when I first learnt of Kanban. It scared me. I understood the value of single piece flow. I appreciated the tremendous flexibility for the product owner in on-the-fly re-prioritising. But no fixed points? No obvious planning horizon? No opportunity to take stock? Challenging stuff!

Of course this places huge reliance and trust in an ongoing conversation between the customer and the team, and it engages the team to find their own feedback mechanisms. All this while letting the customer to re-prioritise at will.

So Kanban is perhaps unbeatably agile - more so than the rest of the spectrum.

More agile. Not necessarily better.

Scrum & XP

When I moved from XP to Scrum, they were already pretty similar. They've only got closer over time. Scrum teams routinely adopt XP technical practices - chiefly TDD but also pair programming. XP, which started with 3-month 'short' iterations, has converged on the Agile 2-week de facto standard, and has adopted retrospectives.

Scrum bills itself as a general-purpose Agile project technique suitable for all types of project, though you'll be hard-pressed to find it used outside the software industries. XP is explicitly intended for software delivery and includes technical practices. So it makes sense to consider XP a software-specific specialisation of Scrum (or vice versa - I don't mean to imply any precedence here).

Scrum & XP foster a co-hacking environment, with just enough governance to ensure that they keep delivering value. "Go make me some of these. Come back in 2 weeks to show me how well you've done." They're the 'bottled lightning' version of Co-hacking lightning, harnessing it to meet product goals.

And on the spectrum? They both provide time-limited iterations. Opportunities for the client to feed back and re-prioritise, and for the team to retrospect its own performance. For all the reasons that Kanban initially scared me, this structure provides a safety framework that is inherently a little less Agile.

Less agile. I didn't say worse.


DSDM takes a very different approach to Agile. The other methods foster an Agile work-style with minimal governance, DSDM creates Agile-friendly governance but is agnostic about work-style.

Uniquely on the Agile spectrum, DSDM offers an up-front project timescale and cost. Just Enough Design Up Front and Timeboxes based on MoSCoW prioritisation (DSDM's approach to flexible scope) enable DSDM to offer the business a high-confidence timescale and cost, and fail-fast discovery if these are at risk.

Any responsible business considering a new project needs some confidence around cost and time to assess project value (Glen Alleman reiterates this point on his blog Herding Cats, and in doing so does us all a good turn). If you're offering software services as a third-party consultancy or agency, you'll definitely need some way to generate these figures.

But this confidence comes at a cost: a plan.

Yes there is still a Prioritised Requirements List (Backlog to the rest of you). Yes, the client still owns the priorities. But the very fact of having a project-length plan creates a resistance to changing that plan. Particularly the introduction of new high-priority capabilities, which will violate the plan. Then change control comes into play, something mercifully absent in the rest of the Agile spectrum.

So DSDM is distinctly less agile than Scrum, XP and Kanban. But not worse.

What about Bruce Lee?

Bruce Lee originally studied Wing Chun. By 1960 he was disillusioned with the artificial boundaries imposed by the martial schools so he founded a martial art philosophy: Jeet Kune Do.

I have not invented a "new style," composite, modified or otherwise that is set within distinct form as apart from "this" method or "that" method. On the contrary, I hope to free my followers from clinging to styles, patterns, or molds.

So you use the right tool or technique for the task. This kick exists in Kung Fu but not Karate? Use it anyway. You need a grapple from Hapkido? Go for it. It seems like the simplest wisdom.

Applying this view simply to the Agile spectrum: pick the methodology that best fits your project. Your customer has fluid requirements and a high level of engagement? Kanban may be just right for you. They need to know a cost and a date before they can commit funds? DSDM may be a better fit. Neither is inherently better and it doesn't matter which is more Agile - they're each a better fit in different cases.

Jeet Kune Do projects

The PM and/or Agile methodologies present themselves as 'whole'. XP is a great example, with a range of practices that support one another: unit tests, refactoring. If you don't employ them all, XP warns that you're heading for disaster (Matt Stephens entertainingly parodies this as a ring of poisonous snakes). Similarly with most methodologies, if you're not following enough of their directives you're not 'doing' Scrum/DSDM/whatever/delete as necessary. You're headed for the rocks.

This is good advice for neophyte Agile practitioners. Each methodology presents a coherent project delivery toolset. If you follow the teachings of a well-reputed school, you'll probably come out OK and start learning how it all fits together.

But this approach also encourages experienced practitioners to pick a school and stick to it. This is clearly nonsense - the existence of multiple successful Agile schools proves there's more than one way to skin a cat. Any given school is probably not a perfect fit for a given project situation, so we should expect more of the experienced practitioner.

Jeet Kune Do projects mix it up. Your client requires up-front commitment? Give them DSDM Foundations. They need an MVP in 3 weeks? Re-configure as a Scrum backlog and use some appropriate tool to track progress - burn-up perhaps. The team wants to operate with WIP limits. No problem. Minimum quality guarantees? Use a Definition-of-Done, or a defined Quality Level or Pair Programming or...

A JKD project practitioner makes herself aware of what the project needs from moment to moment. She knows the teachings of multiple Agile schools, of various Masters both great and small (Fowler, Keogh, Uncle Bob etc), perhaps even schools outside the Agile family (PRINCE2 et al). She understands what each tool gives her, which others support it and where to let go.

And one day, if I work hard, I'll be as good at Agile project delivery as she is.


  1. Pedantic project manager alert. PRINCE 2 is not a software delivery method, its a project governance framework. Very different. PRINCE2 would delegate any of those methodology choices to the delivery team, provided the aims of the business case are not put at undue risk. It is possible for a PRINCE2 project to run Agile, XP, etc as P2 has the concept of tolerance as a defining feature. i.e. how much difference from plan and business case can the PM allow things to run without having to flag them to the board. Often this is time and budget that have that flexibility however agile methods are SCOPE tolerance given a different name. You are of course very right to say that each project should choose its own method based on its needs, although outside of government I'm not aware of many organisations that do PRINCE2 PM for web/ software delivery.

    1. Thanks David.

      PRINCE2 tells the team to go away and come back when the've produced a Stage. The PM only bothers the Board if the project goes into exception. You could work eg a Scrum-like work structure into the team's delivery approach, but that's not Agile. Agile delivery requires and encourages the team and the stakeholders to keep talking throughout.

      I looked at this point back in 2010 (God did I do PRINCE2 so long ago!) in You can't do PRINCE2 and Agile at the same time. I stand by my core point back then. PRINCE2's Management by exception approach is fundamentally incompatible with the Agile principle of Customer collaboration over contract negotiation (see the Agile Manifesto).


  2. One of the criteria for selecting an agile tool in terms of Kanban or Scrum can be the time required. One of these methodology works well when there is shortage of time in terms of deadlines; the other one works well in situations where more time is required to carry out tasks when a diminutive iteration cannot satisfy the work.

    1. Thanks for your comment Kenley. There are all sorts of good reasons for choosing an approach, including time pressures. However if you think it's an off-the-shelf choice of Scrum or Kanban or DSDM or ...then you're probably doing yourself and your client a disservice. If you're comfortable with a range of approaches then you should be able to choose fluently the right mix of tools for the job.