There are two “parts” to Derek’s post.

First he provides a brief history of the practice of  “grooming” and a sample of references – including a Scrum Guide reference.

Then he explores what he calls a Progression Workshop. Here’s the core of what he says about the workshop:

Our progression workshops differ slightly from the story time meeting detailed by Kane Mar and the refinement meeting mentioned in the Scrum Guide.  Counter to Story Time, we don’t invite the entire team. Instead, we have elevated the workshop to a group some have come to know as a .  The group of people within the PO team will vary, depending on the line of business.  Yes, there will be a Product Owner (Product Lead) and facilitator, but from there we’ll include the development lead, testing lead, and an architect.  We’ve found two key challenges when operating at scale. First, is there a well-defined backlog that is ready enough to be consumed by different delivery teams?  Second, is the work being queued up to the delivery teams free and clear of other teams.  That is, have we decomposed it in such a way that we’ve minimized dependencies on other teams? Beyond that, in order to achieve some degree of architectural runway, we continually refactor existing platforms. Architectural changes are not only made incrementally but we require an architect to be present at every progression workshop.

Counter to the Scrum Guide, I’m not going to be proscriptive as to how much capacity the PO Teams do/should commit to progression workshops.  The goal is to have enough work for delivery teams to consume for a few sprints.

When progressing work, we do expect some artifacts to be generated, to contribute to the teams understanding of what will be developed, tested, and delivered. Below is a partial list of potential artifacts.

He then goes on to list a rather long set of potential documents or artifacts that the progression workshop can create.

The point of the progression workshop seems to be, and I’m trying to be fair here, is that at-scale,

• It’s hard (or wasteful) to get the entire “delivery team” together for a backlog refinement meeting, so he’s come up with an approach where a PO team (including architectural folks) primes the work for the teams.
• These teams largely “communicates with the team(s) via documentation
• They also are chartered with decomposing features in such a way as to minimize dependencies and optimize workflow across teams.

And he makes the point that the capacity of the PO team, and the frequency of the progression meetings are driven by the number of ready features/stories for the delivery teams. That is, they need to be looking ahead sufficiently to keep the teams work queues full.

Additional Comment

Mike Cottmeyer made an interesting comment as part of this post. Here it is in its entirety:

I’d recommend that if we are going to continue this conversation, we set some context. The size and scale of the organizations we work with and the level of product complexity in the companies we are trying to help is beyond ‘getting the delivery team involved from the beginning’. That is the problem with these kinds of debates… unless you’ve walked in someone else’s shoes, it’s difficult to have a relevant point of view. Scrum is an interesting theory that only works as described in some contexts. LeSS is describing an idealized end state that cannot be applied out of the box in most of the organization we work in. Scrum as a base package is not scalable. SAFe fundamentally punts on solving the real problem, but can be effective in some large contexts, but will limit agility over time. I cannot emphasize enough here that unless you’ve been on the ground supporting the specific customers we are supporting, it’s tough to have a relevant perspective. There is no theory in what we are talking about, only on the ground pragmatic dealing with reality.

Mike is reacting to some comments challenging the fact that the “delivery teams” are being abstracted away from this early form of backlog refinement. In essence he seems to be saying – our contexts are unique and we’re doing it right, so don’t challenge us.

That’s a fair position, but I want to challenge Mike and Derek anyway.

Agree to Disagree

For full disclosure, I’ve been a fan of Mike Cottmeyer and what’s he’s been doing for quite a long time in at-Scale agile instances. He has quite a lot of agile experience and seems to strike a balance between the “team-side” of agility and the “leadership-side” of agility. Meaning, he walks the line between core agile practices and implementing them in some fairly large, enterprise-level, and somewhat slow to change clients.

He uses words like:

• Context
• Product complexity
• Size and scale
• No theory
• Pragmatism
• Walking in someone else’s shoes

As illustrating that he and his teams are on a unique journey. With that being said, I believe Mike has gone a bit too far here. As agile coaches we need to continuously focus our clients on core agile principles; mostly under the “if not us, then who” clause of sound agile coaching. There are two that immediately come to mind that Derek may be compromising.

Simplicity

This is in terms of everything – tooling, how they organize their agile teams, how they attack their workflows, and how many people they bring to bear operate with silos, hand-offs, etc. We need to be constantly emphasizing lean and agile principles, even when the client is large. I’d actually say, more so when they’re incredibly large.

I was speaking to a fellow agile coach and he shared his current focus with respect to agile at-scale. He said that he’s coaching more de-scaling recently with clients who are overbuilding complex organizational and project team structures in their agile adoption efforts. SAFe is one of the drivers for this, but there are other models. Many of the scaling models, including this approach to backlog grooming, are unfortunately getting away from the simplicity of agile solutions and focusing instead on hierarchical action.

I guess what I’m looking for Derek and Mike to do is to push back against the client drivers and rationale towards complexity, and instead put simplification pressure on their clients in their agile adoption efforts. This leads into my next point, of continuing to place the center of agile transformation on the culture and the teams.

Empowered, Self-Directed Teams

I don’t know how to say this elegantly, but the success of agility within a single team up to the largest Enterprise isn’t centralized within the coaches or the leaders or the hierarchy. The essence of agility is that It’s about the TEAM…first. It’s always been a development team-driven model. And that’s where the successes have come from.

And from my point of view, Backlog Refinement is a team-based activity. Always has been, always should be. It transcends whether we have the time for it or the will to do it. It is THE activity where agile teams consider their work, develop their strategies, and look ahead into their futures. It’s where they have a SAY in their work.

To reduce it to a session where product owners, architects and team leads make fundamental work decisions (folks who are ultimately NOT doing the work) is flat out wrong. It disconnects the teams from the evolution of their work. In other words, I think it undermines their self-direction.

The True Test

Let’s get back to Derek’s point of Backlog Refinement with the team vs. a Progression Workshop with the Product Owner Team.

I think the true test is not whether the coaches like it or recommend it. Nor is it whether the leadership team is comfortable with the meeting and not “wasting the time” of the delivery teams. Or even whether Derek and I think it’s the right or wrong thing to do.

The true test lies WITH the teams.

• Are the delivery teams getting enough of an early warning on feature evolution so that they can effectively guide their designs and product evolution.
• Do the team’s feel empowered and a part of the overall flow of work? Or do they feel like the “committee” is dropping pre-thought work over the wall for them to simply…implement?
• Are the teams’ creativity and innovation being leveraged as the work flows from the Product Owner team to the Delivery Team?
• Does the work produced by the team have minimal rework and does it stand the test of time?

If the answers to any of these questions is no, then I would say that the team is too abstracted from the backlog refinement process and Mike, Derek, their coaching team, and their clients have an impediment.

Wrapping Up

Agile coaching firms need to be wary of missing agile core principles in at-Scale transformations. This is not a theoretical vs. on the ground argument. This is a basic principles point.

While Derek may be operating a sound practice here, he needs to weigh it against the impact to the teams and to core agile principles. Team impact must always be a consideration because ultimately the team is where agile results are realized.

Stay agile my friends,

Bob.