The Manifesto for Agile Software Development was created by a group of like-minded developers at a Utah ski lodge in February of 2001. Calling themselves the Agile Alliance, the manifesto these developers put together summarized the core tenets of the Agile Development methodology. The Agile Manifesto goes like this:
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 planThat is, while there is value in the items on
the right, we value the items on the left more.Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thom
Martin Fowler Brian Marick© 2001, the above authors
this declaration may be freely copied in any form,
but only in its entirety through this notice.
Individuals and interactions over processes and tools
While processes and tools are great, a lot of development outfits tend to overemphasize the processes and tools. Put your development into the hands of individuals and allow them to interact to get the software done. Ask your development team what they think of the project in question, how they should get it done, and how much they believe they will be able to get completed in bite-sized chunks (sprints). Then, allow them to use the processes and tools that they find most effective to completing the job.
Working software over comprehensive documentation
A lot of companies tend to over-document before even touching a line of code. The Agile Manifesto indicates that it’s better to create working prototypes of software rather than to over-document before hand. In this manner the needs of the user will come out over time – before the code base of a project has been developed to such an extent that it is too late to make changes to the infrastructure.
Customer collaboration over contract negotiation
Instead of having an us-versus-them process of negotiating the finer points of a wordy contract, a development effort should be a collaborative effort between the developing organization and the client. Agile favors the discovery of the “final needs” over time, by developing working prototypes of software programs, over demanding that the client has a complete 100% understanding of their needs before a line of code is written. The customer and the developers should work together to come up with the right software to meet the client’s needs.
Responding to change over following a plan
Microsoft Project is a great tool for creating huge, complicated waterfall project schedules. However, Project may not be the best tool to use in an Agile Development software project. Agile projects need to be able to adapt to change, and therefore should not be planned out to the letter months in advance in a waterfall-like schedule. With such schedules changes tend to be feared and protested; in Agile Development, changes should be expected, welcomed and understood.
Using the Agile Manifesto
The Agile Manifesto is more than snappy prose; it indicates a way of thinking when developing software. If you’re an Agile shop, regardless of your methodologies and how you adapt them to your needs, when subjecting your development team to a change in process or even your corporate culture you should ask yourself: Does this change line up with the Agile Manifesto? Are we adding too much documentation – or even too much process – to our practices?
Brian,
Thanks for writing this introduction to what Agile is all about!
I hear that the agile certification (“PMI-ACP”?) is becoming popular.
Cheers,
Alex
Hi Alex, thanks for the note. Believe it or not I had never heard of PMI’s Agile Certified Practitioner certification! It looks like PMI is trying to “get into the game” – this certainly shows that Agile methodologies are catching on. I wonder how well they will be able to compete with the Scrum Alliance’s Certified ScrumMaster (CSM) certification, which as far as I know is still the most popular of the Agile certifications.
Hi Brian,
As the product manager of Planbox, I have printed and posted the agile manifesto in front of everyone’s desk. I want to make sure that we go back to it regularly to make sure that our tool stays in line with the manifesto’s values. One of the things we’ve implemented that really helps to follow the points: ‘Customer collaboration over contract negotiation’ and ‘Responding to change over following a plan’, is a feedback widget. Through the widget, our customers can input feedback, suggestions, requests, questions and we can link all the input to our stories. Lots of our users also use this feedback widget to make prioritization easier and to stay close to their customers.
Magali
hello Magali, thanks for writing. I like the idea of creating widgets that take the principles of the Agile Manifesto to heart. The widget you describe seems to be a good way to promote collaboration between the client and your development teams. You mentioned that your feedback widget is also used to help with prioritization – do you get your product managers involved, and use the widget as a way for clients to prioritize items within the product backlog?
thanks again for your comments, and for dropping by the site! All the best to you and the folks at Planbox.
Solid walkthrough. It’s the foundation after all! 🙂
thanks for the kind feedback Agile Scout. I must admit it must have been interesting to be at that Utah ski lodge to witness “the foundation” that has had such a tremendous effect on software development practices through the years.
a lot of people confuse bad project management with stuff like Agile – the values in Agile are excellent and should be adopted by all businesses and projects, wherever possible – having a plan does not stop you behaving in an Agile manner – there’s a lot of misconception on that point
Hello Kevin,
Thanks for your feedback and your views on Agile Development!
I agree that Agile methodologies, including Scrum, are quite valuable – I have managed projects being developed by Scrum teams in the past, and I’ve found that Scrum is very effective, and scalable – with self-managed teams you can give your developers the room they need to get their work done, and understand the work you’ll be able to get done from your product backlog with the help of story points and team velocities. I definitely think that you can use Agile methodologies in accordance with a well-thought out plan, and in fact have a good understanding of how realistic it is to accomplish that plan based on your understanding of your teams’ capabilities.
Thanks again for your insight – I appreciate it! All the best to you.