Active Stakeholder Participation: An Agile Core Practice

Table of Contents

1. Who are stakeholders?
2. Why is stakeholder participation important?
3. Strategies for working together
4. Gaining access to stakeholders
5. Factors affecting stakeholder participation

1. Who Are Stakeholders?

Agile Modeling (AM)’s definition of stakeholder: A stakeholder is anyone who is materially impacted by the outcome of an initiative. This includes business stakeholders (such as end users or senior management), supporting stakeholders (such as enterprise architects), and downstream stakeholders (such as support engineers or sales staff). Although the development team is also a stakeholder of their own work, in AM we distiguish between “the team” and “their stakeholders” for ease of discussion.

2. Why is Stakeholder Participation Important?

People are not very good at defining, particularly in detail, what they want. However, people are fairly good at indicating what they think they want and then when an option is presented to them what they like and don’t like about it. In other words, we need to work with our stakeholders to identify what they think they want, produce something which reflects that understanding, get feedback from our stakeholders, and then update our solution to reflect our improved understanding. The implication is we need to work in a more evolutionary and collaborative manner if we’re to provide solutions which reflect our stakeholders actual needs, and to do that we must work closely and regularly with stakeholders.

Traditional approaches to software development which are based on defining a detailed requirements specification early in the initiative, referred to as “big requirements up front (BRUF)” strategies, prove to be very risky in practice. Traditional teams, even the “successful” ones, typically produce less than ideal results when they strive to produce a solution which reflects the specification. Yes, the team may produce something to specification but it likely won’t be what the stakeholders actually want, but instead what they thought they needed at some point in the past. I believe that the goal of a disciplined agile delivery team should be to provide their stakeholders with a solution which fulfills their current understanding of the intent of their stakeholders as effectively as possible given the constraints of the situation, not build something to specification.

3. Strategies for Working Together

It is clear that in order to be successful all stakeholders must actively work with your team to achieve these goals.There are several implications of this practice:

1. Timely decisions. Stakeholders must to be prepared to share business knowledge with the team and to make both pertinent and timely decisions regarding scope and requirement priorities.
2. Inclusive modeling. You need to adopt inclusive modeling techniques, which are based on user-centered design (UCD) and participatory design principles, which stakeholders can easily learn and adopt.
3. Management requires IT skill and knowledge. For senior managers to effectively support your initiative they must first understand the technologies and techniques that your team is using, understand why your team is using them, and understand the implications of using them. With this knowledge their efforts within your organization’s political arena are far more likely to be effective at the right times in the right ways. Senior managers won’t be able to gain this requisite knowledge simply by reading a weekly status report or by attending a monthly steering meeting. Instead, they need to invest the necessary time to learn about the things that they manage, they need to actively participate in the development of your system.
4. Production staff are involved from the start. Your operations and support organization must invest the resources required to understand both your system and the technologies that it uses. Your support staff must take the time to learn the nuances of your system, the implication being that they need to work with your system as it is developed and/or your team will need to provide them with training. Furthermore your operations staff must become proficient with both the installation and operation of your system.You may choose to include one or two operations engineers on your development team or once again to invest resources to train operations staff as required. Regardless of your approach, both your operations and support organizations will need to be actively involved with your team.
5. Take an enterprise view. You need to work with other teams if your system needs to integrate with other systems. For example, perhaps your system needs to access a legacy database, interact with an online system, work with a data file produced by an external system, or provide an XML data extract for other systems. Integration often proves difficult if not impossible without the active participation of these developers: imagine how difficult it would be to access the information contained in a large legacy database if the owners of that database refuse to provide any information about that database. Some initial architecture envisioning will help to drive this.
6. Don’t just hand-off to the maintenance team. Maintenance developers need to work with you to learn your system. When the intention is to either partially or completely hand-off the maintenance of your system to other developers, it is common to bring in software professionals skilled in maintaining and enhancing existing systems to free up members of the original development team, then your team must work with these people so they can take over the system from you. Even when some original team members are still involved an effort must be made to transfer the knowledge to the new members of the team.

4. Strategies for Gaining Real Access to Stakeholders

