What is the Agile Manifesto?
The Agile Manifesto includes four values and twelve principles for software development. These are not a set of hard rules for how to use Agile, rather they are outline a philosophy that was intended to govern agile development – this is the nature of Agile. This is an agile approach while creating a mindset for the whole team to adopt during the development cycle.
History of the Agile Manifesto
The Agile Manifesto arose in 2001 with a paper that was published by seventeen software developers. The group of developers all met together for a long ski weekend in Utah, but also to solve the frustration of the document-driven, heavyweight software development process. Agile practices and principles were already in practice in the software world, however, they were only being applied haphazardly. This Agile Manifesto was solidified into what is now known as the customary approach to agile development.
The Four Values of Agile
The four overarching values in the Agile Manifesto are as follows:
- Individuals and Interactions over Processes and Tools
- Working Software over Comprehensive Documentation
- Customer Collaboration over Contract Negotiation
- Responding to Change over Following a Plan
The fundamental idea here is to focus on creating work, not getting caught up in the process about creating work. With this approach, it is more possible to pivot and re-prioritize as the need arises.
The twelve principles of Agile
The twelve principles outlined in this manifesto are guidelines to help inspire agile thinking.
1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
The best way to keep your customers happy is to ship early, iterate often and to listen to customer feedback. Instead of doing long drawn out development cycles, you’ll want to quickly deliver a minimal viable product (MVP), get feedback from customers, and then iterate.
2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”
Product Managers have a constant watch on market trends and feedback from customers, and this agile principle represents the flexibility to make necessary changes according to market trends even if it’s at a late stage of development…..it’s never too late to iterate!
3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
The Agile approach encourages shipping mini releases of your product often. By getting your product into the market early and often, you’re able to validate ideas as you work through the development cycle.
4. “Business people and developers must work together daily throughout the project.”
Consistent communication is what will keep the product team and the business teams connected. Daily sitdown or standup meetings are encouraged to keep the two teams connected.
5. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
Trust and individuality are the cornerstones of Agile development. Each team member should be provided the trust and autonomy to deliver the work they were hired for. Great ideas and work arise from freedom, micromanaging can destroy the teams’ momentum.
6. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
The goal of this principle is to keep communication face-to-face and off of email and slack. If developers are working remotely, video conference as often as possible. Keep communication as “in-person” as you can.
7. “Working software is the primary measure of progress.”
The objective of software development is to create a working product that customers love. Getting bogged down with documentation can lament this process, hence the creation of agile. Getting the product out into the world quickly, and iterating as needed based on feedback keeps the focus on the product and off of heavily weighted documentation.
8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
The objective of this principle is to prevent burnout. Good work-life balance should always be the goal. A team that’s burnt out is an inefficient team.
9. “Continuous attention to technical excellence and good design enhances agility.”
This principle is a reminder to keep things “neat and tidy”. Developers and Product Managers should be working together to prevent technical debt.
10. “Simplicity—the art of maximizing the amount of work not done—is essential.”
The goal here is to “work smart and not hard”. Create an atmosphere of laser-sharp focus so that the team can make the most impact with the least amount of effort. This strategy will help to avoid burnout.
11. “The best architectures, requirements, and designs emerge from self-organizing teams.”
Self-organizing teams are often comprised of self-starters. This principle intends to empower teams and individuals to assign themselves to tasks and to as groups as they see fit.
12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
The core of Agile development is all about being as flexible as possible, and changing whenever it’s necessary to develop the best product.
Conclusion
The Agile Manifesto is all about creating a mindset for your workflow that is absent of rigid rules. To truly work in an agile fashion you must be amiable to change, and open to new ideas. This is as much a burden for the individual as the group and achieving alignment and adoption throughout the org, particularly with a tradition of focusing on delivery dates can make this challenging. In fact, it is important to realize that Agile is merely a tool and as such, no one tool is perfect for every job. Whereas Agile is very adaptive for consumer product development, this approach may not be appropriate for fixed-cost/scope efforts. Large Internal enterprise with complex dependencies is another example of a time where Waterfall development may not be a bad thing. Agile has become a de facto standard in consumer-facing application development for a reason though and is highly recommended otherwise, absent these constraints.
