Category Archives: Project Management

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

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



More on Agile and “failure”

I agree wholeheartedly with the points raised by several people about the definition of project failure.  I think it is commonsense to cancel a project once it is realised that the business case is poor or unrealisable.

A significant question to ask is, “How often is the business case expressed in terms that could later lead to outcome realisation testing?”

My ongoing experience is that organisations still put insufficient effort into defining “proper” business requirements.  This leads on to situations similar to,”The product behaves as required but our business has not improved”: or “We got we paid for but did we get a return on our investment?”  I suggest this is a form of project failure: possibly the most significant.  A possible (I think probable) cause is a lack of Project Owner/Sponsor skill.  Do the Project Owners out there actually understand the extent of their responsibility relative to project governance?  As a way of addressing this issue, the PRINCE2 people have instituted Project Sponsor Certification (not to sure about the value of certification — but at least it’s a step in the right direction).

I think that the lack of business requirements problem is exacerbated by the Fragile/Tragile practise of “the requirements are in the code!!”  It also bothers me that so many still seem to think the business requirements have something to do with the content, look, and feel of the user interface: the classic confusion about benefit versus feature. So many organisations still call Functional (system) requirements Business requirements.

I feel that yet another issue is the seeming lack of understanding about the difference between project governance/management methods and system development and maintenance methods.  I think Agile  is a type of SDELC and project governance should wrap around it.  I wonder if we should start Agile development only after business benefit requirements are well-understood and signed forward?

Looking at the issue of software becoming more complex, yes I agree it is. But I also think that there is much larger catalogue of solutions than there used to be.  Shouldn’t we be making much more use of “software ICs”:  electronic engineers rarely design their own components — they buy them from a catalogue.  I feel that there is an argument for software construction to move more quickly than it is toward software component integration. If you can buy it, why build it? The idea of software ICs is ofcourse not new:  what has happened to all the hype about reueability from just a few years ago?

Given that software projects are more complex than they were, this could well mean that the management of software projects becomes more complex.  That brings us back to the question of how do we improve project governance (of which individual project management is a part)?

People management is of huge importance: so why is it that so many Project Management offices seem to be staffed by grey bureaucrats with EQs approaching zero?

In the end it seems to me that my maxim, “Manage the requirements and manage the people, then the project will manage itself” holds true.

Posted by John Watson

Leave a comment

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



More on “Failure”

CIO Magazine has an article on the Chaos survey results in which they identify that many of the “failed” projects have been cancelled because of recession-related factors (funding removed, staff gone etc).  It says “Johnson [Standish Group chairman] estimates that 20 to 25 percent of the failures during the past two years were caused by the economy forcing project cancellations”

The trend is actually for better results in the “challenged” projects: “When we look at challenged projects, we’re seeing fewer overruns, and the waste to value ratio didn’t look too bad even given all the cancellations”.  Cost and time overruns are actually less than in previous surveys. 

The full article is here:

Posted by Shane Hastie

Leave a comment

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


Tags: ,

What is Failure?

For me one of the key questions about the Standish Group survey is their definition of “failure”.

I feel that cancelling a bad project early is actually a good thing, and this is one of the most valuable aspects of the Agile (big A) approach – all of the methods require of the team that they re-evaluate the business case at the end of every iteration.  I note the “waste” figure in 2009 is US$22BN – in 1994 it was US$73BN (in 1994 $$$).  “Failure” numbers have gone up but the waste figure has gone down, which seems to me to indicate that more projects are being stopped earlier – which is a good thing.

I don’t think we have degraded as an industry, but I do think we’re better able to stop bad work early. 

Offshoring/outsourcing results in approx 30% outright failure (contract cancellation) AFTER spending a year or more trying to deliver products.  This in my mind is truly waste.

Please don’t blame “Agile” for organisations that are actually implementing  Fragile (or Tragile) development approaches.  Any methodology or approach implemented badly – without regard for the disciplines and dynamics required to deliver working products – will result in waste rather than business value delivery.  For me Agile approaches expose this waste as early as possible and enables the project team to change direction or stop the work, building on the good practices from Iterative/Incremental development (eg RUP).

Tragile/Fragile development repeats all the problems and mistakes we’ve had as an industry since the 1960’s with the same predictable results.  Just calling it “Agile” doesn’t make the people or processes any better, in the same way as many organisations said they adopted RUP or RAD or iterative development, or any one of the good practices that have appeared over the last 30 years; what they really did was change the language but continue making the same mistakes, the same thing is happening today with Agile, and will happen in the future when a new brand appears. 

It is easy to hide dysfunction in sequential development projects until right at the end, and often the organisation has too much invested by that stage to admit the problem, thus delivering poorly fitting systems that don’t meet the business needs.

Are we actually going backwards?  I’m not so sure – I’m reminded of Tom DeMarco‘s talk at SDC a few years ago: the reason we are having trouble building systems today is that all the easy ones have been built – what we deal with today are more complex integrations, more complex technologies and more demanding customers. 

If I consider just one organisation I’ve worked with lately  they used to have COBOL applications running on a single mainframe platform using green-screen technology to record and report on the state of farm animals in New Zealand.  A farmer filled in paper forms with milk production and breeding records which were hand punched into the mainframe and the farmer then received a quarterly report of their herd status.  Today each cow has a RFID tag, as the cow is milked the exact quantity of product is recorded by the milking machine and transmitted via wifi to the farm central server, and synced to the handheld device the farmer carries with him/her from which they can scan an animal and immediately see the full veterinary history, calving records, genealogy and milk production records enabling them to make better informed decisions.  (I’m not even going to try and describe the breeding events and the details of bull productivity which they track).  They credit the changes in technology with a significant increase in milk productivity per animal across the NZ dairy herd – and an increase in wealth for farmers as a result.  The complexity of technologies and interfaces is orders of magnitude more complex than the mainframe systems yet their IT budget as a proportion of revenue has remained fairly static, and measured in business value delivered they are providing significant return on the money spent.

Underlying all this is the important recognition that software is built by people – people effectively working together with a focus on the customer’s needs will produce good results; people not collaborating and not communicating effectively will produce bad results.  Irrespective of the brand or type of process you apply it’s the people and relationships that make for effective software development.

I look forward to hearing from others.

Posted by Shane Hastie

1 Comment

Posted by on June 30, 2009 in Agile, Project Management


Software Project Success Going Downhill!

I don’t know about you, but I am sceptical about the methodology used by Standish Group to produce the Chaos Reports.  That said, the report content since 1994 has tended to support my subjective observations of the state of software production:  I did think we were improving and I do think we are now getting worse.

 Is it just me that is unsurprised by the latest update to the report that shows we are going backwards?

 I think an agile approach (with a small a please) is a good thing.  Wholesale adoption of Agile (note the big a) by organisations that have little understanding of the skill and discipline required to make it work is surely a bad thing.  I wonder if inappropriate use of Agile is what is taking us backwards.

 What do you think?

 Have a look at:

Posted by John Watson

1 Comment

Posted by on June 30, 2009 in Agile, Project Management


Tags: , ,