Here is an approach to Strategic Portfolio Kanban that I have
used with some success.
1. Rolling Wave Planning Allows Planning in
Increments.
I have suggested in the past that SAFe’s Portfolio Kanban
methodology is applicable in almost any Enterprise that needs to manage multiple
teams, but that SAFe’s Agile Release Train (ART) planning methodology may be
too heavy-weight for many situations.
However this raises a question – if you have no ART (Agile
Release Train) planning process, what feedback mechanism is used to keep your
Portfolio Kanban realistic?
And here is my answer, based on experience in recent
engagements: Your Strategic or Portfolio-level plans should be incrementally
reviewed and updated based on real-world feedback around team capacity and team
progress - so use Rolling Wave Planning regularly updated from your Iteration or
Sprint planning process.
In using Rolling Wave Planning remember the basic Agile Tenet
that Estimates come from the team – so the planning process needs to feed a
prioritised Backlog to your teams, and get a realistic work commitment based on
capacity back from your teams. In this respect, it is similar to the ART
planning process.
A rolling wave planning approach differs from an ART planning
approach in that Rolling Wave Planning does not require all teams to run
simultaneous, synchronised planning sessions. Rolling Wave Planning allows you
to update your plan incrementally, rather than commit to the longer-term Release
Plan cycles that an Agile Release Train plan tends to require.
2. Hypothesis Guided Product
Vision.
However Rolling Wave Planning is only one part of the
Portfolio Kanban puzzle. Your planning comes from the Rolling Wave…. But where
does your strategic direction come from? What guides the goals that shape the
plan? SAFe suggests that you need a Vision Statement – but this just begs the
question: What guides your vision?
And here is my answer: The Lean Start-Up approach provides
Hypothesis-driven development (or Experiment Driven Development) as an aid to
guiding your strategic vision.
But the Enterprises we work in are not Start-Ups. How, in an
Enterprise environment, do you generate testable Hypotheses? (Yes, I had to look
up the plural of hypothesis before I wrote that.)
The answer is easier than you might think. In an Enterprise
environment you have two big advantages:
- First you probably have access to numerous sites from which
to choose a few Pilot Sites.
- And second, you probably have a good user base, from which
you can select representative users.
In my current engagement we have a user integrated into the
team (echoes of my old XP days). This product user is NOT the Product Owner.
The product user has been brought in from the field, and is proving to be
invaluable in two ways:
i. The user can describe the reality of how the
product is used (this has proved to be an education for the Product Owner – who
is too high level to have a grasp of the fine-grained details).
ii. The user can talk to other users to develop
hypotheses about where the product might go.
The value of that last point cannot be overstated. If you
want to develop a good hypothesis, don’t just bring users into a product review
and ask them what they think. Instead, ship your product to the first pilot
sites and let it settle in for a while. Then send your user out to talk to the
people using the product. Don’t send a BA or a manager – your user has to be a
peer. The pilot-site users will be much more likely to give extended, honest and
thoughtful responses to a peer – because they know that the peer will soon be
using the product.
You can equip your user with questions, but it has to be a
user that asks them.
When your user comes back into the office, you can start
generating hypotheses. At this time, compare the user findings and hypotheses to
your Product Vision. Adjust Vision as required.
After reviewing your Product Vision, you may need to send the
user back out to the pilot site to validate or further refine the hypotheses
list (keep your list short). Once you have your list of hypotheses developed and
finalised, you are ready to test.
You may not need to write code for your tests – consider
using physical mock-ups, wireframes, or simple what-if scenarios. Remember the
Agile dictum – the simplest thing that works.
Once you have tested your various hypotheses, you can enter
the highest-value ideas into your Portfolio Kanban, where they can be analysed,
assigned a business case, and then prioritised against other ideas to form a
portfolio backlog.
Streaming to the Pipeline
Now stream your Portfolio Backlog into Pipelines of work and
send the Pipeline Backlogs out to your Pipeline Teams to get their estimates and
a commitment to the work. The teams can update estimates, progress and work
commitment using the usual Agile Iteration or Sprint mechanisms.
This allows you to constantly update the plan and look
forward using your Rolling Wave approach.
And there you have it – your Hypothesis-driven Product Vision
drives your Portfolio Kanban, which generates your prioritised backlog, which is
incrementally updated in a Rolling Wave Planning process..... A practical approach to Strategic Kanban using Lean Start-Up
ideas in an Enterprise environment.
