These days, everybody wants to be, or claims to be, agile.

It’s a great term isn’t it? To be agile, to be nimble, to be quick, to be able to jump over the candlestick – all are qualities that customers love to see in any business. Well, perhaps not the candlestick jumping, taking into consideration health and safety regulations.

What do we mean by ‘Agile’?

‘Agile’ is a way of thinking and working that started to emerge almost 30 years ago as software development teams struggled to produce products and services quickly enough to a high quality, and without spending money on a finished product that was already outmoded.

To combat this issue, a group of software industry leaders got together in the 1990s to debate how things could be more, well, ‘agile’.

The result? The creation of the ‘Manifesto for Agile Software Development’ in February 2001.

Is the ‘Manifesto for Agile Software Development’ purely for software development departments?

These days it’s usually referred to simply as the ‘Agile Manifesto’. There are four points within it which could be applicable to many organisations and industries – not just software development.

To help paint the picture, allow me to introduce Lucy, who follows the Agile principles, and Barry, who doesn’t.

  • ‘Individuals and interactions over processes and tools’.

Barry works for an organisation that deals with a variety of different customers. The problem is, where Barry works, things are so regimented and formal that his customers are often left high and dry. They only speak in pre-arranged meetings and they stick to the same stale agenda every time. Once, Barry missed an important change to a requirement because he hadn’t checked his email.

It’s a different story for Lucy. Lucy has built a great relationship with her customers over the years. They have regular meetings but these are mainly informal. If there’s a problem with the project, Lucy’s customers phone her and they discuss it immediately. Those conversations aren’t always easy but they’re always open and honest.

  • ‘Working software over comprehensive documentation’.

Of the seven major projects that Barry has worked on, four of them were late delivering and cost a lot more than everyone had expected. The other three were cancelled because the customer lost faith in the project team. In spite of the late software (or complete lack of it), there were so many plans, technical designs, test strategies, risk mitigation statements, and cost projections, that for a while everyone felt really confident that the projects would be a success.

What about Lucy? She still has documentation on her project of course. Her team, which includes client members, focus on having some actual software to look at in their regular demo, every couple of weeks.

  • ‘Customer collaboration over contract negotiation’.

Once a month, Barry and his team meet with their customers and talk about whether they’ve met the Key Performance Indicators (KPIs) laid out three years earlier in their contract. They discuss why they haven’t managed to release the latest updates because they have a strict agreement over how many additional hours Operations staff will work after 4pm on a Friday. Their customer points out that in Clause four, Paragraph two, that they should make “reasonable endeavours”, at which point Barry refers to the definition of ‘Reasonable’ as defined in Appendix two, and explains why this doesn’t apply under these particular circumstances. Everyone’s tense, everyone’s unhappy, nobody feels that they’re being treated fairly.

Lucy’s team are trying to release a new update for their customer. She is a bit worried that making too much change at once is a risk, particularly as a key member of the team is out of the office for a few days. Lucy phones her customer and explains the situation. Her customer knows that Lucy phoned because she sees her customer’s success as her own success. They talk for 20 minutes and decide to split the update into two separate releases to reduce the risk, and to have one of the more important changes in place before Monday morning. Like Barry, Lucy also has regular meetings with her customer and they discuss how the project is going and how the teams are performing to help ensure that the customer is happy and that Lucy’s team are happy as well. Similarly to Barry, Lucy has a contract and set KPIs. However these don’t define the entire relationship, but rather are the starting blocks for the project.

  • ‘Responding to change over following a plan’.

One of the biggest issues about Barry’s way of working is that he and his team are unable to understand why their projects always go badly and disappoint their customers. They follow their plans perfectly. In fact, that’s part of the problem – they’ve spent so much time planning that they feel obliged to stick to them regardless of how the world might have moved on around them!

Lucy’s team realised a long time ago that plans are useful to get things going, but very quickly things change, including the priority of what their customers would like delivered. Lucy’s team prefer to keep a high-level plan to ensure flexibility. Lucy talks with her customers every day to discuss how things are going and every couple of weeks they tweak their schedule to help ensure that there are no (or very few) surprises at the end of the project.

Embracing Agile has certainly helped Lucy and her team. In reality, though, Agile is not a magic bullet and requires a huge commitment from the team, the customer and all project stakeholders.

There are a number of defined frameworks under the umbrella of ‘Agile’, and picking the right one for the project is usually key. Whatever your chosen approach, the magic happens by shifting the focus from up-front planning and control to one of collaboration, cooperation and communication.

Agile development can be a very exciting and invigorating approach and the effects can be dramatic. Ultimately, teams experience a much richer and more rewarding project and deliver better software, products and services to happier customers.