Introduction
The Agile Manifesto and the Twelve Principles of Agile Software were direct results of the frustration that plagued the software industry in the 1990s. The huge time lag between business requirements and the delivery of technology that meet those needs led to the cancellation of many projects. Business demands and client needs changed during this delay, resulting in the final product not meeting current needs. The traditional development models, led by the Waterfall model during that time, were not meeting the demand for speed or how quickly software could be altered.
In 2000, a group of seventeen “thought leaders,” including Jon Kern, Kent Beck, Ward Cunningham, Arie van Bennekum, and Alistair Cockburn, first met at a resort in Oregon, and later, in 2001, at The Lodge at Snowbird Ski Resort in Utah. It was at the second meeting where the Agile Manifesto and the Twelve Principles were formally laid down.
The Manifesto reads:
“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.”
The Four Values of The Agile Manifesto
The Agile Manifesto consists of four core values. Each Agile methodology applies these four values in different ways, but they all rely on them to guide the development and delivery of high-quality, functional software.
1. Individuals and Interactions Over Processes and Tools
Valuing people over processes or tools is easy to understand because people are key to why a project was started in the first place, so their satisfaction is critical to the success of any project. If the process or tools drive development, the team is less responsive to change and less likely to meet client needs.
Communication is an example of the difference between valuing individuals versus a process. In the case of individuals, communication is fluid and place when needed. In the case of process, communication is scheduled and requires specific content.
2. Working Software Over Comprehensive Documentation
Agile does not eliminate documentation, but it simplifies it in a form that gives the developer what is needed to do the work without getting bogged down in details. Vast amounts of time were spent on documenting product development and delivery (i.e., technical specifications, technical requirements, interface design documents, test plans, documentation plans). This intense call for documentation has been the cause of massive development delays.
Agile documents requirements as user stories, which are sufficient for a software developer to start the task of building new functionality. The Agile Manifesto still values documentation, but it values working software more.
3. Customer Collaboration Over Contract Negotiation
Negotiation is the period during which the customer and the product manager are working on the delivery details, with points along the way where the details can be renegotiated.
Collaboration is a completely different creature. With development models such as Waterfall, clients negotiate product requirements before any work begins. This means that the customer did not participate during development, but only before the start of development and after it was completed.
With Agile, the client participates and collaborates throughout the entire development process. This makes it much easier for development to meet their needs of the client. Agile methods may include the client at intervals for periodic demonstrations. However, a project can also have an end user as a daily part of the team who attends all meetings to ensure the product meets the business needs.
4. Responding to Change Over Following a Plan
The traditional method of software development regards change as an expense and should be avoided at all costs. The intent was to develop elaborate and detailed plans. These plans would have a defined set of features, no set priority, and a large number of many dependencies to deliver in a specific order so that the team could work on the next piece of the puzzle.
With Agile, the short iterations allow priorities to be shifted from iteration to iteration and new features can be added to the next iteration. Agile sees changes as improving a project, providing additional value and enabling the customer to adapt at their own pace.
The Twelve Agile Manifesto Principles
Besides the four core values, there are 12 supporting principles. Included under the title “The Agile Movement”, these 12 principles guide the methodologies. They describe a culture in which change is welcomed, and the customer is the focus of the work. It also illustrates the intention of the Agile movement to bring development in line with business needs.
The twelve principles of Agile development include:
- Customer satisfaction through early and continuous software delivery
Customers are happier when they receive working software at regular intervals, rather than waiting for long periods of time between releases. - Accommodate changing requirements throughout the development process
Ability to avoid delays when changing a requirement or requesting a feature. - Frequent delivery of working software
Scrum accommodates this principle as the team works in software sprints or iterations that ensure regular delivery of functional software. - Collaboration between the business stakeholders and developers throughout the project
Better decisions are made when the business and technical team are aligned. - Support, trust, and motivate the people involved
Motivated teams are more likely to do better than unhappy teams. - Enable face-to-face interactions
Communication is most successful when development teams are in the same location. - Working software is the primary measure of progress
Delivering functional software to the client is the ultimate factor that measures progress. - Agile processes to support a consistent development pace
Teams create a repeatable and maintainable speed where they can deliver working software, and they iterate it with each release. - Attention to technical detail and design enhances agility
The right skills and good design ensure that the team can keep pace, continually improve the product, and sustain change. - Simplicity
Develop enough to get the job done right now. - Self-organizing teams encourage great architectures, requirements, and designs
Skilled and enthusiastic team members who have decision-making power, take charge, communicate regularly with other team members, and share ideas that deliver quality products. - Regular reflections on how to become more effective
Self-improvement, process improvement, and development of skills and techniques help team members work more efficiently.
Agile Development Pros
- Greater flexibility than waterfall
- Faster review cycles
- Immediate feedback
- Less defects in final product
Unlike Waterfall, Agile provides the ability to change scope after design and implementation. With scope able to change to meet evolving demands, cost and schedule become the only key factors of the project.
Agile has release cycles or smaller iterations, where the product is in a ready release state. The ready release state allows end users to review and provide instant feedback faster.
Since Agile requires that each iteration be in a ready release state, testing is run at the end of each cycle. This allows defects to be detected and corrected early.
Agile Development Cons
- Daily scrums take valuable time
- Scope creep
- Less documentation
Agile recommends daily scrum meetings to keep everyone in sync with everyone's progress. Pulling developers, quality assurance analysts, and technical writers out of their work to attend a meeting takes up their valuable time.
Because Agile provides instant feedback from end users, scope creep can overburden the sprint. End users who see that their requests are easily met usually request additional features without realizing the effort involved.
The code-test-build-release cycles do not leave time for documentation. It is therefore essential that development teams bring any changes to the attention of the documentation team. Of course, even having access to documentation team is a luxury most businesses can not afford. Without proper technical documentation, it is difficult to trace the design of the product for anyone new coming to the team.
Conclusion
Agile's success is demonstrated with the intent to align development with business needs. Agile projects focus on the customers and encourage customer guidance and participation. As a result, Agile has grown into an overarching view of software development throughout the software industry and has even become an industry all by itself.
What are you thoughts on how Agile has changed the way new development is undertaken? Please leave any feedback or questions you have in the comments below.
References