“Failure is Feedback and Feedback is the breakfast of Champions” – fortune cookie
Most everyone would agree that feedback is an essential ingredient to successful delivery. Feedback helps you to improve, whether you are a cashier, a coach, a teacher, or part of a software development team. So why is it so hard to accept feedback? If feedback is so important why don’t we welcome it as early and often as we can? Many times it can be the delivery of the feedback itself. If you are not expecting feedback it can come across as negative or as criticism.
Years ago I was a member of a project following the classic waterfall approach. During my first month on the project I attended a meeting where our development team was demonstrating the functionality being delivered for acceptance testing. The representatives in attendance had been involved in the requirements gathering a couple of years back and had signed off on the final requirements. The representatives also participated in Q&A sessions during the development phase of the project. During these sessions our analysts shared screenshots, and in some cases demonstrated a small subset of the final product. However, this meeting was the first time everyone was seeing the product in its entirety.
Surprise!
The client was not happy with what they were seeing. Comments ranged from “That is not how it is supposed to work” to “Why does it look like that, my team will be confused” to “That label is incorrect, it should say… ”. With several representatives in the room, this was the perfect time for them to provide feedback. However, our team was not expecting this type of feedback. This was a demonstration of the functionality we were delivering for acceptance. There was no time to make all the changes the client was asking for.
Our project manager responded with “This is what the requirements documents say and they have been signed off on”. It was obvious the project manager was not comfortable with what he was saying, but it was his only defense. As you can imagine his defensive tactic was not received very well. The result was an uncomfortable room and lots of decisions to make on how to move forward. How could this have been prevented?
Early and Often
The feedback that was received at this meeting was great feedback. However, the feedback should have occurred much sooner when changes to the system would have been significantly less risky and costly. I believe it is safe to say if you are reading this you know why feedback is important. You also understand how feedback can improve a process. But you may not fully understand (in software development) where feedback can begin and how it can be continuous.
In software development, customer’s wants and needs can change daily resulting in ever-changing requirements and priorities. One of the principles behind the Agile Manifesto is to “welcome changing requirements, even late in development.“ But development teams want to accept these changes without adding risk to the quality of the final delivery.
Client feedback is critical to the success of a product. However, it is only one of many sources of feedback. What about the feedback you can obtain from the code itself, tools, processes, or other team members? Processes such as Scrum, continuous integration, continuous delivery, and DevOps encourage feedback every step of the way. Following these processes help development teams receive feedback every day, all day, enabling them to meet their customer’s ever-changing expectations.
In Conclusion
Don’t wait until it is too late. Software development teams should encourage and accept feedback as early and as often as possible. Without feedback, you don’t know if what you are developing is what the customer wants. In the upcoming months, I will be writing a series of feedback blogs. Each blog will discuss different tools, processes or principles behind receiving feedback throughout the entire software development lifecycle.
