"The decision making triangle"
This one is from Extreme Programming (XP).
How is a technical decision made? What forces are we trying to unify in all our procedures, phase reports, business analysis, product reviews? How is a feature request spawned and what, when presented, argues for it/against it?
The decision making triangle has three components.
The technician, who provides estimates, cost, risk and quality impact.
The customer, who translates a fluid and chaotic business domain into a concrete set of durable features.
The economist, who manages the entire backlog relating cost effective activities to return of investement, company strategy and resources.
This does not always have to be three separate individuals, and could possibly more accurately be referred to as roles/hats/influences.
If there is a crucial support issue, there is obviously no need for an explicit "customer" and "economist" role in order to respond to the matter.
Also, pair programming has a tendency to encourage being explicit and a more elaborate discourse.
Alas, these concerns should often be explicitly adressed. Not only for the quarterly review, but as an integral part of the iterative and incremental process.
As I imagine most of my imaginary readers to be technicians, we may insist that all those estimates are unreasonable. Often this may be the case, but to bring the best estimate or even the knowledge of uncertainty into the mix, is the responsibility of the technician.
This triangle is the core of the decision process, not the entirety of the team. All of the three roles may have a team of individuals behind them to carry out the respective responsibilities.
The thing I want to focus on in this post is the value of a good customer. In this context, it is not the customer with the most money or willingness to spend. I am not necessarily talking about a person outside your own company.
Above all, the customer is not a developer who has received a four inch thick requirements document in his lap.
The customer is whoever who possess the underestimated, yet invaluable, quality of translating a business problem into addressable concerns. A customer is the one who identifies the underlying durable aspects that will form a sustainable business asset.
The good customer is he whose backlog is based on, and traceable back to, true business concerns.
An organization with good customers have a good knowledge of their value flow. They can allow their model to be pull based. There are less assumptions and less liability in their efforts.
The ideal customer is he who will need the least amount of code to make the most amount of money. The ideal customer is he who lives and breathes the problem with a passion, but has a minimum of preconceptions on how it is to be solved.
No comments:
Post a Comment