Most of us genuinely care about doing quality work and want our customers to be satisfied with our work. When we receive customer requests that are questionable or even ill-advised, we are usually not happy about having to sacrifice craftsmanship for customer satisfaction. But as agile practitioners who strive for customer satisfaction, we can offer our opinion and feedback, but at the end of the day we need to deliver what the customer wants. Right? Or are there times when flat-out saying no is the right thing to do?
My company maintains a complex stack of applications, and the dependencies between layers sometimes leads to bickering between teams over who is responsible for implementing X or Y functionality. Our team was recently asked about making a change in our application to accommodate a certain quirk in one of the lower layers. Normally, we would just grumble about cleaning up another team’s mess and get on with our lives. But this particular quirk wasn’t just inconvenient, it was non-compliant with an industry specification, and our external customers would notice. Implementing a workaround at our level of the stack would have left our customers with a defective product and a long release cycle to wait before they could receive a fix. And less importantly, but still relevant, that workaround meant adding unnecessary cruft to our application that would increase the maintenance burden on our team.
I felt that was unacceptable and firmly explained to the product owner why the defect should be fixed at the source instead of asking us to implement a workaround. When he brought up the workaround again, I explained it again. When he tried to justify the workaround, I explained it again. And a few days later, the product owner told me that the other team had accepted responsibility for the defect and would be handling it.
Even though the very first principle behind the Agile Manifesto says that “our highest priority is to satisfy the customer,” we need to remember that that is not our only priority. Or put another way, sometimes you need to consider customers beyond the immediate ones whom you deliver software to. Sometimes pushing back on a request, even if it was properly channeled through the product owner, is the best thing to do.
Now, I’m not saying that challenging your product owner should become your usual way of interacting with them. There should be far more collaboration than clashing within a scrum team. But knowing when to step outside the lines a little bit is, itself, an agile virtue. And I believe that being able to make those (hopefully infrequent) calls is one of the things that separates those who strictly follow agile “rules” from those who are truly agile.