The fourth principle of agility (www.agilealliance.org) states that "Businesspeople and developers must work together daily throughout a project." However, businesspeople aren't the only stakeholders of a software development project, so it would make more sense to specify that project stakeholders and developers must work together daily throughout a project. Your stakeholders are the primary source of domain information, and without ready access to them, you risk failure. Fortunately, you can adopt several strategies to ensure adequate access to these sometimes elusive individuals.
Project stakeholders include anyone affected by the development or deployment of your system. This group incorporates direct or indirect users, managers of users, senior managers, operations staff, support (help desk) staff, developers working on other systems that interface with yours, and anyone else responsible for maintaining the system. To succeed, you must understand and then synthesize all of these people's requirements into a cohesive vision.
In agile software development, stakeholdersnot developersare the source of requirements. And in the end, stakeholdersnot developersare the ones who prioritize what gets done. In some methodologies, including both Extreme Programming (XP) and Scrum, your stakeholders are expected to provide information and make decisions in a timely manner. Agile Model Driven Development (AMDD) takes this one step further by suggesting that stakeholders can and should be active participants in requirements and analysis modeling. On agile projects, stakeholders get to define new requirements whenever they want, rework existing requirements and even reprioritize those requirements. This approach ensures that developers build systems that meet their stakeholders' highest-priority needs.
But in addition to its benefits, agile development presents a serious challenge. Stakeholders must invest the time and resources required to work actively with the project teambut they may be too busy, or may not want to put the effort into your project because they've had bad experiences in the pastor they may simply not understand why their participation is critical to success.
Calling All Critics
If you're having problems gaining access to stakeholders, your first step should be to educate them about the vital importance of their participation throughout the entire development process. Traditionally, developers have trained their stakeholders to be involved only at a project's beginning and end, first for requirements definition and then for acceptance testing. With such diminished expectations, we shouldn't be surprised that our stakeholders don't understand how important their input really is. On an agile, iterative project, however, it's no longer acceptable to leave customers out of the loop for months or years at a time.
If education doesn't work, try the shock technique: Suggest canceling the project. If your stakeholders' time is actually more important than participation on your project, you should divert your project resources toward helping them do their daily jobs. (Not surprisingly, every time I've explained it like this, senior management suddenly realizes that the stakeholders' time can in fact be freed up to work on the project.)
Once your stakeholders have committed to working with you, your next step is to be flexible with them. You need to address three issues: the frequency of stakeholder participation, the techniques applied to garner that participation and the way that stakeholders are represented on the project.
Of course, we'd love to have our stakeholders readily available to consult with us around the clock. In reality, though, stakeholders are often too busy. But they can still participate in a project in various ways.
For example, if you're working on a brokerage system, some of your stakeholders are stock traders who work with hundreds of millions of dollars each day. You can't bother them during trading hours, but it may be reasonable to interact for an hour or two per day outside of this period. In other situations, you may have someone available for only one morning a week on-site, and then via phone and e-mail the rest of the week. Or perhaps your stakeholders will fly in for several days at the project's beginning and for occasional reviews, but will then be available only electronically throughout the remainder of the project. The important thing to focus on is making the most of the time you have together.
In a perfect world, your stakeholders would speak with one voice, but in reality, stakeholder conferences are often reminiscent of the Tower of Babel. For example, in the brokerage system, stakeholders include the stock exchange owners, representatives from financial institutions and government regulators each with their own, often conflicting, set of requirements and priorities.
How to tame this cacophony into a productive harmony? You could gather all the stakeholders in one room and try to come to a consensus, but this typically leads to either outright anarchy or wishy-washy requirements that may not be of much value.
Another approach, one practiced by Scrum, is to empower a single stakeholder to represent the others, provide information and make decisions within the project team. The advantage? You have a single source of information. But beware the flip side: The challenge of managing diverse stakeholder needs lies heavily on just one pair of shoulders. Just make sure you've got an Atlas who's adept at keeping communication lines open.
Which Way Works?
The effectiveness of stakeholder representation strategies varies widely.
We the Stakeholders ...
It's always best to have the stakeholders represent themselves, but sometimes that isn't possible. Many developers build shrink-wrapped software or systems that are deployed to the Internet, and as a result, they don't know who many of their customers are. In such cases, it may be useful to assign a product manager from your marketing or other department whose job is to provide vision and direction for your project. This approach offers the advantage of placing the responsibility for identifying and prioritizing requirements on someone outside your IT department.
If your stakeholders prove extra-elusive, you might have a business analyst fill in for them. Experienced analysts often know the business well; after all, they've been modeling it for years. However, if they've never had actual work experience within the domain or if their experience isn't recent, they may be out of touch with the detailed nuances that actual users can provide. This strategy may also put too much authority in the hands of your IT department, which could mean that IT is not only building the system but defining what the system should do. This may offer far too much opportunity to make questionable decisions.
A third option is to develop models called personas, descriptions of individuals who might use your systems. These are the archetypal end users. Personas can include personal details, such as hobbies, personality and general outlook on life. To developers, good personas start to seem like real people; it's common to hear questions such as, "How would Ed Maloney work with that feature?" (See "Which Way Works?" )
No More Excuses
Throughout my career, I've heard many project teams claim that they can't get access to their stakeholders, but I've yet to hear a compelling reason.
One client develops several shrink-wrapped products. Its end users span the globe, and few are located near the company's development center. However, management understands that the organization's success in the marketplace is primarily determined by its ability to deliver working software that solves its customers' problems. So at the beginning of each major project, the company flies in potential end users for a weeklong requirements workshop. It invites users from existing, new and prospective clients, as well as end users who have called the company's help desk with complaints or ideas for new features. Each workshop focuses on formulating an initial set of requirements to educate the product manager who will represent the users throughout the project. Although this approach is initially expensive, it pays off tenfold in the long run.
Lack of access to the appropriate project stakeholders is probably the greatest risk facing software development projects. If you're willing to fight for access, there's no reason you shouldn't get it. Next month, I'll cover a collection of specific techniques that facilitate stakeholder participation.
Effective Stakeholder ParticipationSix tips for involving your customers in your projects.
Successful software developers recognize that:
Scott W. Ambler is a Canada-based software process improvement (SPI) consultant, mentor and trainer with AmbySoft Inc. He has written several books and is a regular speaker at software conferences worldwide.