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.
