Effective Scrum Product Organizational Patterns Part 2

In part one of this series; I focused more on guidelines for finding and establishing Product Owners in your organization. In this article, I want to focus more on organizational dynamics. And this is probably more focused on larger-scale organizations with product lines, many products, and Product Owners aligned with all of that.

Agile Product Organizational Patterns (continued)

Connecting Hierarchy to Execution

I’ve found that the Product organizations that morph their existing organizational structures into something aligned with Agile / Scrum team execution do a better job of delivery. At the lowest level, that implies a series of Product Owners aligned with Product Backlogs per team. If you’re have more than one team delivering a product, then the Product Owners collaborate amongst themselves so that the work items all integrate into a holistic product.

Figure 1, Scrum of Scrums Hierarchy, courtesy of Mike Cohn & Mountain Goat Software

Think of it this way. Often the Product Organization aligns “behind” the Scrum of Scrum envisioned above. That is, the Scrum of Scrums is a team-based and execution model. However, for each level and team there is a Product-level connection:

1. At the lowest level, there is a Product Owner per team; driving their efforts with a Product Backlog that aligns with the teams skills.
2. At the Scrum of Scrums level, the Product Owners need to collaborate. Often there is a “Lead PO role”, where one of the Product Owners is guiding the aggregate view across the various Backlogs.
3. At the Scrum of Scrums of Scrums level, there is typically a Chief or Uber Product Owner who is connecting higher level business roadmaps and delivery commitments down to the teams’ executing them. They usually track and maintain the balance between perceived commitments and the actually velocity of their Scrum delivery team(s).

A good reference for Scrum of Scrums scaling, and the extensions the Product Owner Organization needs to make to adapt to feeding at-scale teams, is my book. Chapter 17 of Scrum Product Ownership delves into the Scrum of Scrums layering and the product responsibilities.

The essence of this pattern though is organizational transformation. Effective Product organizations re-connect their structures to how their technical teams are now delivering products. Along the way, they learn how to compose, decompose, and recompose backlogs that drive work through their Scrum teams.

Having a Scaling Model

There are several models now available for scaling agility. One of them is the Scaled Agile Framework (or SAFe) by Dean Leffingwell. The other is Disciplined Agile Delivery (or DAD) by Scott Ambler. Bas Vodde and Craig Larman have written a two book series on how to scale agile and scrum teams. And lastly, there is the venerable Scrum of Scrums model of which I’ve leveraged successfully to scale at many organizations.

Independent of the model, Product Ownership at-scale needs some sort of mechanism to move work from the concept and ROI phase (Portfolio) to the execution phase (within Scrum team(s)). Typically, all of the models implement a 3 level flow along these lines:

1. Portfolio Level – Roadmaps, High level Valuation & ROI, Strategy; towards…
2. Project Level – PMO, Project level costing & tracking, Metrics; towards…
3. Team & Release Level – Iterative Execution, Release Train dynamics, Feedback.

Often the upper two tiers implement a pull-based Kanban system for visualizing, maturing and organizing work for the teams. The team level is often focused towards Scrum. An important part of the translation from the Project tier to the Team tier is establishing a Release Train. This would be the tempo that the teams’ plan at for delivering project-level ‘chunks’ to your customers. Dean Leffingwell established the term/model in SAFe, but it’s become relatively pervasive in its use.

Independent of which specific model, effective Product organizations realize how incredibly helpful it is to establish and follow a model similar to those above. It helps in visualizing and flowing work from high level organizational goals towards your teams for execution. It turns out that the clearer the flow, the better the team and business results.

Product Owner – Community of Practice (CoP)

It turns out that User Story writing is a practiced art, as is effective story point estimation, as are many of the other aspects of Product Ownership. The best Product Owner organizations establish a Community of Practice model where their Product Owners gather and share examples, lessons, challenges, and tools they apply within their own teams.

I’ve seen the following activities be part of establishing a CoP for the Product Owner ecosystem:

1. Establishing “reading groups” for ongoing learning
2. Creating an “information portal” (Wiki) where external references and internal knowledge is documented and shared
3. Cross-attending other Product Owner meetings, focusing on Backlog Grooming and Story Writing
4. Comparing User Stories across teams; establishing some consistency in standards and sizing
5. Conducting a periodic meeting where Organizational Product Owners share challenges and create a Backlog for “steering” product agile evolution
6. Creating an Organizational – Product Ownership “Impediment List”

