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.