I have never been on an IT initiative, agile or otherwise, where I couldn’t get regular, direct access to key stakeholders or their representatives. I’ve worked on initiatives in the financial industry (including brokerage), retail, telecommunications, e-commerce, software product development, government (including military), and others. I have, however, worked on many teams where people provided excuses (none of which ever held any water) for why they couldn’t get access to stakeholders. Common excuses included:

1. Understand why stakeholder involvement is important. First and foremost, you need to understand why active stakeholder involvement is important and what the impact to your team will be if you don’t have it. In many organizations you will be required to justify why stakeholders need to be actively involved with an IT initiative, and the better you understand why it’s important the better you’ll be able to argue for it.
2. Get support from the stakeholders themselves. Some of your stakeholders would love to be actively involved with your team, and many more could likely be easily convinced that they should be involved.
3. Educate senior management. In many organizations senior management will need to determine, and then support, the level of involvement of stakeholders. To make this decision they need to understand the alternatives and the trade-offs of each. .
4. Be flexible. Although you would like to be co-located with your stakeholders and have instant access to them, it doesn’t always happen that way. You may only get to interact with them for a few hours a day, or only for a few hours once a week. More access is generally better, but as you can see below there are several reasons why it can be difficult to gain access to them on a continual basis.
5. Be prepared to work with stakeholder representatives. Regardless of the inane rhetoric you may have heard, you will almost always end up working with people representing the wider stakeholder community (this is certainly true of product owners).
6. Fight for it. Active stakeholder participation is crucial to the success of your initiative because without it you won’t know what your stakeholders actually need.
7. Keep fighting for it. Throughout the initiative there will be pressure to divert stakeholders away from the team so that they can focus on their normal “day jobs”. You may need to keep up a regular communication stream thanking the stakeholders for their participation (always a polite thing to do regardless) and reminding them of the positive impact that they’re having on the effort.

Gaining access to stakeholders, let alone gaining their active participation can be hard for several reasons:

1. We’ve trained stakeholders to work in “hands off” manners. For several decades we’ve told stakeholders to follow a serial/traditional approach to IT initiative — we’ll do some initial requirements gathering, we often ask them to sign off on the requirements and plan, we’ll give them periodic updates of how the effort is going, and then months or sometimes years later ask them to be involved with acceptance testing. In other words, have short, defined periods of involvement with longer periods of virtually no involvement in between. With modern approaches, such as agile, we’re now asking them to be involved continuously throughout the initiative.
2. Many stakeholders don’t trust us. The traditional approaches to solution delivery haven’t worked out very well in practice from the point of view of stakeholders. According to the 2008 IT Project Success Survey traditional strategies have not been very effective at delivering functionality which stakeholders actively want, something backed up by the Standish Group’s Chaos report (see the BRUF article for details).
3. It isn’t part of their job. Many stakeholders believe that they don’t need to be actively involved with IT teams — IT work is the job of the IT department after all. This can be a difficult cultural issue to overcome.
4. They believe it’s too hard. Many traditionalists will use complex diagrams which use notations that stakeholders aren’t used to seeing nor all that interested in learning. Agilists prefer to use inclusive tools, such as plain old whiteboards (POWs) and paper, and sketches to model with stakeholders.
5. They believe their normal “day jobs” are more important. From the point of view of the stakeholder this is fair, but from the point of view of your organization it likely isn’t. Whenever I run into the situation where I’m told the stakeholders are too busy or their time is too valuable I question the logic of this. If that’s true, then what you’re being told is that the value to the organization of their day jobs is greater than that of the IT team. If that’s the actual case then the resources being invested in your initiative should really be diverted to helping the stakeholders do their day job.
6. They really aren’t available all the time. The normal activities of your organization still need to occur in parallel to your IT initiative. Some stakeholders may not be available during normal business hours. For example, I’ve worked in brokerage firms where we weren’t able to interact with traders during trading hours, but could do so during other times. Some stakeholders may only be available part time, perhaps only an hour or two a day at certain parts of the day.

5. Factors Affecting Stakeholder Participation

There are several factors which will impact the nature and quality of how stakeholders participate with a solution delivery team. These factors are summarized in Table 1.

Table 1. The factors impacting stakeholder participation on IT initiatives.

Related Resources

• Inclusive Tools and Techniques
• Team Member Rights and Responsibilities