Multiple stake-holders and Agile

There are many times when a team ends up with having to deal with multiple simultaneous stake-holders, or at least with several external folks that have an interest in what the team does. As they all try to direct and prioritize the team’s work, often in a somewhat contradictory fashion, the team finds itself thrashing as it runs down one path of execution and then another the next day. This makes the situation sub-optimal and leaves team-members feeling unsatisfied as they get almost nothing done.

How does a project-manager or scrum-master handle this? After all, while the scenario described can clearly distress a team, it also affects the scrum-master in quite a stressful way. I’ve seen many people try to find a “real” solution by attempting to get all the stake-holders in a room together and try to get them to come to some form of consensus. This is definitely something worth pursuing, but often, this can take a long time in many large organizations. Eric Anderson, a colleague, and I were conducting a retrospective the other day when he made a comment about how one can use a basic aspect of the Agile process to help clarify the direction for such a team.

While each stake-holder feels that his or her agenda is as important as anyone else’s, quite often, everyone involved is aware of the overall goals for the team. When faced with clear consequences of picking one priority over another, they can make good decisions. In many cases, the issue is not as much one of conflicting goals, as much as it is of not having a clear picture of the outcomes of going down routes with different prioritization. Agile processes excel at elaborating just such scenarios. Every time an alternative presents itself (say in the form of a stake-holder changing direction or changing priorities mid-sprint) the project-manager can juggle the sprint and product backlogs (or master-story-lists) to show how that change might affect implementation of other features downstream. When things become as clear as particular areas of functionality being pushed out to particular (approximate) dates or even outside acceptable timelines, it becomes a lot easier to reconsider and plan accordingly. It makes it easier to think in terms of the project and the team instead of particular agendas or personal beliefs of priorities.

So, the take-away is, one doesn’t need new tools or techniques to resolve problems that arise due to multiple customers or stake-holders or interested parties. Simply taking each plan (based on each person’s idea of priority) and demonstrating what they would do to the overall project deliverables is often enough to get everyone together and on a similar page. Of course, getting the various stake-holders to work as a team and funneling requirements and priorities to the team as one entity is still the ideal situation to be in. Demonstrating the above described projections may help getting the right conversations started.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s