Agile project management: how to regain the lost art

 

The word agile has been hijacked. Reclaim its meaning and reap the rewards, writes Jerry Stubbs

ILLUSTRATION: SIMON BRADER

Your thesaurus isn’t faulty: agile is not a synonym for efficient. Fifteen years ago, agile was the word that summed up a revolution. It marked an end to the IT crowd’s old ways, where software guys did stuff other people didn’t understand and their clients just had to wait for it to work.

Agile disrupted an entire industry by urging everybody concerned to take a more progressive, collaborative and transparent approach with their colleagues and clients. Suddenly software development was about partnership – not “us and them”.

Fast-forward to the present day and the term agile has been hijacked. It is often wrongly used to mean any product or business process that is more efficient, or just better, than the last project or product: “Check out the more agile version of Google Maps.” In fact, Google’s development of its maps app isn’t much to do with agile. The update is just superior. Big difference.

The trouble with misusing language is that you lose meanings. Lose meanings, lose clarity. Lose clarity, lose focus. So muddy has the meaning of agile become that many senior decision-makers no longer have much idea what agile is and how it – in its proper form – can benefit their company. The loss is felt by both supplier and client.

The industry needs to reclaim the word agile – and fast. And it needs to start spreading the true word to its clients. Newcomers to the sector should visit a project management website to read up on the Agile Manifesto – a bible for millennial IT professionals wary of alienating their own clients from software development. The manifesto is perceived as being covered in virtual dust: a tome no longer fit for an age in which few can find time to talk. But like so many ageing key texts, business rejects it at its peril. The core beliefs within the manifesto – namely interaction; collaboration; and responsiveness to change – are still relevant to projects.

Back to agile

As agile has lost its meaning, a paradox has emerged. There is an expectation that everything can become “agile” coupled with the fact that leaders rarely entrust their teams with the autonomy needed for agility to occur. The ability to self-organize in supportive environments leads to agility; command and control and micro-management leads to the exact opposite.

Setting teams free to interact directly, and quickly, with internal and external clients and other teams, is key. To do this, we need to find or train customer-facing software teams, and reject the industry jargon and siloed ways of working that continue to set IT apart from the business and from operations.

Agility still matters. By applying principles carefully carved 15 years ago, the modern age will prepare teams to grapple the next major technology challenge. It’s time to relearn what agile means, and to regain it.

THE MYTHS

Myth 1: Process isn’t agile

The myth stems from the fact that overly detailed process documents are rarely workable in today’s fast-moving world of software development. But it is false to say that agile teams do not have a process. In fact, process is still crucial – but wise and agile development teams reject canned processes in favour of evolving their own.

Myth 2: Planning isn’t agile

Much of the IT industry has rapidly developed a myth that the very concept of planning projects is somehow un-agile. The idea seems to be that truly agile teams don’t plan – they just act. This is nonsense. Agile teams are always planning – but they are willing and able to adapt their plans at short notice when the brief or the situation changes. Flexibility is the key to success. Agile teams are constantly looking ahead. Un-agile teams make a plan and refuse to change it as circumstances alter.

Myth 3: Discipline isn’t agile

When did agile come to mean disorganized? Chaos and last-minute decision making are recipes for failure, not success. Agile teams break down their projects into manageable chunks and are rigorous about timekeeping. When every small stage of a project is completed in a timely and disciplined fashion, adapting to new circumstances – becoming agile – is easier.

 

Jerry Stubbs is head of agile at software quality testing specialist SQS

 

[button type=”large” color=”black” rounded=”1″ link=”http://issuu.com/revistabibliodiversidad/docs/dialogue-9-sept2015/50″ ]READ THE FULL GRAPHIC VERSION[/button]