It seems as if many of my recent client conversations have circled around a singular topic, Business Readiness. The more we’re practicing Agile concepts (Scrum specifically), the more it becomes apparent that given the perfect conditions, adopting Agile is pretty easy. The challenge is that we’re never given the perfect conditions. As a result, much of the coaching and training I do focuses very little on Agile or Scrum. More often it focuses on the other organization complexities that exist within companies today. So today, I’m going to make a pretty bold statement, but I’m doing it in order to make a point.
Teaching a single team Agile concepts is easy, but preventing them from delivering rubbish is hard.
It’s true. Given the perfect conditions, you can teach a single team (or maybe even 3-4 teams) enough to do the basics of Agile sufficiently well in 60 – 90 days. We are seeing that basic team instruction is becoming somewhat of a commodity, however, just adopting Agile practices and mastering Scrum won’t get the benefits that Agile has to offer.
In fact, getting the true benefits of Agile starts with the business, and the idea of business readiness. Are Product Owners even asking for the right thing? Have they aligned all their stakeholder to ensure that there is consensus and understanding in order to prevent unnecessary rework that could have been avoided by a single conversation?
Here are my three suggestions for better business readiness:
- Stop Running, Slow Down! Just because the project seems like a good idea, doesn’t mean it is one. Too many projects get approved and put through the pipeline and organizations are overburdened with too much Work in Progress (WIP).
- Clean the Junk Drawer Often times the scope of new workstreams is weighted down with leftovers from previous projects, nagging production defects, enhancements, and new functionality. When defining scope it is critical to focus on the smallest set of features that, if deployed, would add value for end-users.
- Define a Stakeholder Engagement Strategy Who are the influencers on the effort, and what is the right frequency to engage them to ensure the right level of proactive input? The engagement of these individuals cannot be left to chance. They’re often busy individuals and it takes weeks to get on their calendars. That wait time is a bottleneck for teams and causes waste within the value stream.
The first two in that list are not in scope for today’s exploration, but I do want to offer a few suggestions on #3. A stakeholder engagement strategy is a key element of any successful Product Owner’s game plan. Its accomplished by completing just a few simple steps.
- Step 1: Analyze StakeholdersWho are they, and how close are they to the work?
- Step 2: Define the CadenceHow often should you meet?
- Step 3: Follow-ThroughKeep the discipline for the sessions.
Step 1: Analyze Stakeholders
Who are they, and how close are they to the work?
More often than not a three-tier classification model is sufficient. It all starts with the Product Owner though. The single source of truth to the Agile Team(s). They act as the funnel, aggregating input from all stakeholders in order to ensure there is a single voice guiding the “what” the team works on. Keep in mind, in your organization it may not be realistic for the PO to bear all this burden. Very often it works best to pair a Business Analyst with the PO to help with eliciting information, analyzing results, and aligning the stakeholder group.
- Advisors These are the individuals closest to the work. Apply the same rule-of-thumb used for sizing Agile teams. 7 +/- 2 should be enough to compose a committee of Advisors. In practice, I often see this group include the PO’s direct leadership, someone from user experience, and a representative from architecture (or a tech lead). Other groups to consider would be training and operations support. Product Owners should rely on Advisors to help validate priority, high-level acceptance criteria, and completeness of functionality within the backlog.
- Supporters These individuals are often 2-3 degrees of separation from the work. They may be of a slightly higher leadership level, peers of the Product Owner’s direct leadership, or come from groups within the organization that are more indirectly impacted by the work the team is doing.
- Sponsors Higher levels of leadership often make up this level of stakeholder. They are engaged in order to guide the overall direction of the work the PO is doing, and are very useful in resolving conflicts of opinion among other stakeholders within the group.
When analyzing stakeholders, don’t forget that all types of stakeholders should be considered. Actual end-users, business groups, leaders, and technology specialists should all be evaluated when determining stakeholder classification.
Step 2: Define the Cadence
How often should you meet?
There is no single-right answer to the idea of cadence. The figure in this post outlines an option for you. You can see it prescribes a weekly meeting time. The time each week is the same. The only variable is WHO. Based on the stakeholder map across the three groupings, a different “team” gets together. You may decide a cadence based on meetings every other week are good enough, it’s truly up to you.
In addition to cadence, its also important to determine the focus. Try not to dwell on what the team has already delivered, these sessions are intended to capture proactive input on what the team has coming up in the future. If you’ve watched the recording of the Strategies for Grooming Your Backlog webinar, then you’ve got the idea that this focus is likely 3-4 iterations ahead of where the team is currently working.
Step 3: Follow-Through
Keep the discipline for the sessions.
There is always something to discuss. Don’t cancel the sessions willy-nilly. Keep the habit of the meetings to ensure participation and engagement of the stakeholders. It may be slow to start, but over time you’ll find this invaluable, and the stakeholders will be delighted with their input is manifested in the product demos at the end of each sprint.
I hope this was useful, it’s a passion area of mine, and please share your success stories on these types of stakeholder engagement patterns!