The last of our four key values from the Agile Manifesto: Responding to change over following a plan.
In the previous chapter, you saw the need to embrace change— even late in an Agile process. Think about it this way: learning something new is always beneficial, even if you need to change since it lets you know more about how to solve customer problems.
In this chapter, we will focus on ensuring that your team stays agile and embraces the change at all steps of the work process.
Adopt the Minimum Viable Product Mindset
Have you heard of the term minimum viable product or MVP? In an Agile process, it can help to start small with simple tests and prototypes, particularly when the team is developing new products or propositions, or exploring new territories or technologies.
In his book The Lean Startup, Eric Ries states that an MVP is the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
An MVP should only be as complex as it needs to be for the team to gain simple learning around how best to solve a customer problem. Unfortunately, some try to test too many things and build an expensive, complicated, or unnecessarily advanced prototype.
When the digital storage service Dropbox began, they produced a demo video showing the benefits of their idea. The video’s popularity told them that they were solving a real user need. The feedback helped them to build a better product.
While watching the video, try to answer this question: How does this MVP show the core idea behind Dropbox?
Take an example of a digital product or service from your business. What might an MVP of that have looked like? Write the response in the corresponding section of your log book.
Use Hypotheses to Learn From Failures and Successes
Learning is fun! The objective of starting small with an MVP is that a team can develop a new proposition iteratively to learn and adapt to achieve the outcome. The team uses prototypes and tests to find the best solution to customer needs. It develops a proposition using what Eric Ries (The Lean Startup) would call a “build, measure, learn” loop.
The team should start with a hypothesis in the build, measure, learn loop.
Like a scientific experiment, disproving a hypothesis is potentially as valuable as proving one. This means that teams can learn from successes and failures.
A good hypothesis is a proposed explanation for an observation, occurrence, or idea. In addition, research, data and analytics, customer observation, or customer feedback can inform a hypothesis.
Author and technologist, Barry O’Reilly, described this as hypothesis-driven development and has a good template for generating a hypothesis to test:
We believe <this capability>
Will result in <this outcome>
To verify that, we will <do the following>
We will have confidence to proceed when <we see a measurable signal>
This structured approach to testing enables a team to avoid biases in their decision-making and learn iteratively about best serving customer needs. An example of this might be something simple, such as:
“We believe that adding search functionality to our app will result in more customers finding the products that they are looking for. To verify that, we will test this feature on a group of people. We will have confidence to proceed when we see an uplift in conversions that are driven by search results in our test group.”
Tests and prototypes should be “safe to fail,” meaning that there is limited risk involved if the test fails while also maximizing learning from real customers.
Once the test is complete, the team takes their learnings and defines their next hypothesis. This method creates an iterative learning loop that enables the team to adapt.
Your Turn!
Airbnb famously began with a simple prototype created by the founders in San Francisco. In 2007, a design conference came to town, and all the hotel rooms were booked. So the two founders created a simple website with a listing offering “AirBed&Breakfast,” or accommodations in their apartment on air mattresses for $80. The test worked, and the rest is history.
How would you break down this MVP to describe the founders’ hypothesis, the test they ran on it, and the criteria they used for success and failure?
Fill in your answers here:
We believe <this capability>
Will result in <this outcome>
To verify that, we will <do the following>
We will have confidence to proceed when <we see a measurable signal>
✅ Solution: You can see my version of the MVP here.
Learn From Review and Retrospective
What are the practical ways for an agile team to ensure they are continuously learning, reprioritizing, and improving?
1. In the previous chapter, you saw the importance of showing working outputs to stakeholders to benefit from their feedback and inputs through the Agile process. Consider this feedback on the team’s outputs when prioritizing the next backlog tasks.
2. It’s also vital to balance stakeholder and customer feedback. When the team is prioritizing backlog tasks, it’s good to ask, “What now has maximum customer and business value?” The team should do that next. If there is any doubt about what to prioritize, you should focus on customer needs since satisfied and well-served customers generally create business value.
3. A third element of continuous learning in agile is how the team works. In Agile processes, it’s a good idea to run regular retrospective meetings (i.e., at the end of a sprint) to assess how the team performed, how you worked with other teams, and what you can improve.
For example, a team might use a virtual whiteboard with a “liked, longed for, lacked, learned” template. In the retrospective session, a facilitator can ask the team to allow individuals to input virtual sticky notes onto the template with feedback about what they liked about the last Sprint, what was missing, and what they learned. Then, you can use the feedback and key themes as the basis to discuss what the team wants to do differently.
Why not take one of the example frameworks above and run a practice retrospective with your team?
Sustain an Agile Environment on Your Team
It can be challenging to make agile ways of working stick if other business areas are not and pressure you to return to the old ways. In addition, non-agile teams often work at different rhythms or cadences than agile teams, resulting in dependencies that can slow agile teams down.
It’s best to counter this by establishing workarounds or more flexible working relationships with others to allow an agile team to get the required inputs quickly. Agile coaching can also help a team stay focused on applying agile principles to create lasting change.
Here are some other tips:
Encourage important contacts from other teams to attend your team ceremonies or meetings to understand how you work.
Establish point people to act as points of contact and collaboration in key teams your team works with. They can act as champions on your behalf.
Be transparent about what the team is working on, the team goals, and how other teams can help.
Look for shared priorities and common ground that can help create a sense of collaboration and mutual benefit.
Let’s Recap!
MVP approaches can help a team minimize investment and effort while maximizing learning. Remember to start small, avoid testing too many things too early, and define a test to give you the understanding.
Use hypotheses through the process to ensure you can develop tests that will inform your decision-making. Remember to focus on your belief, the outcome you expect from the test, and the metric for success or failure.
Use the “build, measure, learn” loop to iterate and build on your learning as you go. Don’t forget the importance of embracing change even late in the development process.
Use retrospective and review sessions as an opportunity to gather feedback to help you continuously improve. Focus on customer feedback, stakeholder feedback, and how the team is working together.
Go Further
Now that I've got a good idea of agile mindset and Agile processes, where do I go from here? And how do I encourage other teams to adopt the agile working methods?
Here are some top tips:
Start with one initial project you’d like to run in an agile way.
Set the team up for success by ensuring there is good buy-in from senior stakeholders for agile ways of working and good knowledge of the key principles and behaviors on the part of the team.
Make sure you define a good mission or outcome for the team and that everyone understands their roles and responsibilities.
Get support from an Agile coach to help the team transition to new ways of working. If that’s not possible, have an Agile champion on the team who can play this role.
Follow the key principles outlined in this course, but find the best way to apply them to your team and business. In other words, be agile about how you do Agile!
And lastly, remember agile is about celebrating quick wins (and failures), so it can be exhilarating and motivating to bring teams into the idea.
But before you go on, I invite you to do one more quiz to test your knowledge. Good luck!
