3 Reasons You Need to Seek Feedback in Your Agile Process
3 Reasons You Need to Seek Feedback in Your Agile Process
When it comes to agile teams, far too many of us get trapped in the habit of working independently without a high level of external interaction ‒ this is especially true for teams working on software or web development projects.
While it’s understandable that working with others outside of your immediate sphere can initially seem stressful and overwhelming, investing a little time in clarifying details can go a long way towards cutting the number of iterations in your feature development cycle.
After all, the Manifesto for Agile Software Development teaches us that individuals and interactions, as well as customer collaboration, are core values, which should typically be prioritized over processes, tools and contract negotiations.
Additionally, agile methodologies like Extreme Programming make it a point to collect feedback from the customer on a frequent, ongoing basis ‒ but how many teams actually take that feedback to heart?
I’ve seen too many teams erroneously believe that a two-week sprint means blocking out all feedback from the customer, which can prove to be a mistake in the long-run. If you'd like to help your team move faster and collect as much information from the customer as possible, take a look at these three important reasons why your team needs to seek out feedback during your agile process.
1. You Need to Understand How the Customer Interacts with the Features You’re Building
Many agile teams understand that it’s important to collect customer feedback after an iteration is complete, but it can also be useful to collect feedback while you're in the process of building your shippable iteration.
Giving the customer a preview mode or prototype to interact with can teach you a lot about how they plan to use the features you’re building. Sometimes the way the customer interacts with the features you build is markedly different from the way in which they were expected to.
Using an abstract hypothetical, a car customer could ask an agile team to build an ejection seat to prevent death during a car crash, but their core need is more likely to be an airbag. Why? Because an airbag can better address their core requirement ‒ reducing death and injury with an efficient, cost-effective product that can get to market quickly.
While many agile teams understand the importance of collecting true customer requirements based on true user needs, why not do this on a much smaller scale as well? Your customer won’t wait for your two-week sprint to conclude before changing their mind or providing clearer requirements, so why not collect their feedback on a day-to-day basis?
Some folks may argue that all requirements should be collected perfectly up front, but making this assumption would be failing to prepare for the cases where requirements change or become clearer over time ‒ something that happens far more often than many of us want to admit. After all, responding to change is what agile teams are all about, so why block out input instead of seeking it as quickly and regularly as possible?
Sure, we can organize tasks and goals into short-term sprints without adding additional tasks or requirements, but if your requirements aren’t correctly and clearly defined at the outset of your two weeks, you’ll find that not communicating with the stakeholder during the sprint will surely result in an increment that could have better met customer needs.
2. You Need to Understand the Context of the Features You’re Building and the Work You’re Doing
The features you ship don’t exist in a vacuum ‒ real customers are interacting with these features and the results they produce. It’s important to understand how the customer interacts with the features you build on as frequent a basis as possible.
Talk to customers, and talk to them often. Don’t talk to customers solely on an individual level, but collect data on an aggregate level as well. Think about the industry or market you’re serving and its particular requirements.
In some cases, your customers may not even understand their own requirements as clearly as you can. For example, high school students might be the target market for a website or application designed to help them get into better universities, but these customers ‒ high school students ‒ may not even clearly understand the best methods to get into the best universities in the first place.
In other words, you may need to conduct research beyond customer feedback and in turn educate your customers about what they need.
There’s so much context that can help you understand the customer, which goes beyond their feedback ‒ terminology, regulations and laws, best practices and much more. Don’t assume your customers will simply tell you everything you need to know up front ‒ the features you’re working on may need to guide them or provide solutions that they themselves have not yet conceived of.
3. You Need to Uncover True Requirements Much More Quickly
As I've already alluded to, it’s crucial to reduce the cycle of understanding requirements as much as possible. Idealists will tell you that requirements should be completely understood from the get-go, but this is often an unrealistic goal.
The reality is that requirements change ‒ the customer themselves may realize new requirements, laws and regulations may change, terminology may change and a slew of other changes may occur, all of which can lead to the introduction of different requirements. Ignoring these changes in requirements simply means extending the amount of time spent building towards incorrect requirements, which will ultimately amount to wasted effort on your team's part.
As agile teams, most of us like the concept of a protected sprint, but this shouldn’t blind us to the introduction of real changes in the marketplace or customer needs. The worst thing you can do as an agile team is ignore changing realities and, in doing so, fail to adapt to changing requirements.
What You Can Do About It
Want some actionable ways you can better adapt to changing conditions? Keep in constant contact with your customers and end users.
Do frequent research on the context surrounding your product and users, such as laws and regulations, marketplaces, terminology and any other relevant factors. Shorten feedback loops as much as possible ‒ do not shy away from customers, and force yourself to interact with them and ask as many questions as you can.
Remember, agile is all about responding to change, so staying ignorant to the changes surrounding your work is a fatal mistake. Don’t just respond to change ‒ seek to study and anticipate changes as quickly as you can, and you’ll be able to ensure the iteration you’re working on is heading in the most accurate direction possible.
Ken Shen Robinson is a senior product manager at Praetorian Digital, where he leads product management for EdTech products that make our communities smarter and safer.Learn More