Generally speaking, people are much better at describing what they think they want than they are at translating an idea into actionable items. However, if their concept is made tangible and then presented for their reaction, people can pretty easily identify what they like or don’t like about it, and where it meets with or deviates from their original thinking.
Agile takes this human quirk into consideration. We work with our stakeholders to first identify what they think they want, and then produce something that reflects our understanding of the stated needs for feedback. We gather the information, update the product, and repeat the steps until each feature meets the agreed Definition of Done. In keeping with agile sprints, this communications loop is quick and methodical to ensure continual forward progress. But, none of it could happen without the stakeholder’s involvement.
Don’t get me wrong, stakeholder involvement doesn’t begin and end with their providing business knowledge and feedback to complement our software expertise. To the contrary, optimal satisfaction can only be achieved in agile if stakeholders get and remain fully engaged. They need to—and have to want to—roll up their sleeves alongside the agile team and commit to the transparency, accountability, and true partnership it takes for product success.
Transparency permeates agile because agile is entirely collaborative.
Collaboration starts right from work inception. We work with the stakeholder to identify the product vision, objectives, and requirements to gain an understanding of what’s wanted. What’s actually needed, on the other hand, is discovered in sprints and refined through ongoing communication.
The product always evolves in full view of the entire group en route to the best solution. Everyone is aware of the accurate, current status of all the work. It is the most efficient way to work, plus it gives stakeholders a larger sense of control since they physically see changes and progress occur within weeks.
What’s more, stakeholders can play with the product as it’s created to validate or refute if the software is truly solving the business problem — all of which is valuable information they can share immediately with the scrum team. There is no working in silos, excessive documentation, delaying feedback to fit a formal meeting structure, or other barriers to total stakeholder satisfaction.
When we bring our agile software development expertise together with our stakeholder’s business knowledge, a powerful interdependency is created that demonstrates the critical importance of stakeholder engagement.
The developers need feedback to create a viable product, while at the same time stakeholders need viable software upon which they can base their feedback. Deciding whether feedback or product should come first is immaterial. The point is that responsibility for the final product and optimal stakeholder satisfaction is shared equally. Everyone has a direct voice in planning and can take pride in ownership, making the scrum team and stakeholders feel more connected which essentially eliminates the “us” and “them” mindset. As an added benefit, working with a happy team is fun and promotes growth and trust.
True agile success depends on discovering product value and delivering it. To do this effectively, stakeholders need to be engaged as partners. Stakeholders are the direct line to the business and users and, as such, they provide unique and beneficial perspectives that ensure every sprint delivers the highest value to solve current business problems.
In the larger sense, relationships equal results. We invest in agile partnerships because they yield a stronger community with effective communications, shared understanding, increased productivity and trust. It all leads to creating real value together.
How do transparency, accountability, and partnerships impact your approach to stakeholder engagement? Let me know by leaving a comment below.