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 task – perhaps the single most important task – 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.
A few (there are many more - this is just a flavour) of the areas you need to get right include:
- A governance system that allows for rapid validation and approvals of many incremental releases.
- Business and operational organisations and processes that are capable of assimilating frequent change.
- Office arrangements that support closely collocated teams.
- Extremely slick mechanisms for remote groups – vendors, outsourcers, other offices, and so on.
- System architectures that support rapid change.
No comments:
Post a Comment