With Ron Jeffries comment on my “Negotiating Estimates” post, I think we’ve reached agreement on a common problem, even if we disagree (perhaps?) over how to fix it. As I noted in my short answer, my position is that abuse of estimates stems from a deeper issue. Changing a practice won’t eliminate the abuse. Changing culture will. Changing that culture (where possible) involves convincing the players that it’s in their best interests to change, which it is.
This is my biggest objection to #NoEstimates. It makes an illogical leap that the practice is responsible for problems rather than some underlying dysfunction without showing causality. This putting the cart before the horse risks encouraging people to espouse action that is probably both ineffective and detrimental to their relationship with their customer. The likeliest outcome I see from that is more problems, not fewer.
The word “customer” was a point of contention:
It’s my position that, for better or for worse, there is a customer/provider relationship. Rather than attempt to deny that, it makes more sense, in my opinion, to concentrate on having the best possible customer/provider relationship. While poor customer service is extremely common, I’d hope everyone can think of at least one person they enjoy doing business with, where the relationship is mutually beneficial. I know I certainly can, which stands as my (admittedly unscientific) evidence that the relationship need not be adversarial. A collaborative, mutually beneficial relationship works out best for both parties.
“Collaborative”, however, does not mean conflict free. In his post “Against Estimate-Commitment”, Jeffries states:
The Estimate-Commitment relationship stands in opposition to collaboration. It works against collaboration. It supports conflict, not teamwork.
I both agree and disagree.
There will be conflict. Different team members will have different wants. Different stakeholders will have different wants. The key is not in preventing conflict, but resolving it in a way agreeable to all parties:
Recognizing, rather than repressing conflicts might even be beneficial:
What is critical, is that the relationship between the parties not be one-sided (or even be perceived as one-sided). In-house IT often has the peculiar characteristic of seeming one-sided to both customers and providers. The classic model of IT provision is, in my opinion, largely to blame. It seems almost designed to put both parties at odds.
The problem can be fixed, however, with cultural changes that encompass both IT and the business units it serves. One such change is moving from a project-centric to a product-centric model that aligns the interests of both groups. This alignment cements the relationship, making IT a valuable partner in the process rather than an obstacle to be overcome to get what’s wanted/needed. Relationships are key to success. By structuring the system so that each group’s incentives, conflicts and all, are aligned to a common goal, the system can be made to work. We’ve certainly had plenty of examples of what we get from the opposite situation.
Form Follows Function 
Commitment is core to team success http://goo.gl/HP8w20
Commitment requires resolving conflict
Conflict provides visibility into the gaps that must be closed to assure commitment is focused an the “shared outcome”
“Mutual accountability” requires conflicts be addressed and process put in place to work within those conflicts for the “shared outcomes”
LikeLiked by 1 person
Indeed…not to mention that commitment by the provider strengthens the commitment of the customer to the provider. I have people I’ll go out of my way to do business with because I know they’ll provide the best possible service. By treating me fairly, they’ve insured that I’ll drive as much of my business their way as possible. I believe it’s called a virtuous circle.
LikeLiked by 1 person
Gene, to stretch an analogy, perhaps to the breaking point. Commitment in marriage, friendship, child rearing, dog training is the basis of all collaboration.
LikeLiked by 1 person
Pingback: What We Have Here is a Failure to Communicate | Form Follows Function