Channels ▼
RSS

Design

Scaling On-Site Customer


Communication Conduits Over Product Owners

Because there is a wide range of potential stakeholders, it is difficult for a single person to represent them all, yet this is something that Agile teams often strive to do. Scrum (www.implementingscrum.com) is a partial methodology that focuses on project and requirements management that has a role called product owner, the single person who is responsible for prioritizing the team's requirements. Yet, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole. Product owners are in effect a communication conduit between the project team and its stakeholders.

Internally, the primary goal is to get the team information and decisions in a timely manner. That doesn't necessarily mean that the information has to come directly from the product owner, they instead may choose to put the team in contact with the appropriate expert stakeholders. Their primary external goal is to make the team's progress visible to the overall stakeholder community and thereby build up people's trust in the team's ability to deliver high-quality working software. Because the product owner is a communication conduit between these two groups, they often find themselves needing to define, communicate, and negotiate everyone's rights and responsibilities (see www.agilemodeling.com/essays/activeStakeholderParticipation.htm for some suggestions).

The role of product owner on Scrum teams greatly simplifies things for developers because they're the ONE person to go to for getting answers from the outside world, but in practice, all this really accomplishes is dumping the complexities of working with stakeholders onto their shoulders. Because Scrum provides little advice for people in this role, they quickly find that they need to supplement Scrum with the techniques of Agile Model Driven Development (AMDD), in particular, those pertaining to agile requirements analysis.


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.
 

Video