Get pragmatic about agile

Pragmatic: "Relating to matters of fact or practical affairs often to the exclusion of intellectual or artistic matters: practical as opposed to idealistic." - Merriam-Webster

Agility: "The quality or state of being agile." - Merriam-Webster

It is easy to get dogmatic and enter into religious wars when it comes to the adoption of new trends and technology. We've seen it time and again, as purists insist that a new innovation should be approached and adopted in a particular way.

Think back to the days when object orientation was on everyone's agenda, and e-business. One guru after the other insisted their way of doing it was the correct way. It's similar today with agile software development.

The irony of it is that the very philosophy that underpins agile software development is not to be dogmatic but rather to re-assess priorities on an ongoing basis and to adapt one's effort to generate the most business value as soon as possible.

Almost every organisation I speak to that has had some experience with adopting or experimenting with agile software development, has a similar story to tell. They all speak about the challenges they experienced in getting the organisation to change to a different way of working. Most of them end up adopting some customised form of agile development which is invariably more of a waterfall nature than a true agile nature.

Culture is a powerful force - people and organisations change slowly to new ways of working.

Accordingly, I am in favour of what I refer to as a "pragmatic adoption of agility". While a 100% pure take-up of agile would lead to a pure and positive outcome, few corporations are ready for the sea change that a complete all-at-once adoption agile requires.

Their financial and emotional investment in traditional ways of working is too entrenched for that to happen.

Trying to force-fit agile onto people whose lives have been spent in a different paradigm can be both stressful and destructive.

Ziaan Hattingh is MD of IndigoCube

Moving from waterfall to agile does not have to be done as one monolithic exercise, even though many agile bigots would have it that way.

Pragmatic agility depends, then, on the understanding that you can't change everything at once. You need to change as much as you can, a bit at a time, while staying focused on delivering tangible business value, rather than adopting agile in one big bang - regardless of whether the adoption is on a standalone project or an enterprise-wide basis.

It might take as long as five to 10 years to change a large organisation over to agile from waterfall. In this regard, then, it would be folly to expect too much too soon and probably explains why a large percentage of agile adoption projects fail to deliver the required results.

The ultimate goal must be the transformation of the company to a state where it can more easily respond to business developments and opportunities as and when they occur, through the application of agile software development techniques and approaches.

Of particular importance must be the understanding that failure is not an option. So, while a long-term commitment to agile is key, the fact remains that few organisations are geared to agile, but are for waterfall, and trying to force-fit agile onto people whose lives have been spent in a different paradigm can be both stressful and destructive.

The correct approach would be to blend the best of both worlds: convince the existing development team of the benefits of agile while introducing agile on a planned, prioritised and phased basis.

The benefits of agile are patent for all who will see: but so are the initial trips and pitfalls. One of them is trying to do it all at once. This can only lead to tears, frustration and disillusionment. So, get pragmatic about agility and derive the ongoing return on investment.