A year ago, we created a new feature that I tested diligently, loving every moment of it. Yesterday, almost a year later, we received feedback that the "works as designed" isn't quite good enough for the purposes of a type of customer. I looked at the email, frustrated as it outlined concerns I had raised a year ago without reaction. When the response email from a developer mentioned "we had not thought of this scenario", I bit my lip not to correct. Correcting isn't helpful.
I would love to speak in specifics, but I can't. No one is telling me what to write and what not, but I sense things myself. When creating features around security, the less people know of the inherent designs the safer our clients are. But I can speak on concepts. And the concept of what I tested and what information got dismissed delivered by me but accepted by the customers is relevant.
We work in an agile/devops fashion. The feature got built increment by increment, and included numerous releases before it was officially out there. Each increment, we would talk in the team of the thing we would be adding. It was always natural and fluent to test everything that got mentioned as functionalities to add. It was also evident to test error cases with the functionalities we added. Equally, it was evident to test those functionalities for security, performance, reliability and ease of use. The feature was built on a windows service, and testing the integrated system was evident.
What was not evident is the testing of other similar features integrating with the same windows service. Well, it was something I did. It was something I reported on. It was something where we agreed that we'd change things if customers felt the way I did.
For well over six months in heavy use, we did not hear back. Until now.
I could take this as "it's just time for adding that functionality", in incremental fashion. It's not like anyone was relaxing and slacking off in the meanwhile. Or, I could take it as yet another consideration of what goes wrong with providing and accepting feedback.
When we build incrementally, I find we are not often concerned on things beyond the immediate agreed scope. It takes quite a skill in seeing connections in the product ownership to see the whole, when development teams tend to focus on the slice they're pointed at.
The long delay in feedback brings things back as surprises to current plans. There was the feedback with a short delay that got dismissed. But all in all, reacting to this feedback right now with a short cycle to delivery we've built makes the customer happy regardless. In a world where they are still used to wait 6 months or more for a resolution, delivering fast makes them feel happier than having it right the first time.
