So you’ve optimized Kanban at the team level but true to the Theory of Constraints its uncovered new challenges. Cross team dependencies block progress for one team at the expense of another. Individual backlogs create competing priorities for critical resources. Roadmaps for what to work on next are out of date before you can hit print.
Sounds like you need to expand your Kanban. While this may seem like the solution to all the same problems you had at the team level, lets dig into what patterns are different at the portfolio level. Soloed team expertise, fear and hidden work, lack of visibility across projects, and optimization for one problem without regard for another. But as the system matures you will see status meetings disappear, impromptu gatherings around the board, organizing around the highest priority work and more informed decision making.
You aren’t the first organization to be here, so let's break down what you can expect along the way.
2. @scrumhive
Colleen
Johnson • CEO & Founder ofScatterSpoke
• LeanKanban AccreditedKanban Trainer
• Kanban Coaching Professional
• Former AgileDenver Board of Directors
• Co-chair 2016 & 2017
Mile High Agile Conference
• Member Agile Uprising Board of Directors
• Mama to three amazing kiddos
3. @scrumhive
Kanban has two meanings:
Both meanings are incorporated into the Kanban Method:
Kanban written in Kanji (Chinese characters)
看板means “sign” or “large visual board”
Kanban written in Japanese alphabet,
hiragana,
かんばんmeans signal cards(s)
Kanban Has Two Meanings
4. @scrumhive
Start with what you do
now
Encourage acts of
leadership at all levels
Agree to pursue
evolutionary change02
Initially, respect
existing roles,
responsibilities and
job title
Kanban Principles
01
03
看板
04
12. @scrumhive
Start with the Problem
• What problem are we trying tosolve?
• How can we validate that theseproblems exist?
• What is theurgencyto address them?
• What currentsolutions exist (even work arounds)?
• How will we test this?
Do not jump straight to thesolution, explore pain points, user requests, help desk
logs.
14. @scrumhive
Experiment with Solutions
• How can yousolve their problem in a way thatothers can’t?
• Canyou solutionbe easily replicated?
• What if this problem goes away?
• How will oursolution be unique?
Brainstorm solutions to the users specific problem.
16. @scrumhive
Identify the Activities
• What are thestandard work items that we do every time?
• Who is responsible for completing each item?
• Could westart someof theseactivities earlier?
• How can we avoid silos and handoffs?
Map the life cycleof an epic.
19. @scrumhive
Create Feedback Loops
Fold learning into each phase.
• Use data to make decisions
• When to start based on % complete
• Refine process based on tracking
• Make success metrics clear andvisible
20. @scrumhive
Measuring Outcomes
Set success
metrics up front
Share valueand
outcomes with
the team
Create space
between
features
Makedata
visible and easily
accessible
Gather usage
and adoption
metrics
24. @scrumhive
Don’t Show, Don’t Tell
• The portfolio board only highlights what
people *want* to see and talk about
• Watchfor the handwaving:
• Blockedby XYZ
• Pull off to do XYZ
• Someone asked me to help with this real
quick.
26. @scrumhive
Your going to need approvals for that.
• An abundance of exit policies to account for every
possible thing that could ever happen
• Everyone wants to checkone millionboxes to
show their part is done
31. @scrumhive
Most Relevant Information
• Only need to fully define each feature when
you are ready to pull
• Create space to incorporate learning from
the past
• Give opportunity to pivot or change scope
• Embrace the last responsible moment
37. @scrumhive
Informed Decision Making
• See ALL of the options
• Make more informed decisions about what to
work on next
• Understand the impacts of switching priorities
or adding unplanned work
• See critical cross team dependencies