Want to be agile? Then introduce your stakeholders to each other

Door Patrick Verheij

When I was a young requirements engineer, I learned quickly to listen carefully to what my stakeholders had to say. I learned to watch them do their work and check the consistency of that to what they said they were doing.

Not much later I also discovered that when different stakeholders of the same project come together, some kind of magic happens: they come to realize that there is something to talk about.

Unfortunately, getting stakeholders together and let THEM figure out together how to drive project success, isn’t that common a practice as it seems.

Stakeholders have a certain need for project results. These needs often clash. Not only within large and complex projects, but surprisingly often also in pretty small ones. Business versus IT anyone?

If you use agile practices like the Sprint Review from Scrum, then these stakeholders have plenty of opportunity to talk among themselves and resolve their conflicts. It may need a bit of facilitation, mediation, and some cleaning now and then, but eventually there will be unanimity about priorities of the next outcomes to be delivered.

Alas, some Project Managers and Product Owners alike are still fond of having one-on-ones with their stakeholders. They have nice chats about needs and desires and more often than not, expectations are created. Sometimes these are written down, sometimes they are not.

Now when the project starts running awry, the poo hits the fan. Stakeholders start getting nervous and demand more one-on-ones with the PM/PO. More expectations are created. Actually, a web of conflicting expectations arises.

Eventually the stakeholders start taking matters into their own hands. They bump into each other and realize how their expectations are different. First they blame the PM/PO for being a dork and then they start resolving things. At a pretty big cost of course.

So eventually everything falls into place, but WHY in the name of everything holy does that need to happen only when things start falling apart? Why would anyone take so much risk?

I’d say it’s either lack of experience or just plain ignorance. The Manifesto for Agile Software Development has been around for 16 years now. The principles in there are quite obvious. Just grab a few of them:

  1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software,” which means that a team or project would focus on getting outcomes to the stakeholders as soon as possible.
  2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage,” indicates that teams and projects would do everything they can to understand their stakeholder’s competitive advantage and act on it. Usually this involves getting to know the stakeholders and their COMBINED needs.
  3. “Business people and developers must work together daily throughout the project,” which for me always means that at least some people with a great understanding of stakeholder expectations, preferrably themselves, should collaborate frequently.
  4. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely,” even hints that the people who bring the money for the team/project are involved in such a way that we seriously care for their well-being from being heavily involved.

Know your stakeholders. Care for them. Love them so much that you wish to bring them together.Then love yourself so much that you wish them to help you create the best outcomes. Just remember that IF you receive blame, there is an opportunity to learn. Always.

Patrick Verheij

06 59 443 447

Andere posts

Klik hier