This post is a follow-up post to my earlier blog post, “Working Agile in Practice, not Theory”. You can read it here. In that post, feedback was only covered passingly. As feedback is a central tenant in agile software development, I want to cover it more in detail.
Feedback is Central to Agility
Agile software development was designed so that developers would be able to receive quick feedback on the solution that they are building. The feedback received should confirm the developers initial direction or provide evidence for a pivot to a new direction. All the feedback gathered throughout the process adds up to the release of valuable software. Value comes from the interaction of individuals in developing a solution.
Some think that value originates from the early phase of development. It may be a product owner finding a space in the market for a solution. Or, maybe value is found by an analyst finding an enhancement that will produce more efficiency, savings, or whatever. But, unless that discovery is validated through feedback, value isn’t really created. A product owner shouldn’t make decisions on his or her own. They need to consult their users.
Who is Giving Feedback Matters
Gathering feedback to check a box doesn’t cut it when you want to have true agility. Doing a demo after an iteration doesn’t matter if the demo is with people that don’t matter. You can do perfect demos with all the executives, middle management, and supervisors all you want, but their feedback won’t translate to value if they are not the principle users of the solution.
As an example, take a company that is wanting to replace a piece of reporting software. Per the users, everything works fine with the reports. The users know how to quickly get to, interact with, and derive solutions from the reporting solution. Now, say you have executives that want to replace that solution with a cheaper, custom-built solution. Does the lower cost of running the new solution translate to value? No, it only translates to value if the end-users are asking for the change.
Even if the solution were to successfully replicate the original reporting system, with no apparent change in functionality, value would still not exist. How? Well, for one you have the cost of building the solution which will be expensive (even if you outsourced). Even if you were to roll that cost for the duration of the solution (say five years), the cost versus the savings would be a wash. More importantly, the time spent on replicating a solution could have been used to build something else where change was needed. A development team’s most precious resource, outside of their talent and knowledge, is their time. You only have the team for so long before things change. If you don’t have them focusing on things that really create value, as gathered from actual feedback, then you are devaluing the team. You are not showing business agility.
Ignore Feedback, Increase Risk
Here is a great illustration of why feedback is important. If you have ever played the game of battleship, you can imagine how important it is to get instant feedback. Go to this site, and try out this game. You will have two chances to play battleship. The first game is with no feedback until you submit your shots for review. The second version, you will receive an instant notice of whether your shot made a hit or not (like traditional battleship). Here are my results when I played:
In the first iteration, with not immediate feedback, I was able to hit something 11 times. I successfully sunk 1 ship. On the second version, with immediate feedback, I only did one better in terms of hits. I hit something 12 times. However, I was able to sink 4 ships instead of 1. The time to use all 30 shots for each game was pretty much the same (I may have been only 7 seconds quicker) on the second game.
So what does this tell us? Feedback matters. If you are trying to make a direct hit with your solutions, you need immediate feedback. Not only that, you need feedback from the right people. You need to find the people that can actually tell you if you are hitting or missing the mark with your solution. More often than not, the people that matters are the ones on the ground and not in the tower.
Just like the agile battleships game, if you ignore feedback, or collect feedback from people that don’t really matter, you are expending energy on a solution that will be less valuable overall. For businesses that understand what true agility means, it is a risk that is not acceptable.
Thanks for reading.
Being > Doing
David Bjarnson
