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

07 Jul

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-spelled 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


Posted by on July 7, 2009 in Agile, Project Management



3 responses to “Agile (note the big A) versus agile (note the small a)

  1. James King

    July 12, 2009 at 11:43 am

    I was speaking to my wife over a romantic candle lit dinner. Naturally our conversation moved to why projects fail so often in the real world when the practice of running projects is so well understood in theory.

    My wife’s view is simple – most people are not good project managers. They become busy and senior and so think they have run projects and then don’t know how to coordinate and run them when things get complex.

    My view is slightly different – what Agile, agile, Prince 2, PMI, Six Sigma and other approaches all have in common is that they assume that we will either know the problem we are solving or start by working out what it is.

    Sadly this is often not the case. So my theory as to why projects are failing is that we keep starting projects without knowing the real problem we are trying to solve. Then we try to get better at running projects by finding cool new approaches (such as lean Agile calisthenics) but still fail because we are working hard on the wrong things.

    So to me the answer is to cut back on the initiatives we start and to really understand what we want to achieve. Until then it doesn’t really matter how we run our projects.

    • jwpegasus

      July 13, 2009 at 12:58 pm

      I think that James’ comment supports my assertion that that the software development and enhancement process that we use (or at least say that we use) fits inside an overall project management process. So yes please let’s cut back on the number of projects that we commit to because we have sooner come to a fuller understanding of the true/real/actual business issue being addressed. Prince2, PMI or whatever needs to wrap around Agile, agile… or whatever: but the emergent detail of the project plan needs to driven by the emergent understanding of the product requirements which are a result of the emergent product itself.

      Start off with as clear a vision as is practicable of the business case then develop a product to meet the business case by delivering a little, early, and often. preferably the earliest manifestations of the product will be visual prototypes without resorting to code too soon.

  2. Sharon Robson

    July 21, 2009 at 2:10 pm

    Hi John, I agree very much with your statement:”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.” However I think that this is the crux of all our problems in IT. Not only agile benefits from these…all projects and approaches that employ the principles of discipline and skills, as well as mutual respect and understanding (that may well come from training) will be moving more towards “success” rather than “failure”.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: