Agile (note the big A) versus agile (note the small a)

07 July

I picked this one up several years at one of Software Education’s  Software Development Conferences.  I think it might have been Steve Mellor who said the worst thing to happen to agile was when it was re-spelt Agile.

I think that “agile” (note the small a) is the application of the commonsense, expressed so well in the Agile Manifesto, that competent Software Project Managers have been following for decades.  I would summarise this as:

  1. Value people over processes
  2. Deliver a little, deliver early, deliver often
  3. Don’t rush to code (no, this doesn’t contradict point 2)
  4. Don’t over-specify — don’t under-specify either
  5. Know what your test cases are before you design your product
  6. Avoid premature precise estimates
  7. Never negotiate estimates
  8. Continuously refine estimates
  9. Do negotiate what will be delivered within a spend ceiling
  10. Do not base the spend ceiling on the estimate of effort/cost to deliver the product
  11. Do base the spend ceiling on what the business is prepared to spend to gain the quantified business benefits from the project
  12. Don’t demand that people do more than they can do in a 40 or so hours 5-day week
  13. Cancel the project if it ceases to stack up against its business case (this form of cancellation is a success not a failure)
  14. Don’t base the project plan on some theoretical “religion-based” (e.g. Extreme Programming or RUP) methodology
  15. Do base the project plan on delivery of product features
  16. Continuously revise the plan

I could go on and on — hope you get what I mean by “agile” with a small a — and I can’t overemphasise how important it is to value people over process: value fit-for-purpose product over too much documentation: value continuous involvement of the customers.

Now for Agile with a BIG A:  My observation is that Agile with a big A is a poorly understood (by management teams) brand — actually I think it is a fad — driven by a hope for cheaper, quicker, and better.  It possibly is driven by a “free lunch” mentality.  To pick up on Shane Hastie’s terms we are looking at a Tragile or Fragile approach that, of course, will fail to deliver.

To achieve true agility the whole team must work within a highly disciplined environment and use skills.  Few organisations are sufficiently mature to insist on the disciplines and to spend enough money on training. It is important here to differentiate between education and training: when I’m educated I know about, possibly know how to:  when I’m trained I have demonstrated my ability to perform the task to the required standard and I respond automatically as required to stimuli.

 

Posted by John Watson

CHAT
EMAIL
CALL