Tom Gilb and Kai Gilb's blog

7 truths about Agile and Scrum that people don't want to hear. Part 3 of 7: Stakeout Stakeholders or Stakeholders will stake you out.

Published by Kai Thomas Gilb323 points  on Tue 28 of Sep., 2010 kaiGilb

Project-Requirements.png (4.34 Kb)

Part 0 of 7 Introduction(external link)
Part 1 of 7 Wrong Focus(external link)
Part 2 of 7 Developer Creativity(external link)
Part 3 of 7 Stakeout Stakeholders(external link)

Part 3 of 7: Stakeout Stakeholders or Stakeholders will stake you out.

Agile theory, teachings and practices mainly* focus on the users and sometimes the customer. They preach use-cases, user stories and the customer-in-the-next-room Type techniques.

  • *I’m sure someone can and will point to projects that takes a wider approach to Stakeholders. I applaud and support that. Please link to sensible information about capturing Complete set of Stakeholders, especially those that target Stakeholders that are not customer and users. I’m in support, not against great Agile implementations. Yet 95% of what I see practiced, written, thought, and preached takes the limited approach to Stakeholders.

Any system being developed has multiple Stakeholders. Stakeholders being the people, groups and things (laws, other systems etc.) that have Requirements related to the system. Stakeholders have a ‘stake’ in the system. Critical Stakeholders can potentially determine success and failure of the system. Stakeholders require something from the system.
StakeholderMap.jpg (41.77 Kb)
Illustration: Stakeholder Map by Suzanne Robertson & James Robertson

To have a fighting chance at understanding the Requirements of a system, identify all critical Stakeholders. Then identify, capture, communicate, develop, deliver and tune their Requirements.

Typically one or a few people initially represents a Stakeholder group and their Requirements. It is unlikely that the representatives can understand the diverse needs of their group, therefore I also recommend, where at all possible, to deliver value directly to the actual Stakeholders, get their feedback, then learn and change based on the feedback. Don't stop at demonstrating working software, rather, early and frequently, deliver real value to real Stakeholders.

Yes, users and customers are critical Stakeholder groups. What I’m missing are the other 20 to 40 Stakeholder groups that all have Requirements for our systems, Stakeholders and Requirements that can and will determine the success or failure of the system being developed.

StakeholderWheel-Mordechai600.gif (276.16 Kb)
Illustration: Here is an example from multi discipline industrial designers and design managers of thinking about multiple Stakeholders and their needs. -Providing Design Strategy for Winning Products and Successful Enterprises
by Mordechai Rotenberg - http://m-rotenberg-design-management.com(external link)

Until the popular agile practices systematically incorporate the Requirements from a Complete set of Stakeholders, they will remain unfit for any but the simplest of projects. Scaling agile without capturing the larger Stakeholder set and their Requirements might somewhat Work when the scaling is in the direction of doing more volume of simple commodity Work. Without capturing the larger Stakeholder set and their Requirements, I doubt agile will find much success in trying to Scale towards larger, Complex, high Quality or competitive products.
Stakeout the Stakeholders or the Stakeholders will stake you out.

To comment(external link), you need to register (instant) and log in (top right).

Yours truly
Kai Gilb

Part 0 of 7 Introduction(external link)
Part 1 of 7 Wrong Focus(external link)
Part 2 of 7 Developer Creativity(external link)
Part 3 of 7 Stakeout Stakeholders(external link)

In the last blog post, Part 2 of 7 Developer Creativity, I posted this challenge,

A challenge to you!

I like to pass on a challenge one of my customers had. He was given a project from Microsoft, to implement a Microsoft built Customer Relationship Management (CRM) system at a telephone operator company. He was the Product Owner. He had about 6 months to roll out the system to all the employees there using CRM systems.

Your challenge: By using Scrum, XP or any other Agile framework or method, how would you write the Product backlog items or the Requirements? I understand if you think I have given you too little information, but give it a go anyway. Just give me some examples of how you would specify the Product Backlog Items in our Blog Comment section, or at least think about it for yourself, later I will tell you what he actually did, and then you can compare.

The challenge got one response from one brave person, thanks ☺

4) As for your challenge, that's simple. Deploy the CRM tool out of the box. Tell the user community that you're going to make it live on Monday. Ask them why they couldn't do their jobs if you did that. The resulting reasons they come up with becomes the backlog. Seriously. That way you aren't getting stupid Wish list Requirements, but rather ones that are much more focused on getting their job done.

Well, what my customer (student), Jens Egil Evensen (jens.egil.evensen at logica dot com), actually did was.
1. Identify the critical Stakeholders.
- Number one was the CTO who was sold the system from Microsoft.

2. Talk to them, and find the value improvements they are hoping for.
- The CTO said (After no compromise questioning of, - why? - what do you want to archive?, where he initially was stuck on the Idea of rolling out the CRM system) they where loosing €9.300.000.- per year in expiring contracts, and they did not know about them Before After the contracts had expired and the customer was lost.

3. Identify Solutions, 4. Divide them into value deliveries, 5. Develop (using Scrum) and

6. Deliver value early.
- After 14 days, he delivered a system (based on the MS CRM system) to the desk of the CTO, that hooked into the telephone operators customer contract system, flagged the outgoing contracts about 30 days Before expiration, and sent a message to the appropriate people to take Action.
From that day onwards, and to this date, the telephone operator was saving about €9.300.000.- every year.

The point being that if Jens had followed any kind of Requirement method as taught and practiced by the Agile community, based on Functions, features, user stories and the like. He would have utterly failed. Jens would not have identified the Stakeholders, he would not have talked to the CTO, he would not have asked the right questions. What he would have done is rolled out a CRM system bit by bit?

Jens went on to roll out the CRM system going through the cycle 1 to 8 (7=Measure, 8=Learn). He was given all Resources (guess why!) and the CRM implementation has since won an award that MS is busy taking credit for ☺


Have fun communicating with your Stakeholders.

Kai Gilb