Channels ▼
RSS

Design

Scaling On-Site Customer


Scott is a DDJ Senior Contributing Editor, Practice Leader Agile Development with IBM Rational, and author of several best-selling books. He can be contacted at www.ambysoft.com/scottAmbler.html.


A common stumbling block when trying to scale agile software development for complex situations is how to understand, prioritize, and then act on the multitude of requirements, which their system must address. This is an issue that traditional teams also face, one that is often addressed by business analysts. While business analysis activities are important, it doesn't imply that you necessarily need people in that specific role, nor does it imply that you need detailed requirements documentation. Then again, Extreme Programming's (XP) practice of having a single "on-site customer" doesn't seem to work beyond anything more than the simplest of situations. Most real-world Agile teams find that they need something in between these two extremes.

To successfully scale XP's on-site customer practice to meet your specific needs, my experience is that you should adopt four values pertaining to your relationships with stakeholders. 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.
  • Stakeholders over stakeholder proxies.

Stakeholders Over Customers

The idea of the on-site customer practice is that there should be someone for the team to go to for timely information about the domain and to make timely decisions, particularly when it came to prioritization. Unfortunately, many people misinterpreted this advice to mean that you only needed to work with a single person, that you only needed to focus on the needs of end users, or that the person funding the project (the "gold owner") should drive all requirements. In the second version of XP, these misconceptions were cleared up, yet many teams still seem to fall into this trap.

Years ago, in Agile Modeling (Wiley Publishing, 2002), I pointed out that projects have a wide range of stakeholders, far more than just end users and gold owners. We also need to consider the needs of operations and support people, senior managers, architects, regulatory compliance auditors, senior management, and so on. These stakeholders all have important, different, and sometimes conflicting needs, which your project team must take into account. Unfortunately, it can be daunting when you first visibly recognize how many stakeholders actually exist, but the fact is that you will put your project team at risk if you limit yourself to just business stakeholders.

In Outside-In Software Development (IBM Press, 2007), Carl Kessler and John Sweitzer described a strategy for categorizing stakeholders. This categorization helps to make the range stakeholders explicit while at the same time managing to simplify the overall concept. Their four stakeholder categories are:

  • End users. The people who will use your system, often to fulfill the goals of your principals. They typically want systems that are usable and enable them to do their jobs more effectively.
  • Principals. The decision makers who ultimately pay for and then put your system to use. This includes gold owners, senior business management, and purchasers of the commercial systems.
  • Partners. People who make the system work in production. This includes operations staff, support staff, trainers, legal experts, installers, application hosting companies, and application developers on external systems, which integrate with yours.
  • Insiders. Members of the development team and people who provide technical and business services to your team. This includes enterprise architects, database administrators, security experts, network experts, toolsmiths, marketing experts, and sales staff.


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