Many people in the agile community promote a product orientation over a project orientation. That’s possible because an organization has product or feature teams. That works until you have more products than teams. That’s when you might still need projects to accomplish everything. If you keep teams together, you can still use projects in a product-oriented organization.
More Work Than Teams
The more the organization embraces experiments, the more often we discover we have more work than teams to do the work. That’s because we see more options of what to consider. Back in Product Roles, Part 1: Product Managers, Product Owners, Business Analysts, I suggested product people ask this question:
Have we done enough for now for this product or service?
If we have done enough for now, we can move to the next product.
I don’t see people ask that question often enough. The backlog doesn’t have enough value to proceed. Yet, because we have this product and we want to focus on it, the team (or teams) continue for too long on this product.
If you hear “We need it all,” you might fall into this trap of doing more even if there’s not enough value in the backlog.
What we want is for the team(s) to take a break on this product and move to the next product. All because we don’t have enough teams for all the products and services we want to offer.
We need to stop working on this product for now. Start another product.
That means we need to sequence the work. (Yes, this is about managing the project portfolio also.)
Those time blocks between this product? You can insert a different product in there, with more value. Guess I need to do another image.
Sequence the Work: Rolling Wave Deliverables at Every Level of Planning
Rolling wave planning works at the team level. It also works at every level in the organization.
I wrote about project-based rolling wave planning in many previous posts.
The image on the left is one way you might think about product-based rolling wave planning:
- Define the strategy for the product: what impact on what customers/users do we want now? That tells us the outcomes we want. I use an impact map for this part.
- Based on the impact map, create a year plan with month-by-month deliverables. Defining deliverables is the difficult part. That’s because it’s easy to talk about work. It’s much more difficult to start with the outcomes, the impact we want to make.
- Use rolling wave planning to plan in detail for the next couple of weeks. Plan in less detail for the next couple of weeks. You now have a two-week to one-month plan. After every week, plan the new “last two” weeks again. You’ve got a one-month plan. (I think of steps 2 and 3 as an inner loop.)
- Ask the question about whether we are done enough every week. Have we achieved the outcomes we want for the customers we want? Do we need to revisit the strategy or the outcomes we want? We discover to deliver at the product level. We do the same at the strategy level. (I think of steps 1 and 4 as the outer loop.)
You now have a way to move from the strategy to the tactics and back again.
All this product planning and replanning takes time. Defining small deliverables? Quite difficult for many POs and teams. Creating the impact map to implement the strategy we want? Also difficult for the product manager and the product value team.
That’s why I recommend a product value team.
All this planning and re-planning is non-trivial. In some ways, this level of planning is easier—you don’t have to plan for an entire year or 18 months and know you’re wrong.
In some ways, this planning and replanning is much more difficult than attempting to plan once for the entire product. A big plan is wrong but you only try to plan once. Instead, if you replan every week, you make micro-adjustments based on what the teams deliver for experiments, for MVPs, for MMFs, for everything.
Successful replanning means the people replanning have all the access they need to the results of the experiments and the feedback from the customers. One person (a PO) can’t do that. A product value team can.
Keep Teams Together, Even for a New Domain
When teams stop working on “their” products, what do they work on? Any other product.
In Manage Your Project Portfolio, I said to flow work through teams. Some teams will find a different project easy to transition to. Some will need research and time to become accustomed to the code and test base. Especially if the code and tests are old and crufty.
My advice: do not wait for the perfect team to become available. If you offer this new product as a challenge and you don’t pressure the team, they will outperform anything you can imagine. They might complain along the way, but they’ll succeed. As long as you allow them to use flow efficiency.
Flow Efficiency Changes the Culture
Flow efficiency promotes a product orientation even in project-based organizations. If you have a flow efficiency mindset, it doesn’t matter if you have a product or project orientation. It matters that you understand the flow of outcomes, the impacts you want to have, through the organization:
- Through the teams at the story level
- Through the roadmaps with deliverables
- Through the project portfolio, as you implement the strategy.
Can we still have projects in a product-oriented organization? Yes.
Does having projects stress the various product roles in any kind of organization? Yes. And, even if we think about a product-based organization, we still have the same or similar problems. An agile approach to product planning and delivery takes talented people time to do well. It’s not the role of just one person.
The next post is about how to think in flow efficiency with component teams.
Series so far:
- Product Roles, Part 1: Product Managers, Product Owners, Business Analysts
- Product Roles, Part 2: The Product Value Team
- Product Roles, Part 3: Product or Feature Teams
- Product Roles, Part 4: Product Orientation and the Role of Projects
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Product Roles, Part 4: Product Orientation and the Role of Projects Opinions expressed by Java Code Geeks contributors are their own. |
