Defining “Scaling” Agile, Part 3: Creating Agile Product Development Capabilities

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 need another part before my original part 3 :-). This new part 3 is about creating agile product development capabilities.

In Agile and Lean Program Management, I wrote about continuous planning. (I should have called it “continual” but I didn't. Oh well. In the second edition I can do that :-).)

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.

Manage Your Project Portfolio, 2nd editionWhen 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.

This graph to the left is what we hope are the product's capabilities over time. Every project helps us create more capabilities.

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 (I've been calling this the product owner value team) can replan in rolling waves and help the team(s) deliver value more often, the more often the managers can change the project portfolio, the mix of projects the organization can deliver for the number of teams.

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 the will “lose” a bet, replan the project portfolio. Choose another mix of projects to see different value from 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 in the 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.

The entire series:

3 thoughts on “Defining “Scaling” Agile, Part 3: Creating Agile Product Development Capabilities”

  1. Pingback: Dew Drop - June 1, 2017 (#2491) - Morning Dew

    1. Ola, Here’s how I see it:
      1. Someone shepherds the business value of the product over time. That means they work with customers to understand the customer problems and they work with the corporate management to decide when to stop working on this product. I call that person a customer or product manager. That person also creates a high-level product roadmap, with problems to solve and possibly experiments, minimum viable products, the whole nine yards.
      2. Someone breaks those problems into feature sets and creates a low-level product roadmap, maybe for a month or two or three. That person works primarily with the team. They are part of the team. They affiliate with the team, although they work with the product manager. That person is a product owner.
      3. Sometimes, the product owner is the product manager. In that case, there’s another person to work with the team to make sure everyone understands the problem to solve and how to create stories/feature sets to solve the problem. That person is a business analyst, BA.

      In a small organization, the product manager is the product owner is the BA. That person might feel pulled in too many directions to do his or her job well. That’s because they:
      – have to see the organizational strategy
      – translate that into feature sets
      – work with the customer to define the problems
      – work with the team to explain the problems
      – work with the team to create the feature sets and stories
      – work with the team to verify a given story solved a particular problem the way this person represented it from the customer
      – check with the customer to make the solution fixed the customer’s problem(s)

      The strategy and long-term roadmap (6-18 months) is a product manager and product value team problem. Understanding the high-level problems and shepherding the business value of the product at the high-level is a product owner and product value team responsibility.
      The short-term (1-3 months) problem refinement and definition is a product owner problem.

      The smaller the org and the fewer the products, the easier all of this is and you can have a product owner do it all. (Maybe. I need to write a post about that.)
      The larger the org, the larger the product, the fewer product managers and the more teams, and the more we need to separate the responsibilities. However, in an agile org, everyone needs to be part of a team.

      Alternatives for Agile and Lean Roadmapping: Part 5, the Product Value Team discusses a possible approach for a product value team. I clearly need to write more about this to explain ways to make the product owner role possible.

      Thanks for your prompt. Look for another series about the product owner/product manager problem. 🙂

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: