Channels ▼


Scaling On-Site Customer

Stakeholders Over Stakeholder Proxies

There's a very real danger of product owners becoming a bottleneck on Agile project teams, particularly at scale. What development teams really need is direct access in a timely manner to the stakeholder(s) with the domain expertise required to address any questions that they may have about the functionality they are currently implementing. Stakeholder proxies are good, actual stakeholders are even better. A critical task performed by product owners is putting developers in touch with the right stakeholders in a timely and efficient manner.

Another important technique that doesn't get the attention it deserves is observing end users at work. In the late 1980s, the user-centered design (UCD) community showed us that what end users told us they did, and what they actually did in practice, could vary widely. People will often discuss the ideal way of working, ignoring significant details and less-than ideal events. For example, how many times have you told people that your morning routine is to wake up, shower, dress, have breakfast, then get off to work? Yet we all know that far more than showering occurs in the bathroom each morning, enough said about that topic, and that many of us would be embarrassed to admit what we actually consumed for breakfast. Until you observe people in action, you'll never know what actually happens, and therefore you'll never truly understand their needs.

To successfully scale the concept of agile customers to meet your specific needs, my experience is that you should adopt four values pertaining to stakeholder relationship management. In the lingo of the Agile Alliance, these four values describe preferences; while the ideas on both sides of each value are important, the ones on the left are more important than the ones on the right. These four values are stakeholders over customers; communication conduits over product owners; business analysis over business analysts; and stakeholders over stakeholder proxies. In this instance, the Agile community can clearly benefit from taking the good ideas of traditional development while leaving behind the bureaucracy.

Thanks to Mike Vizdos for his insightful feedback, which was incorporated into this article.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.