https://nkdagility.com/resources/xGuuZ5l6fCo copied to clipboard!

Product Development Product Management

tech·nic·al·ly agile

Empowering Agile Teams: The Critical Role of User Feedback in Requirement Changes

Unlock your team’s potential! Discover how to empower agile responses to user feedback and enhance your organisation’s adaptability in this insightful video.

Published on 19 July 2024

Written by Martin Hinshelwood

6 minute read

https://nkdagility.com/resources/xGuuZ5l6fCo

In the world of Agile, the ability to adapt and evolve based on real-time user feedback is a cornerstone of success. Yet, many organizations miss the mark when it comes to empowering their teams to make meaningful changes to requirements based on this feedback. In this post, we’ll explore why this is a crucial aspect of Agile that often gets overlooked, and how you can ensure your teams are truly Agile by enabling them to close feedback loops and adjust requirements as needed.

The Missing Piece in Agile Organizations

One of the most critical questions you should ask in your Agile organization is: Are teams empowered to change requirements based on user feedback? This goes beyond simply gathering feedback—it’s about whether your teams can actually implement changes to the product requirements based on what they learn.

Gathering Feedback is Not Enough

Collecting user feedback is a valuable practice, but it’s only the first step. The real question is whether your teams can take that feedback and action it. For instance, if a significant part of your product turns out to be no longer viable or aligned with business needs, can your team pivot and make the necessary changes to the requirements?

This ability to adapt is often hindered by rigid structures, such as:

Locked-in requirements: When requirements are set in stone, it becomes impossible to adjust based on user insights.
Complex change request systems: Expensive and convoluted processes can deter teams from making changes.
Lack of empowerment: Teams may not have the authority or trust to make changes, even when they know it’s the right thing to do.

Real-World Challenges

Let’s consider a scenario that often occurs in Agile environments, especially in business systems or B2B contexts. When you ask users what they need, their first response typically revolves around immediate needs—problems they’re currently facing. These are often issues that should have already been addressed in your product. However, by the time these needs are met, they may no longer be relevant or as urgent due to the delay in delivery.

As teams work on a product with a set delivery cadence—say every three weeks—businesses often project what they’ll need in the future. They might be preparing for a significant decision three months down the line, which could drastically change what the product needs to support.

Adapting to Market Changes

For example, imagine your users are anticipating a major business choice that could go one of two ways (let’s call them Option A and Option B). Depending on which option is chosen, the product requirements will shift. As a team, you might start delivering features that align with both options, but as soon as the decision is made, only one set of features will remain relevant.

In an Agile organization, it’s crucial to ask:

Can your team quickly discard or de-prioritize features that are no longer needed?
How efficiently can you close the feedback loop to remove unnecessary requirements?

If your teams can’t adapt in this way, you’re likely not fully Agile. True agility requires the flexibility to not just gather feedback but to act on it—often in real-time.

The Barriers to Change: Contracts and Complexity

One of the biggest barriers to adapting requirements based on user feedback is the rigidity of contracts and the complexity of change request systems. These can create a “locked-in” effect, where teams are unable to make necessary changes without jumping through hoops.

Rigid Contracts

Contracts that don’t account for the need to change based on user feedback are a significant obstacle. Agile organizations need to ensure that contracts are flexible enough to accommodate changes. This might mean building in clauses that allow for adjustments or working with stakeholders to agree on more adaptive approaches.

Complex Change Request Systems

Change request systems that are cumbersome or expensive to follow can also dissuade teams from making necessary adjustments. These systems, often put in place to avoid chaos, can ironically create the very rigidity that stifles innovation and responsiveness.

The solution? Streamlining these processes and fostering a culture of trust and empowerment where teams are trusted to make the right decisions for the product and the business.

The U.S. Department of Defense’s Litmus Test: Detecting Agile BS

If you’re wondering how Agile your organization really is, consider using the U.S. Department of Defense’s “Detecting Agile BS” guide. It offers a six-question litmus test that can help you assess your true agility.

The Six Questions

Are teams empowered to change requirements based on user feedback?
Is user feedback gathered frequently and systematically?
Can teams pivot quickly based on new insights?
Is the change process simple and streamlined?
Are contracts flexible and adaptive to change?
Is there a culture of trust that allows teams to make decisions autonomously?

If your answer to any of these questions is “no,” then your organization might not be as Agile as you think. While this litmus test is not about pointing fingers or labeling organizations as “non-Agile,” it is a valuable tool for self-reflection.

Reflect and Improve

As a Scrum Trainer, I don’t enter a team and immediately start pointing out where they fall short. Instead, I use these questions to help teams reflect on their current practices and identify areas for improvement. This approach fosters a continuous improvement mindset, which is at the heart of Agile.

Closing the Loop: Empowering Teams for True Agility

The ability to change requirements based on user feedback is not just a nice-to-have—it’s essential for any organization that wants to be truly Agile. To make this a reality, you need to:

Empower teams to make changes without unnecessary red tape.
Simplify processes to make change easy and cost-effective.
Build flexibility into contracts to allow for adaptation.
Foster a culture of trust where teams are trusted to make the right decisions.

Real-World Example: Adapting to User Feedback in Action

