The Manifesto for Agile Software Development is a really powerful piece of work and something I really relate to. Not only have some of the finest minds in the business been part of its creation, thousands of others have found that it relates to their own experiences and have been proud to sign up. I signed the manifesto myself back in March 2011, but recently it’s become more relevant than ever.

I’ve been part of a very successful business, the number of software developers has grown from a dozen to nearly 30 and we’ve subdivided into different teams working on different aspects of our product. You can read more about those changes in my series on progress; Part 1 – How things used to be and Part 2 – How things are now.  We’ve specialized and diversified from a company of developers to one with many different roles and departments. The challenge now is to try and maintain the aspects that work and made us successful whilst encouraging the new changes that will help us continue and become more successful.

Ask most people what a successful development team looks like and they’ll probably tell you that it is “agile”. But what does that mean? That they work in small blocks of time called sprints? They have fancy boards with kan-bans and burn down charts? They talk of user stories, planning poker and a product backlog? They practice pair programming, daily stand ups and retrospectives? Well all of those items could be considered agile practices, but for me it is simpler than that. You need to have an agile perspective, and the Agile Manifesto sums it up perfectly. Let’s look at each of the items in the manifesto in turn:

Individuals and interactions over processes and tools

Let me say that again, individuals and interactions over process and tools. Lots of those so called agile practices that I listed before are aimed at improving the interactions, but really they are just processes and tools. A really subtle difference perhaps, but one that means so much in practice.

Working software over comprehensive documentation

We deliver a high quality product that in general works very well. However, where we lack documentation we are heavily criticized and the documentation is seen as the cure for all issues. “If only we had that documented then we wouldn’t have this problem”. I doubt it. People just don’t read! (http://uxmyths.com/post/647473628/myth-people-read-on-the-web)

Customer collaboration over contract negotiation

One of the biggest reasons we became so successful was our ability to listen to our customers and offer them a solution to their particular need. We had no real need to check that our contracts were water tight (and many certainly weren’t) as they were rarely disputed. We now take contract negotiation very seriously.

Responding to change over following a plan

Being very flexible in our approach a plan was more of a conversation piece. Something to discuss, but rarely accurate as change was inevitable (and the right thing to do). Now a plan needs to be agreed and executed with change controlled and removed where possible.

The manifesto concludes that “while there is value in the items on the right, we value the items on the left more.”

If you placed the items in the manifesto on a large set of weighing scales, you would want the items on the left tipping the scales to the left. If you add more process and tools, more contracts, more planning, you need to also add more focus on individuals and interactions, customer collaboration, and more responding to change otherwise. It is all about getting the balance right.