This article looks to discuss the Four Values of the Agile Manifesto. Starting with the history of the Agile Manifesto before a more in depth discussion on each of the four values of the Agile Manifest.
The Agile Fundamentals
A 59 Seconds Agile Video Animation
Four Values of the Agile Manifesto for Scrum Masters
A 59 Seconds Agile Article
Agile is a quick, simple, lightweight and effective way of managing projects. In traditional project management models, everything is sequential and strictly planned, but in the Agile framework, the unpredictable nature of product development is taken into consideration by welcoming changes. Instead of a one-time delivery of a full-featured product, the Agile approach focuses on breaking the product development into iterative deliverable pieces of functionalists.
Four Values of the Agile Manifesto: The History
In 2001, a group of software practitioners proposed the Agile manifesto for pursuing better ways of developing software. This new method is based on four key values and twelve principles. The Agile Manifesto values “Individuals and interactions over processes and tools”, “Working software over comprehensive documentation”, “Customer collaboration over contract negotiation” and “Responding to change over following a plan”. There are different frameworks to practice the Agile concepts and the Agile manifesto in a real working environment. One of these frameworks is Scrum. Scrum is a lightweight framework for developing complex products.
Four Values of the Agile Manifesto
We look at each value of Agile Manifesto in more details in the eyes of the Scrum framework.
1. Individuals and interactions over processes and tools
Scrum is a team-based approach with the aim of delivering value to the business. Scrum focuses on cross-functionality and autonomy of the development team. Though tools and processes are also important, without having a team working and interacting effectively, it would be much more difficult to achieve a successful final product. Apart from team member collaboration, scrum encourages interaction with customers and stakeholders to get their feedback on the developed product. To provide the opportunity for team interaction, Scrum provides different time-boxed events such as daily stand-up meetings, sprint planning meetings, and retrospective meetings.
Four Values of the Agile Manifesto Two to Four
2. Working software over comprehensive documentation
The Agile frameworks are based on releasing early and often. Scrum requires a working, finished increment of the product at the end of every sprint. The primary goal of software development is to produce working software, detailed documentation should come behind this. On the other side, documentation has its own importance and benefits and it should not be forgotten or neglected. Detailed documentation helps people understand the ‘How’s and whys’ of the system and how to work with it.
3. Customer collaboration over contract negotiation
Having a contract is important. It provides a foundation for collaboration on product development and identifies the rights and responsibilities of the engaged parties. But it cannot replace the communication between the customers and scrum teams. From one side, team members collaborate with each other to find the best way to build and deliver the software. On the other side, product owner collaborates with stakeholders to inspect and adapt the product.
4. Responding to change over following a plan
It is always good to have a vision and an overall plan for the future of the product. This plan should reflect the changes that may happen during the product development and should be flexible enough to respond to changes. Change is an unavoidable part of software development process. The changes may originate from the change in technological tools. They also may be required by customers or may be a result of a change in the business priorities.
Prev <— Continue Reading —> Next
User Stories Applied
A 59 Seconds Agile Book Review
User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.