How to construct a Product, Team and Release Goals at scale?

The PO can create multiple product goals; however, only one product goal can be active at a time.  Treat these as intermediate goals that will allow the company to ultimately achieve their strategic goal, along with intermediate goals from other products and agile org teams.  . 

Each sprint has a spring goal what will allow the team to get closer to achieving the current active product goal.  Treat these as immediate tactical goals. 

As each team that is working on this product will have a different sprint goal and will have selected PBIs from the single product backlog that will allow them to meet their sprint goal. 

How does this look

It looks like a problem. It looks like at least 3 months will go by before feedback is obtained for any work that is Done. Empiricism is correspondingly attenuated and Scrum outcomes cannot be expected. Moreover, it looks like this is being normalized.

I'd suggest that transparency is needed over this problem so it can then be acknowledged and dealt with. Avoid the temptation to cast a "view" of this as a solution, or remedy, or as high level expectations. Doing so would cover things up.

Hi Scott,

"only one product goal can be active at a time"

I don't believe that this is feasible in reality when working with 10+ teams. 

Rightly or wrongly we work on at least 3 product goals at any one time. There is an antipattern here, we have 3 month releases which gives us the space.

Hi Ian,



Do you think that the long release is linked to multiple product goals and need to document release goals?



I can see your point, if we delivered every couple of weeks then there would be less need to document what we are trying to do.

I see problems.

Why do you need goals other than a Product Goal and Sprint Goals for each team? Generally speaking, a team's Sprint Goal should help progress toward the Product Goal, but I can see cases where it doesn't directly do so, especially in a scaled environment. You may have one or two teams whose focus for the Sprint may be on something that benefits the product but isn't directly the Product Goal, such as paying down technical debt or other kinds of support and maintenance activities. Your release becomes the set of achieved Sprint Goals since the last release.

I'd question the value in having 10 teams that work on a single product, though. That seems highly inefficient. I'd question if you truly have one product or if the thing that you consider to be your product does way too much. There's not a short-term fix here, but I'd want to look at the definition of the product and if it makes sense. There may be opportunities to descale here and have smaller numbers of teams working on each product.

The 3 month release cycle also seems long, especially if that is your only source of feedback. Are you able to get feedback sooner? Shorter feedback loops can mean that you make visible progress toward the goals and are able to adjust. You don't need releases to get feedback.

Hi, Niall!

In the case that you are issuing, where do you think the focus of improvement should be placed: on how to visualize the goals or on how to reduce the time to release?

Is it not too risky to release only once in each quarter?

Is it not becoming difficult to establish achievable goals because the time to release is so long, the uncertainty high, and therefore you are maybe addressing the symptom and not the root cause?

Do you think that the long release is linked to multiple product goals and need to document release goals?

I suspect it's related to hierarchical, waterfall thinking, and the desire to break goals down, rather than shape them up through empiricism and bottom-up intelligence.

I have never been involved in a Product that required 10 teams to work on it.  I have been involved in a Product Suite that fit that bill.  Are you sure your "Product" isn't a "Product Suite"? 

It may help to revisit your definition of a product.  If are able to break the work into 10 pieces, it seems like you could break it into 10 distinct parts each of which can have it own goals. 

I also agree that a 3 month release cadence seems more reminiscent of waterfall project management than agile software development.  @Ian Mitchell has the right idea. 

I agree with Ian, it's waterfall. 

I'd like to build on what Thomas Owens and Daniel Wilhite said about whether you perhaps have more than one product, or at least suggest that what you have could perhaps alternatively be modelled into domains or value streams that can each be treated as a product...

As distinct units that you theoretically could outsource, build a business around, buy an off-the-shelf solution for, or in other words, where a Product Owner can account for value (whether revenue, or some other impact on customers, users, brand reputation, other stakeholders etc).

 

Things that make me think this is likely are that you have 10 teams; there must be enough going on that someone felt that kind of growth was needed, and furthermore there are multiple simultaneous Product Goals, plus from your question, it sounds as though teams are struggling to connect to these 3 Product Goals. Perhaps there are even more Product Goals, albeit implicit ones.

Where I work, we appear to be on the right track, having used Domain Driven Design (DDD) to define domains around areas of the business, which we've grouped into what in a Scrum context we call products.

It's less than a year since we began this approach, but the need for inter-team dependency has been reduced, and steps have already been taken that are allowing teams to be more autonomous, without causing dependencies, or other problems for other teams.

The work of each team is more closely linked to value, and each team can work to a distinct Product Goal. Right up to the board level, it should be possible to have a conversation about the investment, and the perceived and demonstrable value that is being added in each product.

It's not perfect. The technical dependencies have not disappeared overnight, but the teams are now empowered to start diverging, and by claiming ownership of code that is tied to specific areas of the business, the developers (particularly software engineers) are more confident in refactoring, and when things break, the bugs and questions almost always go to the team that is responsible, and best suited to drive a conversation about how things should work.

Additionally, teams are treading on each others' toes a lot less often than before, even though we added a 4th team, and have continued hiring. When they are impacting each other, they are now defining more explicit (emergent) boundaries, both proactively and in response to problems occurring.

Some other things that I think may indicate that a single product could be better modelled as distinct products:

• Is there a significant learning curve for developers to understand the technical aspects of the product?
• Are different stakeholders demanding the product to goes in distinct, perhaps even competing directions?
• Are there different personas at your customer(s)? Do any of them have specialist needs, or use the product in a way that is different to the others?
• Are management or investors cycling through different strategies every few months? (Something akin to trying to steer an oil tanker as though it's a speedboat)
• Are developers disengaged or disconnected from the business or customer needs? Do they find it hard to really understand these, and challenge the Product Owner in an effective way?
• Are developers or teams already specializing in certain technical areas, or features?
• When something breaks, is there a particular team best suited to fixing it? And if so, does it tend to take time to identify which team that should be?
• Are there multiple Product Owners, or Product Backlogs? Or are there any implicit or explicit agreements about who should fulfil "Product Owner responsibilities" or which team takes a certain part of the Product Backlog?
• Are teams choosing to solve problems in a certain way, because it avoids having to discuss with another team?
• Are developers claiming ownership over parts of the technology? e.g. "that is our ..." / "we own that ..." repository / namespace / table