When I think about agile approaches to work, I think about how fast we can change and the cost of those changes. We can change the next decisions about the work because we finish the current work and release it.
Multiple deliverables allow us to change what we do and what we plan next.
That’s why an agile approach with deliverables every day or week doesn’t fit with some kinds of projects, such as events. Events often require an iterative approach, but there’s only one deliverable. (See the lifecycle series for more information.)
Here, I assume you want multiple releases for your product. That means you will make different product-based decisions at different times.
Different decisions require different people and occur at different frequencies. That means we need to consider when to centralize or decentralize decisions.
Consider the Continuum of Feedback Loops and Decisions
Agile teams need to be able to experiment quickly, finishing stories relatively fast. Those teams also change what they do on a frequent basis. That’s why I called it 1-10 days on the continuum (far left).
Product owners might want to change the roadmap as often as every 1-10 days, but I don’t see that often. I more often see POs want to change the roadmap between three and six weeks.
As for the project portfolio? Very few organizations can—or want to—change the project portfolio every month. More often, organizations make decisions on a quarterly basis.
And, for what drives the company, to define the strategy? I rarely see organizations tackle that decision more than once a year.
That’s why I find the continuum above a useful way to discuss who makes which decisions when.
When does centralization make sense? When does decentralization? How much decentralization?
I like to think about the feedback loops as a way to discuss those frequencies. Let’s start with the team.
Decentralize Team-Based Decisions
What about a team’s decisions?
I introduced you to the way I think about feedback loops back in Multiple Short Feedback Loops Support Innovation.
The team makes all the decisions in the blue feedback loops. I like being able to make those decisions every day with one-day stories. You might think I’m nuts, and prefer longer stories. This is why I recommend you Measure Cycle Time, Not Velocity, and consider a Low Tech Way to Forecast. (You don’t have to agree with me as long as you know why you make your decisions.)
How could anyone outside an agile team make these decisions about the backlog and the approach? Every team needs its own agile approach to how they work and how to manage the backlog. (Even if the team doesn’t like what I say.) This is another good reason for teams to determine their own agile approach.
However, the team might not be able to decide on the roadmap by itself. This is where the agile team and the product value team might need to collaborate.
Some Centralization for the Product Roadmap
The longer the time you can tolerate between decisions, the more you can tolerate a more centralized approach to that decision.
If you are a product owner who is also the product manager, you might want a cadence for your decisions. But, you don’t need to centralize anything. You might want to involve the team in your decisions.
What about if you work with a product manager or with several product owners? You’re part of a product value team? In that case, the PO needs to collaborate with the other POs and product manager. The PO can’t make decisions alone—that would leave out other people’s perspectives.
That’s a slightly more centralized decision. The Product Value Team (PVT) makes decisions that the various teams will live with. The PVT focuses all the involved teams on the relevant work.
Because you focus on the product, you only need your team members to make a decision.
However, the project portfolio team needs more centralized decisions, to focus the organization.
Project Portfolio: Yet More Centralized Decisions
Assuming you use an agile approach to all the projects, I recommend reassessing the project portfolio at least once a quarter. Those are the green arrows in this image.
Because the portfolio implements the organization’s strategy, it makes sense to use a more centralized decision-making approach for the portfolio. When you do, you can continue to reassess all the projects against each other.
Notice I didn’t say, “decision-making that takes a long time.” I said centralized.
Centralized Decision-Making for the Strategy
I do recommend senior leaders decide on the organization’s strategy. In normal circumstances, senior leaders might decide once or even twice a year. In a pandemic? You might decide more often.
Why do I recommend a centralized approach to the strategy in a crisis? Because senior leaders define the overarching common goal for the organization. Without that goal, no one can agree on the project portfolio. Or on the roadmaps. Or, worse, on a backlog for a team.
My Guidelines When to Choose
How do you choose when to use a centralized or a decentralized approach to decisions? My guidelines:
- The faster you want the work done, the more you decentralize the decision(s). That’s why teams decide for themselves.
- The more you need to collaborate across the organization, see how few people you need for the decision. Centralize at the “lowest” possible level.
- If the impact is more global and therefore you need to spend more time, the more you might centralize the decision(s).
If you prefer other ideas than feedback loops, let me know.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Feedback Loops Help When to Centralize or Decentralize Product-Based Decisions Opinions expressed by Java Code Geeks contributors are their own. |
