What is it all about?
The Agile manifesto is used by many and it has a lot of really good points, but what do we actually mean by each of them? Lets talk about what they are and what they are not.
Agile and Adaptive
When the bright minds of software analysis and development came together in Wasatch Mountain, Utah some ten years ago, they ended up with the Agile Manifesto and Principles. They actually wanted to use the term Adaptive instead of Agile, but since James Highsmith at that point had already published a book called “Adaptive Software Development”, the settled for Agile.
According to Oxford Advanced Dictionary, Agile means:
”Able to move quickly and easily” and ”Able to think quickly and in an intelligent way”
According to the same dictionary, Adaptive means:
”Concerned with changing” and ”Able to change when necessary in order to deal with different situations”
It is clear to see that Adaptive had been a better choice than Agile, so every time you hear Agile, think Adaptive. I do.
The Agile Manifesto
The Agile Manifesto is a set of truisms when it comes to software development:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
I have put a few parts of the manifesto in bold, because to me that is where the important parts are hidden.
Uncovering: We do not know everything and we are still on a path to find better ways.
By doing it: We are getting better at developing software not by reading about it but by actually developing software.
Helping others: To improve quality and to get better it is important that we share our experiences.
It is also important that the manifesto says over and not instead of so going Agile is not an excuse for e.g. no documentation, not to look at requirements and having no plans.
What the Agile Manifesto is trying to remind us is that we are in cooperation with the business, and that cooperation is what makes the good software even better.
The Agile Principles
While the Agile Manifesto is the part that always gets most attention, there are also twelve Agile Principles that also deserves their time in the spotlight.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This means we should deliver features to satisfy business needs, not to deliver code. This doesn’t mean spend more time satisfying your Product owner than coding.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
This means don’t be a slave to the requirements. This doesn’t mean that requirements should be ignored.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This means you should ensure that the features in an iteration actually fit within the defined work units. This doesn’t mean to work around the clock every three weeks to meet an obscure deadline.
Business people and developers must work together daily throughout the project.
This means exactly what it says. If you aren’t doing this already, you are heading for trouble!
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This means get good machines and software, keep them up to date and stop complaining. This doesn’t mean force your team to use tools just because it is company practice.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This means have stand-ups and feature design meetings. This doens’t mean the team should have to cram in the same room.
Working software is the primary measure of progress.
This means shipping is a feature. This doesn’t mean you can skip documentation, status reports or integration tests.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
This means work 40 hour weeks, or less. This doesn’t mean you have to sell your life to the project and burn out within 3-6 months.
Continuous attention to technical excellence and good design enhances agility.
This means you need to keep yourself updated on what is going on in the IT community to keep your skills honed. This doesn’t mean you need to change languages/IDEs every 2 weeks to be a good developer and to prove that you are on the cutting edge of technology.
Simplicity—the art of maximizing the amount of work not done—is essential.
This means write less code, write less specification, focus on producing what is needed. This doesn’t mean import every framework you have ever heard of into your project.
The best architectures, requirements, and designs emerge from self-organizing teams.
This means there shouldn’t be more managers than developers. This doens’t mean there should be no management at all.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This means your team should hold retrospectives and apply your findings the project. This doesn’t mean you should change frameworks, direction and scope every iteration.
Being Agile is a state of mind. Agile is not about the tools or methods you use but how you use them. Its about your mindset and your approach problem solving. You do not automatically become Agile if you use SCRUM. There is no such thing as an Agile tool. Also keep in mind that the Agile Manifesto and Principles are not written in stone. They are guidelines, really good guidelines based on practical experiences that has proven to work, and should be treated as such.