Skip to main content

Agile development: What it means, the myths, and how to make it work

(Image credit: Image source: Shutterstock/niroworld)

The IT departments of many large corporations claim to be ‘agile’, but they’re faking it. They value predictability and control over product innovation or success. They will, invariably, simply be following a waterfall process with some scrum or standups. The latter are not indicative of a genuinely agile feedback loop, but rather being done more as decoration.

Instead, products are developed in a linear fashion, one after another – according to, say, a predetermined plan that’s one year in the making and another year in the execution. All on the presumption that the world at the beginning of that two-year process will be the same as at the end.

Large corporations are forgetting what agile means. Or, perhaps worse, they don’t know what it means to begin with.

What does Agile Development actually mean?

“Agile” was originally a software discipline, where it refers to largely self-organising teams practising evolutionary development and adaptive planning; it was a more pragmatic way of building software on time and on budget than the old-fashioned “waterfall” or predictive planning. In practice, “Agile” development mitigates project risk: you won’t get to the end of a process and discover you have an awful product, as there’s plenty of regular feedback loops and checks built into the process. This is opposed to the older method of building large swatches of software in long chunks. At the end of that process, if it’s broken, you’re stuck with it.

When agile development first emerged, this piqued the interest of large companies as agile techniques could help them overcome the failings of large IT departments -- prone to struggling with too many complex, interdependent variables and suffering persistent project failure.

The Myths: “Agile doesn’t work for us”

So why isn’t it working? On the face of it, if large corporations bought into the process, their IT departments would be invariably better for it.

I think the issues begins here. The agile mindset is comfortable with uncertainty. It should follow a clear strategic vision, but it doesn’t pretend that it can predict how the world will be in two years’ time. In today’s world, this is vital.

In a business that puts agile at its core, teams will be interdisciplinary and have the autonomy to make decisions, use organisational structures that promote cross-functional working, use adaptive planning, and adjust according to what the team learns through making and testing real things (rather than talking in meetings, or not talking at all).

Therein lies the rub: Aspects of agile run right against the grain of  conventional business practices. When agile works, it causes friction. Successful agile development means that products are being re-thought mid-project, code is being rewritten, and decisions are being made, and altered based on feedback. Therefore, if agile isn’t causing certain frictions, then is isn’t being done right.

The truth of the matter is: all businesses that are digital at their core, will be agile. Agile isn’t going away. However, any business that thinks that agile is a fad, or a veneer, or something to be ‘seen’ to be doing, will fail. So don’t be surprised by an agile backlash from our staid cousins in starched shirts.

How to do it right

Agile is more than daily stand-up meetings and scrums, it’s a complete change to decision-making processes, it involves an unfamiliar degree of honesty and enquiry, of collaboration and the distribution of authority through a flatter organisation.

There’s a tendency to do “agile light” to avoid the inevitable challenges; and there’s a tendency to apply agile in areas where innovation and change isn’t appropriate. In a highly regulated, process-based environment, agile can genuinely be disruptive.

First, CIOs or CTOs need to ask, “do you need to be agile and, if so, which parts of your company do and where should you begin?” If all you’re being offered is a series of workshops on how to be agile, that’s only going to scratch the surface. Becoming agile is more than just doing a workshop. It involves changing mindsets, decision-making processes, hiring new talent, building new capabilities. It’s more than having a stand-up meeting and a scrum coach, it’s changing by making software.

Reaching agile is a heady goal. It means your company will be better able to respond quickly, to customer need, in a way that is sustainable to business.

When you don’t need to do agile…

I will also add a word of warning here: there are some contexts which make agile development that wrong solution. For example, a situation where repetitive process and known qualities are important. For example, you don’t want your call centre to be agile – that’d be a disaster. In a call centre, you want people to follow a very strict set of processes.

Another context is where you are better off pursuing incremental efficiency gains. Then, it’s not just overkill – it’s damaging. You see this in banks and insurance companies – departments doing business as usual and someone comes in and says “we’ve got to do agile”. Agile is the antithesis of ‘business as usual’ because it’s about doing things differently and continuous innovation, and you don’t always need to do that. Especially if gains can genuinely be made on the margins.

What does it mean to be agile?

But, when done correctly, businesses will have the tools to harness dynamic and powerful forces in the pursuit of growth. True agile will give its adherents the right mindset and a set of capabilities fit for the post-modern era.

This all raises the question, what does it mean to really achieve agility?” The process involves a change of mindset, organisational structures, skills and process and can only be learnt through doing; new attitudes to investment process, mitigating risk, relinquishing a command and control mentality.

William Owen, Made by Many