Karmængine

A lot is written about the three main roles (or only roles, as some might have it) in scrum. Here are my definitions:

1. Product Owner – The product owner is the filtration and feeder system for the machine, which inputs ideas and outputs a product.
2. Scrum Master – The safety valve on the machine. Can manage the internal pressure.
3. Developer – a working component in the machine, a processor. One who does the actual development.

But, I’d like to touch on another role, the stakeholder.

The stakeholder may be the real owner of the product. He is the person the product is created for. He is the person with the ‘vision’ of the product.

And, the stakeholder has responsibilities. He (or she) is not just a boffin at the end of the phone.

The stakeholder should:

• Know what he wants from the product.
• Know when he wants the product to be completed.
• Be able to outline all major features of the product.
• Be available for the Product Owner to discuss the product often.
• Represent or actually be be the user of the product.

The whole development of the project can break when the stakeholder doesn’t meet these requirements.

Let’s examine each point and assume we have broken it:

• The stakeholder doesn’t know what he wants from the product. In this case we end up wasting development time on a product which goes in the wrong direction. We might create something usable and meeting the basic requirements, but was the real requirements become clearer, more and more work will need to be done to pull the project back on track. It may require starting from scratch. It is very unlikely that the team will deliver exactly what’s needed.
• The stakeholder doesn’t know when the product needs to be delivered. Well, the immediate thought is that this is a good thing. That it means the development can proceed at a leisurely pace. This is almost always wrong. What usually happens is that while the stakeholders are mulling over the goals of the project, they have ‘already told you about it’ and expect that work is already proceeding. Then when they come up with a deadline, it will be shorter than expected, due to this mulling and buggering about time. This causes a panic and can put the team under pressure, resulting in a low quality product.
• The stakeholder cannot outline the major features of the product. This is a major problem. What is developed? If it’s left to the PO and the rest of the team to decide, the product will end up satisfying only them. It will not satisfy the stakeholder. In this case it’s much better to put the brakes on and string up the stakeholder until he tells you what he needs from the product.
• The stakeholder is rarely available to discuss the product with the PO. If the stakeholder is the type of ‘hands off’ person who does not keep in touch with the PO or the progress of the product, the product will start heading in the wrong direction. Stakeholders have an ugly habit of changing their minds every time you speak with them. They can be influenced by even the subtle flapping of a butterfly’s wings on a planet millions of light-years away. If they can’t communicate their mind changes to the PO, the product delivered will be not what the stakeholder was expecting, and therefore a disaster.
• The stakeholder doesn’t use the product, nor represent the users of it. Ridiculously, this can happen. And if it does, you’re making a product blindly. The stakeholder will probably accept whatever you churn out, but beware that when the users come back with their tsunami of complaints, it’s the PO who lying on the beach, not the stakeholder. I could put the good ole iron fist down here and say “Don’t ever create a product for a rogue stakeholder!” Tell them to shove it. Outsource it. Bypass him if necessary. Get your own understanding of what the users need by communicating directly with them.

Hopefully this gives some understanding of the ‘role’ of stakeholder in Scrum. There seems to be a lack of information about them on the net so far.

Lastly, I would say that if you’re the PO, you’re probably liable to the stakeholder. Don’t let him put you under his thumb. If he throws you a curveball, catch it, and shove it in his face.