The Agile Manifesto celebrates its 21st birthday this month. Agile is an umbrella term encompassing a variety of frameworks and approaches to value delivery in complex environments. The word agile came into widespread use following the creation of the Agile Manifesto in 2001. That year, a group of 17 software practitioners looking for a better way to deliver software settled on the the term agile to refer to their more rational, human approach to complex work. Agile, in this context, is now a widely used term, which is commonly used to refer to Agile frameworks in general — including Scrum.
The Scrum framework comes with its own guardrails and values, but it is worth taking a moment to consider the base upon which Scrum is founded by examining the principles and values of the Agile Manifesto. The Agile Manifesto includes four values and 12 principles that describe a better way to approach complex work. Below, we will discuss each of the 12 principles and what they mean in the real world.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The image below is a famous example from Henrik Knilberg demonstrating an agile approach to product delivery and comparing it with more traditional methods.
The first principle included in the Agile Manifesto starts with “Our highest goal is to satisfy the customer….” This statement reflects what we all learned after running our first lemonade stand: to stay in business, we need to keep the customer happy. But it doesn’t stop there. The agile principles take this a step further and assert that the way to keep the customer happy is “through early and continuous delivery of valuable software.” In other words, the best way to keep the customer happy is to deliver valuable products to the customer frequently. After all, the only thing better than a great product is a great product that gets better often.
Unlike waterfall or other traditional project management approaches, agilists deliver early and continuously. We are not producing software once in one large delivery. Instead, we're delivering it frequently—or iteratively. Further, our customers must find what we deliver usable and valuable. It's an incremental approach. Rather than envisioning the end state of a product and working on that step-by-step, agile teams continuously ask themselves, what is the most valuable thing to do next?
The illustration above shows how this might look. The waterfall team envisions only the final product and delivers it in silos by working on systems that will be part of the final delivery, such as the tires, the frame and finally, the car. The agilists below them focus on the goal, which is transportation. In their first delivery, they manage to deliver a skateboard. In their second delivery, a skateboard with handles. Next, they produce a bicycle, then a motorcycle, and, finally, a car. Each delivery is usable, and each builds upon the previous work. These two scenarios show the difference between thinking only about the end state versus delivering value incrementally.
But isn’t that wasteful? Surprisingly, in the real world, incremental delivery is not wasteful. In fact, it eliminates waste because stakeholders and customers provide frequent feedback about whether what the team delivered was useful or whether the team should change direction. This regular feedback loop means that teams are less likely to spend a lot of time on features that are not useful to the customer.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
The Agile Manifesto’s second principle speaks to a different approach to requirements. Traditional methods aim to reduce the amount of change while product development is in flight. Agile does just the opposite. Instead of focusing on reducing variation and changes to the original requirements, Agile frameworks welcome change. Delivering value in smaller, usable increments makes this possible. Agile teams learn something from the customer after each delivery, and because it's a smaller increment of work, it's possible to introduce new requirements.
Why do Agile teams welcome change? Teams use an agile framework in complex environments, where more is unknown than known. In that context, does it make sense for the team to plan everything at the start, when they know less, or does it make sense to replan regularly as they learn more?
The benefit of welcoming change means that agile teams are able to respond to changing circumstances as more information becomes known over time.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
All agile frameworks rely upon the principle of delivering working software frequently, but this principle takes it a step further. Teams must deliver working software; not just a cog in the machine, so to speak.
Consider the image below. The left-hand side of the image represents the traditional way of delivering value to the customer, which is a large deliverable provided after everything envisioned in the final product is complete. Contrast this with the right-hand side of the image, which shows an iterative (frequent), incremental (Done) approach for delivering value. Each piece of what is delivered is usable, but it’s a smaller piece of the bigger puzzle.
In Scrum, teams determine the frequency of value delivery by the length of the Sprint. The purpose of each Sprint is to deliver a Done, usable increment of work at least once per Sprint. The Product Owner then determines when to release the functionality to the customer. The Sprint length should be just long enough to allow the Developers to deliver a usable increment of product, and no longer, with a preference towards the shorter timescale.
4. Business people and developers must work together daily throughout the project.
To me, this principle generates the most noticeable changes in the day-to-day experience of an agile team compared to a waterfall or traditional team. Using a traditional approach, the delivery team often goes through a long, intense requirements phase where they frequently meet with the business stakeholders. After they complete the requirements phase, the delivery team disappears to build whatever they understand the stakeholders specified.
Agile is different. Business stakeholders meet regularly with the agile team at a lower level of engagement. In Scrum, this engagement may take place in refinement meetings or at the Sprint Review. In other agile frameworks, this engagement may take the form of replenishment meetings. Regardless, engagement, and therefore visibility, is continuous in an agile environment.
In the image above dashed lines represent a waterfall or traditional approach. The blue lines represent Scrum, which is the most popular agile framework. By engaging with stakeholders more frequently, agile teams provide greater visibility into product delivery. Whereas traditional teams rely upon infrequent progress or status reports to provide visibility, Scrum teams rely upon frequent inspection of Done, usable work at the Sprint Review.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Leaders who work with agile teams focus on ensuring that the teams have the support (tools, access, resources) and environment (culture, people, external processes) they need, and then trust them to get the job done. This principle can scare some leaders who have a more command-and-control management style. They wonder how they'll know if their team is succeeding and focusing on the right things. My response to these concerns is to focus on the team’s outcomes. Are they delivering working product frequently? Are they making progress towards their goals? Those are the metrics that warrant attention. It is a necessary shift in perspective and mindset, and it is one that leaders as well as agile teams need to make to achieve the best results. To learn more about how to support agile teams, leaders should consider attending the Professional Agile Leadership - Essential class.
Successful agile leaders enable teams to deliver value by providing them with the tools that they need to be successful, providing guidance when needed, embracing servant leadership and focusing on outcomes.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
With the greater adoption of Zoom and other meeting platforms, the words face-to-face have taken on a slightly different meaning lately, but the idea behind this principle remains. The best way to convey information is to have a real-time conversation rather than a back-and-forth via email or messaging app. For agile teams, this may mean that those who deliver the work speak directly to those using the work. Or it could mean that those who deliver the work collaborate amongst themselves to solve their problems. Each agile team determines how best to live this principle according to their unique situation. What matters is that collaboration is critical for all Agile teams.
The best way to collaborate is to have a conversation.
7. Working software is the primary measure of progress.
This is the third time that the word software has shown up in one of the principles of the Agile Manifesto. The use of the word reflects the fact that agile “grew up” in software development, meaning that many of those who originally participated in the creation of the Agile Manifesto were in the software field. Today, agile frameworks are used in venues as diverse as human resources, marketing and defense.
The seventh principle speaks to the importance of delivering working software (or product). Success isn’t about the percentage of the work we have completed or how well we are sticking to a plan. In agile, we measure success by the product that we have delivered, and whether it is in a usable state. This means that progress reports, while they have their place, are not an end in themselves. Working product is ultimately what matters.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Have you ever been a part of a traditional team with a critical delivery scheduled far in the future? At first, the team approaches the work casually. Then, as the delivery date approaches, managers ask team members to work progressively longer hours to make the deadline. Along the way, business stakeholders inevitably change their minds about some of the requirements, which are difficult to work into the product at this late stage. Testing start dates get squeezed, and testers have to test more and more as time begins to run out. It’s exhausting and demoralizing.
Now, consider an agile team. The team tests the work as it goes and has a series of concrete steps to take. They have an unwavering focus on the end goal. Because they are delivering value incrementally, each piece is usable and is a step in the direction of the goal because they get constant stakeholder feedback about its value. This way of approaching work means that the team establishes a steady pace. It’s a much more even paced, satisfying experience.
Climbing a flight of stairs in one leap is about as difficult as delivering one giant product release. Delivery in smaller releases is a much more sustainable approach.
9. Continuous attention to technical excellence and good design enhances agility.
Agile teams should focus not only on feature development but also on ensuring that they deliver high-quality products. This might include addressing any existing technical debt and preventing its accumulation. Agile teams using the Scrum framework might work with the Product Owner to include items that increase product quality in the Product Backlog. Teams can also create a Definition of Done that prevents the accidental accumulation of technical debt by implementing best practices such as regular code reviews and security standards.
Why does this matter? The accumulation of technical debt can erode product quality and make frequent, incremental delivery impossible, therefore impacting agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
Because Agile teams focus on smaller, more frequent deliveries, the attitude of the business stakeholders towards the work often changes. Instead of asking for every requirement they may need in the future, the agile team can instead focus on the most valuable thing to do next. This kind of focus can significantly reduce waste, as the agile teams build trust with their customers and stakeholders through frequent delivery of working software.
Focus on the next most valuable thing to do next increases business stakeholder trust through the frequent delivery of working software.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
The architecture for the product, which is the underlying structure and approach to delivering the product, emerges along with feature delivery. Adhering to this principle means that the team doesn’t disappear for six months while they figure out the best long-term architecture. Instead, team members decide how best to build the product while they build the product.
The idea of self-organization is that the people closest to the work are best and figuring out how to do it.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I contend that adhering to this principle has the biggest impact on the happiness and efficiency of an agile team over the long term. On a regular basis, the team aks themselves, how it’s going and what changes should they should make. Then they make those changes and repeat the process regularly. A series of small improvements made over time is better than any single reorganization or process improvement project.
Teams that embody this principle continuously improve the way they work together and the product they deliver. Such teams have higher morale and greater productivity—and isn’t that what it’s all about?
Conclusion
Revisiting the manifesto regularly is a useful exercise for teams as an additional layer of accountability. If you’re wondering how your team can better live these agile principles, discuss it at your team’s next Sprint Retrospective. One way to do this is to place the 12 agile principles on a shared whiteboard. Then, ask the Scrum Team members to brainstorm how to better embody these principles in their work and interactions with the parent organization or business stakeholders. Next, vote on one or two actionable improvements, and implement them as soon as possible.
About Mary Iqbal
Mary has trained more than 1,000 people in Agile, Scrum and Kanban. She has guided the Agile transformation for organizations with more than 60 teams and has led the creation of new products from product definition through self-organization and launch. Mary is the founder of Rebel Scrum, a consulting company that helps teams transform to Agile and provides training and coaching services founded upon practical experience. Rebel Scrum has experience in large-scale agile transformations in a variety of environments including technology and business transformations. Signup for one of Rebel Scrum's upcoming public scrum training classes or contact us to discuss private Scrum training and consulting options for your organization.
What to learn more about Scrum?
Signup for one of Rebel Scrum’s upcoming classes:
- Applying Professional Scrum
- Introductory class for those new to Scrum
- Professional Scrum Master
- Geared towards Scrum Masters coaching teams
- Professional Scrum Master II
- Advanced class for Scrum Masters
- Professional Agile Leadership
- For leaders and managers of Agile teams
- Professional Scrum Product Owner
- For Product Owners
- Professional Scrum Product Owner - Advanced
- Advanced class for Product Owners
- Professional Scrum with Kanban
- For anyone interested in learning about implementing Kanban principles within a Scrum Team
- Scaled Professional Scrum with Nexus
- For three or more teams working together on a single product
Both public and private classes are available. To learn more, contact Rebel Scrum.