It’s often useful to establish a small core team of thought leaders who are leading and motivating the CoP’s direction and evolution. Typically, Scrum will be used to for this and a backlog is maintained that captures the specific goals for evolving the Community. The Chief / Uber Product Owner are often the Product Owner of this team and helps set the direction for the Community.

Another part of the CoP is surveying the needs of the teams and the Product Owners and supporting training and coaching needs across the organization. Many organizations often try to “go it alone” in their agile transformations and are reluctant to ask for ‘help’, Realizing this, community leadership can bring in training and internal/external coaches to augment the community and accelerate the learning and effectiveness of the organizations agile transformation.

Partnership between (Product + Technology)

Finally, this is one of the greater success patterns in mature agile product organizations. At the top, the two organizations realize that effective agile execution requires a partnership between the Product and Technology. Not only that, they understand that the planning, tracking and reporting aspects of project execution have now shifted to the product-side. There are now “no walls” to throw needs over to a group to plan a response. Both have to work collaboratively not only on the envisioning and requirements side of things, but also on the road-mapping, planning, and delivery aspects.

One way of illustrating this partnership is sharing a story. It comes from Chapter 18 – Other Scaling Model Considerations from ‘Scrum Product Ownership’.

When I was a Director of Development in a traditional Waterfall organization, I did the entire project planning for my development projects. The product organization would throw the roadmaps “over the wall” to my teams for execution. I would do the requirements analysis, project plans, negotiate with the product folks, and then commit to a plan.

In the end, I would throw the software “over the wall” to the quality group for testing & requirement verification. Then we would both throw it back over the wall to product organization for customer delivery.

While we were ostensibly an “organizational team”, our first loyalty was to our functional silo. But this posture fundamentally changes as you move towards an agile organizational transformation.

For example, during my tenure at iContact I found myself vetting our technology organizational development plans earlier and more collaboratively with the Chief Product Owner and the product team. For example, vetting team structures with them, aligning hiring plans with the roadmaps, vetting our skill set strengths & weaknesses and overall team development plans.

This even extended to how we aligned teams towards our products. We just didn’t throw people into teams, throw backlogs together, and then glue them together. No, it was much more thoughtful than that. This is the basic ordering of our thought processes over time:

1. 1. It started with the product roadmap. Understanding what we were trying to accomplish strategically as a business. Looking at it from a technology perspective and trying to contribute (early) to the plans from our perspective.
   2. Next we would look at the overall development and testing organizations, trying to determine numbers, skill-sets, and groupings to best connect teams and skills to product areas in the roadmap. All with an eye to efficient throughput of features.
   3. Part of the above was considering Scrum Master and Product Owner ‘pairs’ for each team. Also, the nature (types of work) that each backlog would feed each team. Were we skill aligned? Consider this close to Feature Team and/or Component team alignment; although we didn’t directly leverage those notions.
   4. We tried hard to give each team an identity or ownership of a complete area of the project or product. Ownership of maintenance, bugs, new development, support, dependencies, architecture, etc. We felt it important for each team to have a strong sense of ownership, which then aligned towards accountability.
   5. We would also consider load balancing; were we balanced to product priorities across the roadmap as much as possible given our team size and capabilities? In these cases, we might create shared responsibilities (backlogs, architecture, etc.) across multiple teams.

In my traditional team experiences, we would never have partnered this way. But we did here within our agile contexts and it worked beautifully.

For those wondering if we lost ourselves in the partnership, I’d say no. We didn’t always ask for permission. And the product team valued our technical leadership capabilities and trusted our judgment. But we were much more collaborative and transparent than I ever was traditionally.

Wrapping Up

I began this two-part series vetting my frustrations with organizations trivializing the Product Owner role and Product Organization restructuring needs when adopting agile. In my experience, this is probably one of the Top 3 problems I encounter while coaching.

Often the excuses flow when discussing this part of the transformation; from we have no additional headcount to we’re too busy to work closely with our technical teams to we want to write everything down because we’re the only ones who know what to do. Many of these connect back to an inherent resistance to change.

What disappoints me the most is how short-sighted all of these excuses are. Many organizations don’t realize just how crucial the Product Owner is to their success, but it’s within a collaborative framework and not an “over the wall” relationship. And beyond that, they fail to realize that it’s a serious role in their agile adoption—one that needs investment, skills, and the time to focus towards the team.

In some small way, I hope I’ve provided some “investment advice” to Product Organizations who are contemplating “going Agile”. It’s certainly not a free ride, but the results are well worth the investment.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.