Defining 'Scaling' Agile, Part 3: Creating Agile Product Development Capabilities
A DZone MVB looks continues her series on how to scale the Agile process, and dicusses the importance of being able to 'replan.'
Join the DZone community and get the full member experience.Join For Free
In the “Scaling” Agile: Part 1, I wrote about cross-functional collaborative teams. The cross-functional collaborative feature team is the basis for “scaling” Agile. In “Scaling” Agile, Part 2, I wrote about programs. I realized I needed another part before my original Part 3. This new Part 3 is about creating Agile product development capabilities.
Here’s a problem I see a lot in organizations who want to “scale” Agile. They plan and replan less often than they should (I am working on a product owner book to help with that problem. It’s next in the queue).
This lack of replanning is a legacy from the more traditional yearly planning.
When organizations planned the project portfolio on a yearly basis, people didn’t perceive a need to plan the products more often. However, with Agile approaches, it’s possible and helpful to plan the project portfolio on a quarterly basis, if not more often. And, in order to replan more often, the teams need to deliver finished features more often.
In Manage Your Project Portfolio, I recommend people start with quarterly planning and move to more frequent planning as the teams get better at delivering value in the form of completed features.
It’s the same idea for product management and product ownership. Product management and product ownership are two different albeit related activities.
Product management manages the product over its lifetime. Product managers meet with customers (so should real UX people so they can create and run experiments, but that’s a different post). Product owners are part of an Agile team and work with that team on a continuous basis.
The continuous basis part is part of what the PO needs to do: create and refine (small) stories, accept stories, and replan the roadmap and the next backlog. I wrote about rolling wave replanning in Consider Rolling Wave Roadmap and Backlog Planning.
Agile approaches allow us to replan. This is particularly helpful when we want to replan the project portfolio and product roadmaps.
Agile approaches allow us to release value on a regular basis, at least as often as every month in my world. Hopefully, every week or two. If you use continuous delivery, you can release value multiple times a day.
The more often you release, the more often the people with strategy responsibilities can manage the project portfolio. Have we done enough for this project for now? If so, feed the team another product. In my world, there are often too many products for the number of teams. We flow work through a team, so the team can move to another product.
The more often the product value team can replan in rolling waves and help the team(s) to deliver value, the more often the managers can change the project portfolio, and the mix of projects the organization can deliver increases.
Agile product development capabilities require:
- Cross-functional collaborative feature teams that deliver value often. The more often a team can deliver, the easier everything else is (this is Part 1 of this series).
- Product owners and their colleagues to replan often. Again, the more the team(s) can deliver value, the easier it is to replan.
- Managers can then make small safe-to-fail bets on the project portfolio. If they realize they will “lose” a bet, then they can replan the project portfolio. Choose another mix of projects to see different values from different products.
That’s what I mean about Agile product development capabilities. If the product development organization can become good at delivering value, the product value team people can replan what they have in the roadmap and backlog. The project portfolio people can replan the project portfolio. The product development effort, writ large, becomes Agile.
If you have questions, please ask in the comments. I’m just starting to explain this in writing. I’m sure I am not as clear as I want to be.
Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.