In one of my recent engagements, a team was working on a B2B system with a three-week delivery cadence. Midway through a project, significant user feedback indicated that a substantial part of the product was no longer aligned with the business’s future needs. Instead of being locked into the original requirements, the team was empowered to pivot, reprioritize the backlog, and focus on delivering the features that mattered most.

This kind of flexibility not only saved the business time and money but also ensured that the product remained relevant and valuable to its users.

Takeaway

Agility isn’t just about following a process—it’s about being responsive to change. By empowering your teams to change requirements based on user feedback, you ensure that your product remains aligned with market needs, ultimately leading to greater success. 🔄 Remember: Agile is a journey, not a destination. Keep asking the tough questions, keep reflecting, and keep improving. Your users—and your bottom line—will thank you.

Another question to ask leadership is, are teams empowered to change the requirements based on user feedback? So this is not just gathering the feedback; are you actually able to change the requirements for your product? And I don’t mean like little things on your product backlog or little things that you want your product to do. What if you find out that a huge chunky thing is no longer viable or no longer what the business needs? Are you able to close that loop? Are you able to take that feedback and actually action it and make changes to the requirements?

One of the things that happens a lot, especially when you do sessions where you’re engaging with the people who are going to be your users and you’re asking them what they want, this is especially important for business systems but also for commercial, for B2B, but also for commercial. When I ask you what do you need in a system, the first thing you’re going to think about is all the things that you need now. All of those things are too late; all of those things are stuff we should actually already have in the product. We should already be able to do because the delay in actually building it to get you to the point where you can use it is going to be quite tough. You’re, you as the business, as the consumer of the product that you’re asking for, you’re perhaps losing money or you’re perhaps losing time or you’re losing something by not having this problem that’s been identified solved.

But you’re going to give me this big chunk of things that you need now, and then you’re going to go away and think about what might my business need over the next whatever the delivery cycle is. So let’s say we are going to deliver on a three-weekly cadence where we’re definitely doing some amount of agile, but the business goes away and thinks about what’s going to happen. This product’s going to last us for the next few years, right? It’s going to be in production for the next few years. What types of things do we think we might need to work towards in order to have that product support for that length of time?

So they’re going to think about what’s going to happen in the future in the business, what are the choices that are going to need to be made in the business, and they’ll think about that big choice that’s coming up. We’re going to make a big choice in this business in, let’s say, three months’ time, and it could go A or B, right? I’m making it simple; it could be an octopus problem, right? But A or B. And if we need A, we’ve got 50 things we want, and if we need B, we’ve got another different 50 things we want. What happens when we get to that decision, and users are able to feedback to us that we’ve got to that decision? Are we able to remove half of those work items, the half that we don’t need?

What about if we’ve delivered some of those 50 work items that are going to be of value? We deliver, let’s say, we deliver 15 of them, 15 things, and we get feedback from the users that, yeah, you’re solving this problem just now. This business problem is resolved from our perspective. That other stuff that we put on your list, you’ve delivered the most valuable piece, and the rest is not as valuable. Can we go delete the rest of those requirements or at least deprioritise them or not do them?

How quickly can you close those feedback loops? Can you actually make those changes in the system? Quite often, I see teams talking to users. I see teams engaging and getting feedback and then not being able to do anything with it. They’re not actually able to change the requirements because somebody else has locked them in, and we’re not allowed to change them, or because we don’t want them to change the system because perhaps there’s a crazy contract in the way. We create a convoluted, complicated change requests system that’s very expensive to follow to try and dissuade people from making changes.

We don’t want those things; we want to be adapting to the needs of the customer that we’re seeing. We’re adapting to the market needs, and their market needs are changing constantly, which means our product and the things we think we’re going to do in the product need to also change constantly. This means as well that if you do have contracts, you need to build into the story of the contract that these things are going to change constantly.

Make sure that your teams are empowered to change the requirements based on user feedback. If your answer to any one of these questions, or the answer of your business to any one of these questions, is no, we’re not doing that, then you would probably, I probably wouldn’t consider that you’re already in the agile space, right? You’re not already agile. You might be working towards it, and you might have put in loads of effort, but unless you can mark every single one of these six questions as yes, we do this, this is how things work here, then we’re still lacking. We’re still trying; we’re still working towards being agile.

Now, this is just a litmus test dreamed up by the US Department of Defense, but they are probably the least likely place for you to expect something within this high bar to have come from. I’m not going to go into a team and work with a team or a company, and if they’re not doing these things, then I’m going to say, well, you guys suck; you’re not agile because you’re not doing this. That’s not how we work towards success.

But I think it’s hugely valuable from the perspective of self-reflection for you all to think about the processes and practices in your organisation and how many of these six questions you are able to achieve and what you could do to make it a little bit easier for the teams, for the people doing the work, to work towards this idea of not being agile BS.

Connect with Martin Hinshelwood

If you've made it this far, it's worth connecting with our principal consultant and coach, Martin Hinshelwood, for a 30-minute 'ask me anything' call.

Our Happy Clients

We partner with businesses across diverse industries, including finance, insurance, healthcare, pharmaceuticals, technology, engineering, transportation, hospitality, entertainment, legal, government, and military sectors.

CR2