Slow and steady

Agile software development is in many circles being promoted as the flavour of the month, the silver bullet deemed to cure all software development ills. This is, of course, unrealistic, as agile on its own is just another method for developing software. Anyone seeking to change their lives or revolutionise their business will end up disappointed.

Agile certainly does confer many benefits, if done correctly, but it is a life-long journey to improvement - and it will require significant disruptive change in organisations, ranging from budgeting to testing, from business analysis to the choice of tools, from the behaviour and composition of teams to the expectation of management.

But even agile cannot guarantee business value - there is far more to return on investment than simply implementing the latest methodology.

Many organisations adopt agile for agile's sake.

Ziaan Hattingh is MD of IndigoCube.

Considering that some of the earliest attempts at formalising software development date back to the 1950s, and added to this the fact that the Agile Manifesto was signed in 2001, then it's fair to say that agile is a relatively new addition to the software development landscape. Consequently, many of its advocates may understand the theory of agile well, but lack practical experience with its implementation because of its relative newness - especially in enterprise environments.

While agile may be the way forward, there is seldom any detailed consideration given to what value the organisation can expect to generate from adopting agile development and how to unlock this value in the process. Most advocates who promote the agile route shy away from that question - they don't know the answer, and opt instead for promoting a leap-of-faith decision to go with agile because it's the way all forward-looking organisations are going, as far as they can determine.

There is little doubt that adopting agile delivers benefits, but organisations planning to adopt agile need to be sure that they are in fact going to generate that value. Many organisations adopt agile for agile's sake, attempting to convert to agile in its totality in a sweeping change throughout the business. The inevitable effort, change, churn, and disruption end up becoming costly and often the reason why executives call into question the whole initiative - they simply cannot see the value under these difficult circumstances.

The better way to shift to agile is to look at what pains are being experienced with the current software approach, and then select parts from one or more of the various agile methodologies to specifically address these issues. Rather than selecting a methodology to implement in its entirety, it makes far more business sense to select appropriate practices from a variety of agile methodologies and to implement those incrementally.

Contemporary thinking around adopting agile methodologies favours a practice-based approach rather than a holistic or methods-based one. Agile comprises a wide range of practices, and organisations do not necessarily experience greater value by adopting them all. Some of the practices might not be relevant, necessary or generate value, and if not required or suitable, might only serve to disrupt the organisation.

Agile can be regarded as a box of tools to be selected according to requirements and the value they can generate for the business - they can be prioritised and adopted accordingly. By selecting the agile practices that will specifically address urgent problems, change is introduced in small bites rather than in sweeping reforms that cause disruption among project teams. Steady incremental enhancements lead to progressive improvements in productivity.

Achieve results by starting small, having realistic targets and, step-by-step, working towards a vision of where the organisation aims to be by introducing one practice at a time. After all, isn't this the overall approach to agile - to approach it in increments, rather than as one massive exercise?