Comments on Cornwell - an Agile company: An Agile Enterprise

Another comment that I saw recently occurs to me. ...

2010-05-27T14:45:01.883+01:00

Another comment that I saw recently occurs to me.
Al Goerner of ValTech said in a presentation (http://www.slideshare.net/stephenellliott/agile-e-business-valtech-agile-edge-london-march-2010-al-goerner, slide 2), "An Agile team in an non-Agile environment will not long survive. Development Agility & Business Agility go Hand in Hand."
The evidence to support this observation comes from the number of organisations who have attempted to adopt Agile development, done the first couple of pilots, then run out of steam, and eventually given up.
Unless there is a parallel cultural/management shift in the host organisation, Agile cannot fight perpetually the odds. The pilot projects must be accompanied by an engagement with the management to manage IT and change using Agile values, and practices.

Hi Jim I could not agree more, especially about t...

2010-05-19T11:30:34.187+01:00

Hi Jim

I could not agree more, especially about the difficulty of putting Agile across to the business. Some years ago I implemented DSDM (then the preferred flavour of Agile) at Churchill Insurance. As far as the core processes were concerned, there was no great difficulty, but the business was a problem for two key reasons.

The first was allowing their representatives on the project enough authority to approve of what was going on on the spot (e.g., prototypes, changes, reprioritisations, etc.), without constantly referring to senor management. The second was getting the required effort from their representatives – they were necessarily very experienced and valuable people (who else would you empower?) but that was precisely what made them hard to backfill in their day jobs. So they needed to spend about three days a week on the change project, but also five (usually very long) days on their BAU work.

So although the business was keen on an Agile approach, they could not participate effectively. It was a long struggle – only partially successful – to deal with this problem.

Your comments reflect one of our central findings,...

2010-05-19T10:34:26.518+01:00

Your comments reflect one of our central findings, that agile is not an easy option. You have to get a lot of stuff right to do agile software at an enterprise scale. To present a good Agile software service to the business, the swan has to be paddling very hard. The benefits of agile come from reduced risk of failure and better, and earlier outcomes/benefits.

Nevertheless, I will return to the hypothesis of this particular blog, that people are agile, and we should try not to inhibit their agility by imposing rigid structures, giving them more obstacles to work around. Again, easier said than done. The banks have proved to our great expense, that empowered management without appropriate constraining values, and clear direction, can/will lead to undesired outcomes.

Any Agile change programme is faced with starting from here (rather than "I wouldn't start from here"). It is not reasonable to expect a fully formed agile ready organisation. Part of the early analysis as you suggest must include a readiness review of people, processes, and culture - standard change management practice, not to be neglected in agile. Any plan of action must be designed to accommodate the state of the organisation, not just in IT, but in the main business, to understand the decision making and management/delegation models in target areas of the business.

In my experience a crucial precondition for achiev...

2010-05-18T19:15:16.704+01:00

In my experience a crucial precondition for achieving agility is a certain level of maturity. Agility presupposes the presence of quite a wide range of highly standardised core mechanisms of which the agile operations can take advantage.

The classic example, familiar from IT development (whence agility sprang, of course) is test automation. Without this the development team is unlikely to be able check its day’s labours swiftly enough to move on confidently the next day. But test automation itself can only be adopted by an organisation that already has standardised test classes, a well established test process, a clear understanding of the basic mechanisms of test scripting, and so on. Without all of these (and much more), test automation will fall flat on its face – becoming either ineffectual or rigid – and quickly start to turn agility into paralysis.

Of course, in a vey small, simple project or activity, the preconditions for agility are very limited. But in a more complex situation, such as BAU operations or a large-scale programme, agility can be achieved, but only ensuring that a full ‘agile environment’ is also in place. The elements of this environment can themselves be agile, but they certainly must be present and specifically geared to allowing other areas to take them completely for granted – it is, after all, the most basic basis of agility that the would-be agile activity can either omit or take for granted that everything in their environment.

Hence one of the key tasks – perhaps the single most important – when implementing agile methods is to investigate what the organisation’s ways of working can offer to the agile area – and what they demand from it too.