Examining the Agile Manifesto
|
|
Examining the Agile Manifesto |
|
 |
To address the challenges faced by software developers an initial group of 17 methodologists formed the Agile Software Development Alliance (www.agilealliance.com), often referred to simply as the Agile Alliance, in February of 2001. An interesting thing about this group is that they all came from different backgrounds, yet were able to come to an agreement on issues that methodologists typically don’t agree upon. This group of people defined a manifesto for encouraging better ways of developing software, and then based on that manifesto formulated a collection of principles which defines the criteria for agile software development processes. The manifesto defines four values and twelve principles which form the foundation of the agile movement. |
|
The important thing to understand about the four value statements is that while you should value the concepts on the right hand side you should value the things on the left hand side (presented in red) even more.A good way to think about the manifesto is that it defines preferences, not alternatives, encouraging a focus on certain areas but not eliminating others. The values of the Agile Manifesto are:
Individuals and interactions over processes and tools. Teams of people build software systems, and to do that they need to work together effectively – including but not limited to programmers, testers, project managers, modelers, and your customers. Who do you think would develop a better system: five software developers and with their own tools working together in a single room or five low-skilled “hamburger flippers” with a well-defined process, the most sophisticated tools available, and the best offices money could buy? If the project was reasonably complex my money would be on the software developers, wouldn’t yours? The point is that the most important factors that you need to consider are the people and how they work together because if you don’t get that right the best tools and processes won’t be of any use. Tools and processes are important, don’t get me wrong, it’s just that they’re not as important as working together effectively. Remember the old adage, a fool with a tool is still a fool. As Fred Brooks points out in The Mythical Man Month, this can be difficult for management to accept because they often want to believe that people and time, or men and months, are interchangeable.
Working software over comprehensive documentation. When you ask a user whether they would want a fifty page document describing what you intend to build or the actual software itself, what do you think they’ll pick? My guess is that 99 times out of 100 they’ll choose working software. If that is the case, doesn’t it make more sense to work in such a manner that you produce software quickly and often, giving your users what they prefer? Furthermore, I suspect that users will have a significantly easier time understanding any software that you produce than complex technical diagrams describing its internal workings or describing an abstraction of its usage, don’t you? Documentation has its place, written properly it is a valuable guide for people’s understanding of how and why a system is built and how to work with the system. However, never forget that the primary goal of software development is to create software, not documents – otherwise it would be called documentation development wouldn’t it?
Customer collaboration over contract negotiation. Only your customer can tell you what they want. Yes, they likely do not have the skills to exactly specify the system. Yes, they likely won’t get it right the first. Yes, they’ll likely change their minds. Working together with your customers is hard, but that’s the reality of the job. Having a contract with your customers is important, having an understanding of everyone’s rights and responsibilities may form the foundation of that contract, but a contract isn’t a substitute for communication. Successful developers work closely with their customers, they invest the effort to discover what their customers need, and they educate their customers along the way.
Responding to change over following a plan. People change their priorities for a variety of reasons. As work progresses on your system your project stakeholder’s understanding of the problem domain and of what you are building changes. The business environment changes. Technology changes over time, although not always for the better. Change is a reality of software development, a reality that your software process must reflect. There is nothing wrong with having a project plan, in fact I would be worried about any project that didn’t have one. However, a project plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant.
The interesting thing about these value statements is there are something that almost everyone will instantly agree to, yet will rarely adhere to in practice. Senior management will always claim that its employees are the most important aspect of your organization, yet insist they follow ISO-9000 compliant processes and treat their staff as replaceable assets. Even worse, management often refuses to provide sufficient resources to comply to the processes that they insist project teams follow.Everyone will readily agree that the creation of software is the fundamental goal of software development, yet insist on spending months producing documentation describing what the software is and how it is going to be built instead of simply rolling up their sleeves and building it. You get the idea – people say one thing and do another. This has to stop now. Agile developers do what they say and say what they do.
|
To help people to gain a better understanding of what agile software development is all about, the members of the Agile Alliance refined the philosophies captured in their manifesto into a collection of twelve principles. These principles are:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. For some reason many people within IT have seem to have forgotten that the goal of software development should be the development of software. Or, perhaps the problem is that they think that they need to define everything up front before they can start building software, whereas an evolutionary approach to development seems to work much better.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Like it or not, requirements will change throughout a software development project. Traditional software developers will often adopt change management processes which are designed to prevent/reduce scope creep, but when you think about it these are really change prevention processes, not change management processes. Agilists embrace change and instead follow an agile change management approach which treats requirements as a prioritized stack which is allowed to vary over time.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. Frequent delivery of working software provides stakeholders with concrete feedback, making the current status of your project transparent while at the same time providing an opportunity for stakeholders to provide improved direction for the development team.
Business people and developers must work together daily throughout the project. Your project is in serious trouble if you don't have regular access to your project stakeholders. Agile developers adopt practices such as on-site customer and active stakeholder participation, and adopt inclusive tools and techniques which enable stakeholders to be actively involved with software development.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Too many organizations have a vision that they can hire hordes of relatively unskilled people, provide them with a CMMI/ISO/...-compliant process description, and that they will successfully develop software. This doesn't seem to work all that well in practice. Agile teams, on the other hand, realize that you need build teams from people who are willing to work together collaboratively and learn from each other. They have the humility to respect one another and realize that people are a primary success factor in software development.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. For a software development team to succeed its members must communicate and collaborate effectively. There are many ways which people can communicate together, and as you can see face-to-face communication at a shared drawing environment (such as paper or a whiteboard) is the most effective way to do so.
Working software is the primary measure of progress. The primary measure of software development should be the delivery of working software which meets the changing needs of its stakeholders, not some form of "earned value" measure based on the delivery of documentation of the holding of meetings.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Just like you can't sprint for an entire marathon, you can't successfully develop software by forcing people to work overtime for months at a time. My experience is that you can only do high-quality, intellectual work for 5-6 hours a day before burning yourself out. Yes, the rest of the day can be filled up with email, meetings, water cooler discussions, and so on, but people's ability to do "real work" is limited. Yes, you might be able to do high-quality work for 12 hours a day, and do so for a few days straight, but after awhile you become exhausted and all you accomplish is 12 hours of mediocre work a day.
Continuous attention to technical excellence and good design enhances agility. It's much easier to understand, maintain, and evolve high-quality source code than it is to work with low-quality code. Therefore, agilists know that they need to start with good code, to keep it good via refactoring, and take a test-driven approach so that they know at all times that their software works. We also adopt and follow development guidelines, in particular coding guidelines and sometimes even modeling guidelines.
Simplicity – the art of maximizing the amount of work not done – is essential. Agile developers focus on high value activities, we strive to maximize our stakeholder's return on investment in IT, and we either cut out or automate the drudge work.
The best architectures, requirements, and designs emerge from self-organizing teams. This is one of the most radical principles of the agile movement, one which I would love to see researched thoroughly by the academic community. The Agile Model Driven Development (AMDD) and test-driven design (TDD) methods are the primary approaches within the agile community for ensure the emergence of effective architectures, requirements, and designs.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Software process improvement (SPI) is a continual effort, and techniques such as retrospectives should be adopted to enable you to improve your approach to software development.
Stop for a moment and think about these principles. Is this the way that your software projects actually work? Is this the way that you think projects should work? Re-read the principles once again. Are they radical and impossible goals as some people would claim, are they meaningless motherhood and apple pie statements, or are they simply common sense? My belief is that these principles form a foundation of common sense upon which you can base successful software development efforts.
The Agile Manifesto provides a philosophical foundation for effective software development. Contrary to some of the criticisms you may have heard from the traditional community, the fact is that the agile movement is based on some very solid concepts and the methodologies clearly reflect that. Unfortunately the agile community currently suffers from low-end hackers claiming to be agile (e.g. the "we don't document therefore we're agile" crowd) and many traditionalists jump on that and say that agile is a bad idea. Yes, the "code-and-fix" approach to development is a bad idea, but code-and-fix isn't agile regardless of what these clowns claim. You might find my article The Criteria for Determining Whether a Team is Agile of interest because it describes how to determine if a team is truly agile or not and my The Threat of The New article which examines agile myths and misconceptions.
I'd like to thank Stan James, Lasse Koskela, and Ilja Preuss for their feedback regarding this article.
| This book, Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise describes the Disciplined Agile Delivery (DAD) process decision framework. The DAD framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and provides the foundation for scaling agile. This book is particularly important for anyone who wants to understand how agile works from end-to-end within an enterprise setting. Data professionals will find it interesting because it shows how agile modeling and agile database techniques fit into the overall solution delivery process. Enterprise professionals will find it interesting beause it explicitly promotes the idea that disciplined agile teams should be enterprise aware and therefore work closely with enterprise teams. Existing agile developers will find it interesting because it shows how to extend Scrum-based and Kanban-based strategies to provide a coherent, end-to-end streamlined delivery process. |
We actively work with clients around the world to improve their information technology (IT) practices, typically in the role of mentor/coach, team lead, or trainer. A full description of what we do, and how to contact us, can be found at Scott W. Ambler + Associates.
|
Copyright 2006-2014 Scott W. Ambler |
This site owned by Ambysoft Inc. |