The Agile Mona Lisa

by Andy Mayer
Posted on 13 October 2014
read time: 5 minutes

Agile is a key part of our project management approach and underpins everything that we do – from the programming languages that we use, to the design of our office layout. This post aims to explain what we mean by 'Agile', and why it’s so important.

First a bit of history about waterfalls

For the past 20 years, the most popular approach to developing software has been thewaterfall model. This is so-called because progress is seen as flowing steadily downwards (like a waterfall) through the different phases of specification, design, build, testing and go live. Each stage gets signed off before the next is started. This approach is still popular today (for example PRINCE2 follows this route) and you may well use it yourself:

Waterfall projects start by pouring a lot of energy into writing an excruciatingly detailed specification document to describe every imaginable eventuality the software might need to cope with. Once completed, it's then handed over to the design team to come up with the theoretical solution to be built. This theoretical design is then signed off and handed over to the software development team to turn it into a working system. After the software is finished, the project is tested and then finally launched and ends up in the hands of real users.

The problem with waterfall

It's not until after this final 'go live' phase that real users get their hands on the software and are able to give their feedback on what works (and what doesn't). Unfortunately, the specification document written way back at the beginning of the project forms a contract for the software development. So, if more changes are needed after the specification's been written, then it’s very difficult to go back up the waterfall to previous stages to change things – as the budget, plan, resources and legal contract have all been agreed based on the (now outdated) specification document.

With traditional (waterfall) projects it's very difficult to make changes to the software after the specification has been signed off at the beginning of the project. Unfortunately, it's at the end of the project that users get to use the software and give the most useful feedback.

Hello solution!

In 2001 some top software developers got together and proposed a new approach calledAgile. The philosophy is described in the Agile Manifesto and is an approach that welcomes change and feedback throughout the entire development process, rather than resisting it and enforcing a strict specification. The Agile approach basically involves working in a series of iterations, which are lots of tiny waterfall projects running one after another.

The first iteration delivers a rough prototype, feedback is collected and changes are incorporated into the next iteration. The process repeats to deliver better and better iterations until the project stops when the budget is exhausted. At Yoomee we try to deliver a new iteration each week.

The Agile Mona Lisa

An Agile, iterative process allows you to move from a vague idea to concrete realisations. You can also iterate to find the ideal solution for users, and iterate to improve it, once you’ve found it. Oh, what a dream come true!

One of the best ways of visualising this contrasting approach I've seen is an explanation by Jeff Patton illustrating what Agile development of the Mona Lisa would look like. You can see that three iterations, starting with a concept, which is firmed up into the final deliverable. Iterating builds a rough version, validates it, then slowly builds up quality:

Agile is not incremental

The old waterfall approach is akin to painting by numbers, as it calls for a fully formed idea at the start, which is delivered piece by piece without flexibility. This is called an incremental approach because the product is built piece by piece from a fully formed initial design. It's difficult to change the project's direction once the design's been determined at the beginning of the project. This approach doesn't welcome change, and isn't Agile in the slightest. You can visualise the approach like this:

Agile values

The Agile Manifesto summarises this philosophy by emphasising four core values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Agile principles

The values are manifested in twelve key principles, which we try to follow at Yoomee:

  1. Customer satisfaction by rapid delivery of useful software
  2. Welcome changing requirements, even late in development
  3. Working software is delivered frequently (weeks rather than months)
  4. Working software is the principal measure of progress
  5. Sustainable development, able to maintain a constant pace
  6. Close, daily cooperation between business people and developers
  7. Face-to-face conversation is the best form of communication (co-location)
  8. Projects are built around motivated individuals, who should be trusted
  9. Continuous attention to technical excellence and good design
  10. Simplicity—the art of maximizing the amount of work not done—is essential
  11. Self-organizing teams
  12. Regular adaptation to changing circumstances

These values aren't just something the creators of the Agile Manifesto intended to pay lip service to and then forget. They are working values. Each part of the Agile methodology approaches these values in a slightly different way, but all of these methodologies have specific processes and practices that foster one or more of these values.

You can do it too!

We've experienced such dramatic improvements in productivity and quality of deliverables since switching to Agile methodologies a few years back, we now insist all our clients use an Agile approach for new projects.

Mind, vInspired and Girlguiding are recent examples of large, non-profit organisations we’ve helped embrace Agile software development for complex software projects – and they've loved it so much they’ve adopted an Agile approach on other projects too.

"We hadn't used an Agile approach before. Yoomee introduced us to Agile for the development of Elefriends, made sure it held no surprises for us and also achieved what we needed and more." ~ Eve Critchley, Digital Community Manager, Mind.

If you'd like to know more about how we implement an Agile approach to projects and follow the principles and values outlined above, then please do post your questions below.

Posted on 13 October 2014 - By Andy Mayer
Share this post
blog comments powered by Disqus