Don’t play the Hero

I don’t know why, but I still shake my head at continuing heroic behaviour in the industry.

I am reminded of my boyhood heroes the Commandos, subject of the very moving Spean Bridge memorial. Each time I visit there, I see soldiers and heroes, my admiration mixed with a sadness, which reduces me to tears at the sacrifice they and their more recently commemorated colleagues have made.

As a fighting force the Commandos would resolutely point out that they do not aim to be heroes. They are highly motivated, extremely well trained and led and they only go into action after careful planning. If they are forced to be heroes then the organisation has failed. That’s not to say that there haven’t been disasters and individual heroism, but they are minimised by having

· A sound method – shock, speed and overwhelming force

· clear objectives with defined tasks,

· realistic schedules,

· sufficient resources (human and materiel)

· good risk management – intelligence and back-up plans.

The same skills stand us in good stead in IT where the human stakes are, thankfully, usually much lower. It might however be better if we were to leave the guns at home.

Heroes don’t need measurement

Heroic project managers fight fires, and they love it. They get a buzz from it and they drive their teams to deliver despite the obstacles. They resist measurement – if the budget isn’t spent, they’re fine. Or are they? The Standish Group in 2009 reported that only 32% of projects deliver on time and on budget, 24% projects are abandoned and the remainder deliver late or partial solutions. This results in the familiar witch-hunts, and the shedding of those to “blame” for the failure, even when management have not the slightest clue why the project has failed and who was really responsible.

Of course some poorly controlled projects do deliver, but often at the price of excessive process, over-manning and slow delivery. When the sandbagging of resources becomes apparent then we start to think – what should we do? Organisations start on the first of the steps of the road to reduced heroism. By following this road we can increase delivery success and get the best from the mere mortals that most of us are.

The four-step process is summed up as:

· Reporting – looking back at what you’ve delivered

· Understanding – why projects deliver as they do

· Managing – managing development processes to maximise productivity

· Predicting – using data to plan strategically and maximise value.

In my next blog I’ll take a closer look at the four steps.

Click here to read the rest of this entry »

Well, here we are in 2012, and I hope that it’s a good one for all of you.  Looking back on 2011 is interesting; some good things and some bad things have happened; some things have changed and some stayed the same.

For me the good thing has been the chance to contribute to the industry within DCG.  I’m still taking small steps here in Europe, but there is a measurable advance on a year ago.

The not so good thing for those of us in SW processes is the sad loss of Grant Rule.  I only met Grant once, but I corresponded and, like many people, I took notice of what he said.  What I found refreshing particularly was that he had moved beyond measurement.  By that I don’t mean that he had abandoned measurement, quite the opposite, but I think he felt that in a mature industry measurement was so integral to the process that the data simply supported a drive to more effective software development. Measurement is a tool and not an end in itself.  This is something I have always believed and certainly drives us in DCG.  I will miss his observations and his immeasurable contribution.

A positive change for me has been the increased traction for IT-CMF.  We now have a practice dedicated to this new framework. It’s a work in progress, but I know already that by improving communication between IT and Business and by enabling specific issues to be identified and addressed, IT-CMF is another powerful tool in our armoury. Watch this space for an update.

One thing regrettably hasn’t changed much, and that is the unwillingness of some managers to embrace measurement.  There seems to be a deep psychology of heroes who become managers and they still don’t get it that most of us would prefer to sleep at night. For example, I know of a failing project in the UK where the team was working 70 hours a week for months on end, and even when the manager was given measurements that showed that there weren’t enough hours left to actually run the required tests, his response was - “If we all pull together we can deliver this.”  Go figure.  That is one of my challenges for this year, and I’m fortunate in having one listening client where they are trying to change the culture.

Enjoy your year, I certainly intend to.

I am a scientist by training, and in discussing bodies of knowledge both in science and in software measurement I often run up against the  “But it’s only a theory” argument.  Let’s get this clear there are at least two definitions of the word theory.  One is based on the concept of an idea that is unproven (hence the cheap but wrong-headed trick often used by deniers of the Theory of Evolution), but the second, scientific, meaning is that a “theory refers to a comprehensive explanation of an important feature of nature supported by facts gathered over time.  Theories also allow [users] to make predictions about as yet unobserved phenomena.” The definition in quotes is from the American National Academy of Sciences.  It is one of the simpler definitions, but it sums things up rather nicely.  I have substituted users for scientists in the definition above because I think it has a valid application in considering software performance.

