One of the most important things we can do to help individuals and teams improve is coach them to embrace the agile mindset. The Manifesto for Agile Software Development provides values and principles to help guide teams in navigating the complexities of product delivery. It includes this statement: “While there is value in the items on the right, we value the items on the left more.”
This means we don’t just say “no” to the items on the right. That would be too black and white. However, we use these values help us navigate the many shades of grey in complex work. In this post, we will explore the 4 values and provide some examples of how they help teams embrace this mindset.
Individuals and Interactions over Processes and Tools
Processes and tools can be helpful, but they are not perfect. They cannot be designed to fit all of the complex scenarios. Furthermore, they often get in the way if they are followed blindly or without flexibility.
Here are a couple examples to illustrate how this value may show up in practice:
- An organization wants everyone to use the same process and request system for engaging the infrastructure team, so they can better manage their workload. All details are expected to be filled out in the ticket. However, a Scrum Team might reach out and ask to have someone from the infrastructure team available part-time to help design a larger, complex solution and build it incrementally, quickly adapting the design as they learn more each Sprint.
- A Scrum Team uses a specific tool to capture Product Backlog items. However, the understanding comes from the collaborative conversations they have during refinement and development.
There are a plethora of agile tools and techniques that have sprung up in the past decade or so. Some are helpful, but many are used in the context of the traditional model because organizations think they can “buy” standardization and best practices. But that undermines self-organizing, collaborative teams aspect of agile.
Through communication and collaboration, people will discover the best way forward. Do not allow processes and tools to hinder the collective intelligence.
Working Software over Comprehensive Documentation
Working software is the primary measure of progress. Documentation likely needs to be created in order to be releasable. This documentation could be part of the team’s process (e.g. keeping an architecture diagram up-to-date), the automated tests to maintain quality, or it could be something that is used by customers and have a specific value associated with it (e.g. product training video). In many circumstances, zero documentation would not be professional.
Here are a couple examples to illustrate how this value may show up in practice:
- A Scrum Team is told there are several “required” project compliance documents to be completed. Some of these documents don’t feel like they provide sufficient value and will end up delaying the delivery of working product. Instead of simply accepting the status quo and “checking the box,” this Scrum Team talks to be the PMO to better understand the purpose of documents. Together they discover the Scrum Team can meet the purpose in other ways that are more effective and more efficient.
- Instead of detailed technical documentation that is rarely referenced, hard to use, and difficult to maintain, a Developers may choose to capture technical documentation in different ways. For example, they may write their code as documentation with specific standards agreed to by the team. They may have a more concise and user-friendly version of technical documentation for support, maybe even photos of whiteboard drawings.
By placing emphasis on always delivering something of value and re-thinking which documentation is valuable and how to create documentation in a more effective way, we enable agility.
Customer Collaboration over Contract Negotiation
Contracts are important and necessary in business. The purpose of a contract is to establish the agreement that the parties have made and to fix their rights and duties in accordance with that agreement. Responsibilities of the parties are defined to the level of detail necessary to make both parties comfortable with the relationship. Be thoughtful about when contracts are necessary, how restrictive the contracts need to be, and when they may inhibit customer collaboration and business agility.
The term contract can be interpreted as a formal contract with an external party or an implied promise to an internal party. Requirements documents are often used as contracts when there is not trust with the people asking for the features and functions.
Customer collaboration is essential to ensure we build the right thing. People often find it difficult to describe exactly what they want. Often, people need to see something in order to get a better idea of what they do or don’t want.
Here are a couple examples to illustrate how this value may show up in practice:
- During a Sprint, the Developers shows the Product Owner how a feature is coming along. The Product Owner realizes what she originally asked for isn’t going to meet the business need. Even though there will be re-work required, the Developers collaborate with the Product Owner to slim the feature down so that it can better meet the business need while still being able to have a Done Increment by the end of the Sprint. The Product Owner adds a new PBI to the Product Backlog to capture the parts of the feature that will not be incorporated this Sprint. PBIs are not meant to be contracts.
- Instead of entering into a fixed scope, fixed budget, fixed schedule contract, a Scrum Team is open about the unpredictability and complexity in delivering the solution. Painful “change request” processes are often built into many fixed bid projects. Customers are forced to pay more to get the product they want, but there is a lot of overhead in trying to “manage change” this way. Instead, a Scrum Team tells a customer they can detail and even change the Product Backlog while the product is being built. The customer will get something usable every Sprint and be able to guide the product direction as they see and use a working product. Impacts to the cost and schedule will be transparent, and the customer will be able to prioritize and make informed decisions. This type of collaboration and transparency builds trust.
This agile value is ultimately about working with your customers and building trust rather than working against your customers with contracts.
Responding to Change over Following a Plan
In a rapidly changing and unpredictable world, we must be able to respond to change. Plans are important because they help us establish shared expectations from which we can then assess progress and identify what may have changed. Responding to change is simply updating the plan to reflect what we know now. Since the plan will change frequently as we inspect and adapt, we should make it easy to update the plan.
Here are a couple of examples to illustrate how this value can be used by a Scrum Team:
- A Scrum Team is building a new feature. They have released an early version of the feature with some of the key user benefits. However, the Product Owner is discovering from usage data that fewer people are using the feature than expected. Customer feedback indicates that people will not pay extra for this premium feature. The Product Owner re-orders the Product Backlog so that PBIs related to further enhancements to this feature are lower. The Scrum Team can focus on the next priority while the Product Owner does more research to determine how to improve the new feature.
- The Developers discover mid-way through a Sprint that it will be much harder to implement a feature due to integration complexities. They assess options and determine that the only way to deliver a Done Increment and meet the Sprint Goal is to greatly scale back the scope of the feature. After getting input from the Product Owner, the Developers completely re-create the Sprint Backlog. Several PBIs are removed. A new PBI is created to capture the minimal functionality that can be delivered to both validate the technical approach and get feedback on value from stakeholders at the Sprint Review.
Reflect on These Values Regularly
The Sprint Retrospective is a great time to reflect on how the agile values are showing up in the team’s daily work. You can also bring in the 12 underlying principles. This is an opportunity to clarify their meaning in terms of behaviors and outcomes.
Here are some questions to consider:
- What are examples of times we chose to value the item on the left and why? What are examples of times we chose to value the item on the right and why? Would we choose any differently next time?
- In what ways did the values/ principles show up during this past Sprint?
- Which value/ principle do we feel most challenged by? And what would make it easier?
- What are the obstacles we have to overcome to enact this value/ principle?
Want to take your learning deeper?
If you enjoyed this post, check out my book Mastering Professional Scrum. This book illuminates what it means to effectively apply empiricism, an agile mindset, and teamwork to truly unlock the benefits of agility.
Join me for an upcoming Professional Scrum training for 2 days of intense experiential learning, or schedule a private training for your organization.
