Agile – the way forward for projects?

One of the biggest flaws with the traditional “waterfall” model of software development is that the customer requirements are only validated at the end.

Of course this reveals two types of flaw in the documented requirements:

  1. They were simply wrong/inadequate in the first place
  2. They have been overtaken by events

This is particularly obvious in long defence projects like the F35 replacement for the Harrier, or public vanity projects like the Millennium Dome and Scottish Parliament Building.

Much of the cost-overrun of big projects results from the delays and rework costs of enhancing the finished product to meet the newly-clarified/revealed requirements.

So – if you get the requirements right and build to meet them right first time, the project will stand out as being cheaper than normal. The Rion-Antirrion Bridge in Greece is a fabulous example of getting it right first time, and Cross-rail is looking good too.

The huge strength of the Agile approach is that it validates requirements as it goes along, by integrating end users into the development team, and for software development projects this is great (with a couple of caveats). This means that Agile projects have a tendency to be more successful and better value for money.

So is it a no-brainer? Should we do all projects as Agile?

Agile isn’t necessarily cheaper – the Rion-Antirrion Bridge wasn’t Agile, and there are Agile projects that have gone badly wrong.

In my experience, the Achilles heel of Agile is that if the fundamental requirements are not adequately understood at the start, the wrong “architecture” of the solution can be selected and only when a lot of time and effort has been invested does it become clear that you’re on the wrong horse. Swapping horses in mid-stream is difficult and risky, and usually hugely expensive, so the pressure is on to struggle on and make do with what you’ve got.

I prefer a multi-stage approach with rigorous feasibility assessments in managing major strategic projects, where the architecture is really sorted out first. The Rion bridge needed to be tackled as a single entity, because that is the way it functions. Picking the wrong ERP system crippled the business and IT strategy of a FTSE 100 company, leading to a complete U-turn in its IT plans.

Agile approaches have some real benefits, but need using with care, and must not be used as an alternative to thinking the problem through first.

What Really Makes Change Fail?

This post by Steve Barlow intrigued me: I think he has some great insights, and the idea that we are not “change fit” is a new idea for me.

I agree completely that people are usually delighted with change they see as an improvement e.g. mobile phones, the Internet, on-line shopping, Sunday shopping etc (though you will find people who hate all of these things). Forcing change on people, when they don’t see the benefit, fear they will be worse off and don’t see why it should happen, quite naturally falls far short of a no-brainer!

I like the idea, though, that even desirable change fails because of mental flabbiness!

Looking at the metaphor Steve offers; I know why my New Year’s resolutions fail – the pain of changing my lifestyle in the short term outweighs the long-term benefit (no pain, no gain). It never ceases to amaze me the obsessional self-sacrifice it takes to become an Olympic athlete – how do they do it?

I think there are 2 key factors:

  • They invariably have a coach who eggs them on and sets just-achievable goals
  • They are able to visualize success in a very realistic way – what it will feel like to mount the podium and collect their gold medal – and how they will win – every move, muscle twitch, metre of track etc

Coming back to business change, what can we draw from the parallel?

  • I believe that project leaders need to act like coaches, encouraging the team and setting challenging but achievable goals
  • I believe that project leaders must support all stakeholders in understanding and feeling the benefits of the objective, explaining how they will get there and soothing fears of the unknown

These are 2 very different skills sets – planning and communication, but both are clearly essential for success in my experience.

The vision – key to success

Many years ago, I learned that building a shared vision and working towards it was vital in married life. I’ve also found the same to be true of business change.

Reading this article on documenting a clear vision reminded me of two discussions with prospective clients; both had decided what they wanted to do without having a clear vision of where they wanted to get to. When I started to investigate their vision, I ended up with the reaction “you’re too strategic”.

I speak from bitter personal experience that it is very easy to get busy doing tactical things that take you in the wrong direction if you don’t have a clear vision of where you’re trying to get to. Losing stakeholder support is even easier if you can’t share a clear definition of what you’re trying to achieve.

I’ve found you can’t be too strategic when it comes to being clear about where you want to get to, and it really helps to take stakeholders with you if they can see what it will be like when you get there.

Be very careful when selecting the information you act on!

Just read this interesting article on how selecting the wrong sample of people to listen to can skew your choice. This prompted recollections of the business intelligence strategy work I did at Willis and Centrica, and a warning story about data mining, where the “training data” wasn’t randomly selected, leading to astonishing performance that was too good to be true, sadly.

I’m currently engaged in helping a client move from having no data at all to a (hopefully) detailed and balanced view of the problems their customers face in using their products. At the moment they’re planning product development through a mixture of informed opinion and guess-work. It’s good that they are unhappy with this situation, but the solution is a challenging leap for many of them – become a customer-focused organization speaking to the customers frequently and in detail.

As scientists and engineers, they are comfortable working with numbers and precision – they just don’t have the data required, and that can only come from from the customers themselves. We’re working on how to collect and analyse as much data as possible, prior to developing a phased development and deployment plan.

This has just reminded me that we need to build in data quality detection and management to detect skew before they make the wrong choices!

Public praising of those who perform – can you do too much?

According to this article by Gretchen Rubin on meeting behaviour, yes, it can make them feel patronized.

I shall have to watch myself, as in a nation full of people who give little or no praise for success, and plenty of vitriol for “under-performance”, I’m very happy to praise people who do well.

Perhaps the reason I’m enjoying my current assignment at The University of Manchester is that I’m working with several high-performing people and I have the chance to praise them quite sincerely. Plus, I’m getting praise back for the team’s progress.

So the bottom line is that praise (where sincere) is a good thing, but be careful not to overdo it!

More haste, less speed – not taking the user with you

I have come across the same phenomenon twice in a row on assignment:

An IT visionary pushing for rapid change in IT that demands a large-scale business change

So what is wrong with that? Nothing, so long as the required steps are taken to bring the Business and particularly the users along!

The current economic climate is one of change, most of which is uncomfortable or even painful for the business users – it’s the easy option to claim that “people just don’t like change, and must be forced”.

My experience is that people want to do the best; it feeds their self-respect!

To do their best, they need to UNDERSTAND what they need to do, and why. Poor business understanding of “IT projects” causes mistakes, delays and quite possibly FAILURE.

Many large organizations retain an almost pathological “need to know” policy, where managers distrust their staff’s discretion – this clamps down on communication, crippling that vital understanding. In the absence of knowledge, people fear the worst and resistance to change builds and feelings of insecurity spiral up.

Effective business readiness for any IT change must include a strong campaign of user engagement throughout – understanding needs and aspirations, explaining the changes, user-testing of solutions and training – and it will pay off.