We have now got a Theory of Software Performance covering the whole software lifecycle, from thought to closedown.  Over the last thirty years our industry has been under the measurement spotlight and we now have a considerable body of knowledge which enables us to predict the success or otherwise of our projects, and measure the health of our products.

So sound is this knowledge that predictive models are available.  For estimating there are tools on the open market including SEER™ and of course CoCoMo, which is available to all.  Backing this up are Benchmark Databases, including our own, where data are available for comparison against the performance of development and support teams.  Good process driven risk management such as that provided by De-Risk™ enables monetary quantification of risk adding further opportunities to control projects and programmes.  Add to this, analysis tools such as CAST™ provide us with clear diagnosis of the health of existing software.

So fundamental is measurement to the Software Performance Theory that metrics is incorporated into standards such as CMMI at the most basic levels of maturity.   Yet everyday I come across organisations which subscribe to the “only a theory” argument, describing metrics as an overhead, or simply ignoring the facts and throwing money at problems.  Here are a few examples:

Client process failure
The death march project where team have been working 60-70 hour weeks for months and the project has missed all its deadlines.  Despite clear metrics to show that the project is undeliverable, the management view is that if  “we all pull together” somehow, magically, all will turn out for the best.  There has been a clear failure of process from end to end, and the client hopes that by throwing money at it the problem will go away, yet a glance at the data would show otherwise.  Not only will problems remain and grow during development, but the downstream debt is likely to be enormous as defective code is fixed. How do we know this?  We (the industry) have the data and we can predict it.

Development process failure
Established organisations complain that their development projects always over-run on cost and budget, and yet when asked they neither collect effort data for tasks on a weekly basis nor even at the end of the project to enable them to improve predictability.  Add to this no view of size and schedules guessed at by developers and project managers and the results are bound to be chaotic.  How do we know this?  We have the data and we can predict it.

Joint process failure
A third group always delivers on time and on budget.  “We are the good guys,” I hear them say. “We monitor our spend and we never overrun on cost or time.”  They puff out their chests and many management teams pat them on the head and give them bonuses, but a quick look under the bonnet indicates that things may not be so rosy.  I have had a programme manager tell me that for years all a programme’s projects were delivered to within three per cent of the detailed estimates – produced a year before delivery.  Looking at the data, these roughly 1000 function point projects were delivered with up to 80 change requests submitted after the end of design with some arriving during user acceptance tests.  Funnily enough these change requests seldom impacted the total budget, unless client senior management introduced major changes or cut budgets mid-year.  Clearly, potential overspends resulted in de-scoping and underspends resulted in added functionality to mop up the budget.  This is great if you want to spend a client’s budget, and they may want you to do this, but as we know late change drives up defects, increases complexity, threatens schedules and decreases productivity.  How do we know this?  You’ve guessed it… We have the data and we can predict it.

With all of these examples it is impossible to effectively measure the value of the software development organisation, and all the behaviours I illustrate tend to increase what has been called the Technical Debt of the organisation.   This builds up as a result of poor requirements definition, multiple changes and incomplete testing resulting in poor quality code which must be fixed in the future.  The resultant total cost of ownership is higher than necessary, but worse still it is unpredictable.

Development projects may deliver to a cost, which may not be known until after go-live, but the downstream technical debt built up as a result of defective code can have measureable economic consequences on the organisation and beyond.  Failure of banking systems to be delivered on time leads to regulatory fines, holiday booking system failures affect holiday makers, hoteliers and the holiday firms themselves.  Government failings are well known.   For example the replacement Child Support Agency system in the UK was in the headlines for a number of years as a failure.  The system was fundamentally unstable.  The Parliamentary Public Accounts Committee investigated and it was shown that the developers were forced to accept 2,500 change requests in a three-year project.  It was clear that when asked the Agency head had no idea just how out of control his requirements team had been.  The result was a debt visible to the public, but what was not visible was the cost of fixing the resultant mess.  That, I suspect, took several years and a lot of money.  The head of the CSA resigned.

So why do parts of our industry still persist in seeing non-financial measurement as an awkward overhead? Answers on a postcard please.