Patterns of Agile success – Part 3 of 6
This mini-blog is taken from our session Adapting Agile and is the third part in our series on Patterns of Agile Success.
Following many years of practical experience, we have identified similar patterns in organisations successfully using Agile principles and practices. The story so far… In Part 1, we looked at how organisations who believe they are committed to improving their outcomes can check on how deep that commitment runs. Part 2 examined one of the most valuable and important elements of Agile methodologies – delivering in increments. Here, we examine another core element that can cause problems for some – feedback.
Feedback
Feedback is essential to Agile because it is the empirical base that powers improvement. We form a hypothesis, we examine the assumptions behind it and then we test the hypothesis. With the feedback that results from the test we adjust our hypothesis and act.
In practical terms for developing new products and services, what this really means is that we iterate our designs and processes. Agile doesn’t expect to get everything right first time, and rather than investing heavily in perfecting a specification or requirements up front, it favours the route of – build, check, rebuild. It rests on the unspoken assumption that things will change anyway, and therefore it’s better to have a way of working that welcomes change.
Feedback comes in many forms and can be sought in many ways, but in essence we are always looking for what a customer will value. We must combine feedback with iteration, whether that’s in the detail – refactoring our code – or the big picture – evolving the design. If we don’t, then feedback is just waste.
Risks of ignoring the pattern
Short feedback loops reduce risk. The longer between feedback cycles the greater the risk that you are heading down a dead end or making a costly mistake. You ignore feedback at your peril, and moving without it is like flying blind.
Signs to watch out for
Do you seek out unwelcome feedback as well as the positive?
It is normal to reject or ignore unwelcome feedback, but it is fatal. A demonstration means showing everything to the customer as it is: there is often a temptation to turn it into a sales pitch, but this will undermine the real purpose of the meeting. Only by exposing warts, workarounds and all honestly will you find which elements are truly ‘essential’ to the customer. Taking feedback seriously also means trying to ensure demonstrations are regular and in person. You will receive much richer feedback if you are able to study body language as a customer plays with the software, as well as reading an emailed report.
Looking for full feedback also means searching out customer complaints. Do your development teams regularly meet with call-centre representatives to listen to users’ bugs and annoyances? Or do these get handed off onto a routine maintenance team?
Are the teams involved in testing alternatives? The best teams are eager to try out different ways of doing things – they don’t know which way is better, so they set up a test. If this is left to a Marketing Manager or Product Owner to suggest, then feedback is not fully integrated into the team.
Do you gather real customer feedback?
Most Agile methods introduce proxy customers. It’s a helpful device, but devolving sole responsibility onto an individual and thinking that you have ‘customer feedback’ can be a major error. The team should always be agitating to get software into the hands of real users. When feedback conflicts (as it often does), is there a hierarchy of whom should be listened to first? A range of users and customers will help ensure changes aren’t being made on the whim of one person or single user group.
Do you use feedback?
It’s not uncommon to gather feedback – and then just abandon it. This is where some struggle. Are you deleting unused features? Are you observing real marketplace data and using it to inform future releases or even completely different products? Are you changing the plan based on the current realities? Of course, you can choose to ignore feedback – but this should always be a deliberate decision, not an accidental one.
Additional Insights
The future of full stack engineering talent
The art of feedback
Don’t confuse tools with technologies
