In February 2001, following 17 software developers met at the Snowbird, Utah resort, to discuss lightweight development methods. Agile Manifesto-
| Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler | James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick | Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland |
They were representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others, sympathetic to the need for an alternative to documentation driven, heavyweight software development processes.
They published the Manifesto for Agile Software Development to define the approach now known as agile software development. Some of the agile manifesto’s authors formed the Agile Alliance, a non-profit organization that promotes software development according to the agile manifesto’s values and principles.
Agile values
The Agile Manifesto reads, as follows:
| 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. |
Let us understand the values
- Individuals and interactions over Processes and tools
The message here is that while processes and tools will be necessary on our projects, it is more important to focus on individuals and interactions involved. The projects are a result of effort by people. The problems get resolved by people. The ideas to solve problems come from people. Also the projects are defined by people, scope decided by people and finally accepted also by people. Focusing early on developing the individuals involved in the project and emphasizing productive and effective interactions help set up a project for success.
- Working software over Comprehensive documentation
The message here is that, software without any documentation is certainly problematic, but comprehensive documentation without software is also valueless. The message is to document but documentation should be such that it is barely essential for others to understand whats there in the software.
- Customer collaboration over Contract negotiation
The message here is that one must be flexible and accommodating rather than being uncooperative with the customer. We could build the product as originally specified but it may become worthless if customer recognizes that there needs to be a change to make it more effective. Rather than beat up the customer with a change management process that is really more of a change suppression process, we have to assume right at the start that things will change.
- Responding to change over Following a plan
Initial plan should always be a starting point and the plan should progressively elaborate as time goes. More energy should be spent on responding to the inevitable changes on the project. However, this does not mean that one must throw the plans out of the window and be ad-hoc. We still need to plan. Just that there should be an assumption that plan will change and one must respond to change positively.
Agile Principles
In addition to the four Agile Manifesto values, the authors of the Manifesto created twelve guiding principles for agile methodology. Following are the 12 principles
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily cooperation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work NOT done—is essential
- Self-organizing teams
- Regular adaptation to changing circumstances
- Customer satisfaction by rapid delivery of useful software
o We should focus on Customer. Satisfying only our own management or PMO should not be our only goal.
o We must structure the project and projects team to deliver early and then deliver frequently
o We must deliver valuable software and not just WBS items, documentation and plans/ The focus should be on end goal.
- Welcome changing requirements, even late in development
o Changes can be great for a project if they allow us to deliver some late high-priority features.
o From a traditional project management perspective, the changes are often seen negatively and finally only the high-priority changes go thru.
o Agile Manifesto projects accept that fact that changes will happen. XP methodology infact states clearly to “Embrace Change”. This principle states that instead of suppressing changes, the teams should embrace change and keep the project adaptive and flexible as long as possible.
- Working software is delivered frequently (weeks rather than months)
o This principle emphasizes the importance of releasing work to a test environment and get feedback at the earliest. Frequent testing and feedback are very important and helps incorporate stakeholder comments at the earliest.
o Delivering within a short timeframe also benefits the team by keeping the Business engaged and keeping a ongoing dialogue about project progress. This helps solve escalations and dis-satisfaction from the customer in the later stages of project.
- Working software is the principal measure of progress
o The effort of creating documentation and designs should be supporting work and should not be primary activity.
o The definition of progress and the binary nature of “working software” creates a resulted oriented view of the project. Interim deliverables and partially completed work gets no external (customer) recognition.
- Sustainable development, able to maintain a constant pace
o Instead of long, intense development periods, agile methods recognize the value of maintaining a sustainable pace that allows team members to have a work-life balance. Not only is a sustainable pace better for the team but it benefits the organization as well. Log workdays lead to dis-satisfaction which may result in loss of personnel, talent and knowledge.
o This principle advocates that working at a pace that can be maintained indefinitely creates a happier and more productive team.
o Some of the agile methods like XP recommends not more than 40 hours a week, however the key here is to sustain the pace for long term whatever work hours your team decides as a norm.
 Sustaining a pace on a AGILE SCRUM project for each Sprint vs a typical Waterfall project where pace picks up as the project progresses |
- Close, daily cooperation between business people and developers
o The frequent demos mentioned above are a good example of Business and developers working together throughout the lifecycle of the project.
o By working with business representatives daily, the development team learns about the business in a way that is far beyond what a collection of requirements gathering meetings can ever achieve.
- Face-to-face conversation is the best form of communication (co-location)
o Face to face communications allow us to quickly transfer a lot of information. Body language, gestures and emotions also play a important part in the face to face communication. Face to Face communication therefore is called “High Bandwidth” communication.
o In the distributed environments where the teams work at different locations, it is still recommended to have atleast the starting point as a kickoff face to face meeting so that the teams can know each other better and help in better communication.
- Projects are built around motivated individuals, who should be trusted
o While we may not always be in a position to pick our dream team, what we can do is try to motivate our team members. Since the team is such an important factor on the project, agile methods promote empowered teams. People work better when they are given the autonomy to organize and plan their own work.
o Agile methodology advocate freeing the team from micromanagement of completing of tasks, instead, the emphasis is on peer collaboration, team work which results in higher productivity.
o Traditional HR theories also suggest similar principles, where more than the salary or basic needs, what drives people is motivation to excel. e.g. Herzberg’s theory or Maslow’s theory suggest similar principles. McGregor’s theory X principle does not apply in the knowledge environment for many years even before Agile Manifesto was written.
- Continuous attention to technical excellence and good design
o While we want the development team to work hard and deliver a lot of value, we also have to be mindful of keeping the design clean, efficient and open to changes. Technical excellence and good design allows the product team to understand the product much better and maintain it much better.
o The project needs to balance the efforts of delivering high-value features with giving continuous attention to the design of the solutions. This balance allows a system to deliver long term value without becoming difficult to maintain, change or extend.
- Simplicity—the art of maximizing the amount of work NOT done—is essential
o The most reliable features are those that DO NOT BUILD. This statement seems weird, but if we look at 90% of the systems, the 50-60% of features built in never get used actually. DSDM goes to the extent of saying that 80% of the value is delivered by 20% of the features (pareto principle).
o However because of those 50-60% features, the system becomes complex and difficult to maintain.
o Agile methods seek the “Simplest things that could possibly work” and recommend that this solution be built first. This principle is not intended to preclude further extension and elaboration of a product – instead, it is simple saying, lets build the bare minimum first and then lets add the features as we go along.
- Self-organizing teams
o The best architectures, requirements and designs emerge from self-organizing teams.
o Essentially the principle says that to get the best out of people, we have to let them self-organize. People also like self organizing. It allows them to find an approach that works best for them.
o By allowing the people to take their own decisions, it puts accountability on them to own the decisions that they have taken thereby resulting in better commitment.
- Regular adaptation to changing circumstances
o Gathering lessons learned at the end of the project is too late for the current project. Instead agile projects employ frequent reviews called retrospectives to reflect on how things are working on the current project and identify opportunities for improvement.
o On an Agile Manifesto project, the lessons learned are captured from the team as the project progresses so on one can claim they do not apply. Instead the team knows they are relevant and is pushed to tune and adjust their behavior accordingly.
