Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Large Scale Kanban for LKCE11

Not just Maintenance - Key points for using Kanban for Large Scale Product Development

Yuval Yeret

on 17 October 2011

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Large Scale Kanban for LKCE11

Kanban Teams?
Classes of Service
in Product Development
Can we commit?
Key points and Practices for using Kanban for Enterprise Product Development
Project Teams
Teams on Demand
Actually, you can mix and match...
Classes of Treatment
When isn't this "Continuous Roadmap" enough?
What if for some features this is not fast enough?
What if one of the Fixed Date features is running late?
Flexibility and ability to swarm depends on Team Formation...
Pull versatile capacity from Projects/Features with Slack
When release /adoption cost is significant, it skews cycle times enough to matter.
Beware the dangers of Timeboxed Commitments
What about commitment to Fixed Price?
Customer Requirements Signoff Process
Analysis - Development Gap
Delivering to a non-Agile client,
using Fixed Price signed off Features
Classes of Treatment
can help manage involvement of
precious Subject Matter Experts
Performance Testers
UI Experts
Security Experts
Project Managers
Testing Experts
SME lagging behind
Welcome to the big league! What does Kanban mean at the portfolio level?
Not all Projects/Initiatives are created Equal
Because not all initiatives are created Equal
Classes of Treatment
Requirements Uncertainty
Technology Uncertainty
Time to Market
Team Pattern
SME Involvement
Cadence Frequency
Team versus Handoffs
Takeaway: Principles of Kanban and Flow
(as well as its emerging properties)
apply to Product Development at all scales

Optimize execution by
Classes of Treatment
Limit the WIP
Visualize Work
Measure and Manage Flow
Spread risk with capacity allocation
Make process policies explicit
Cost of Delay
Focus on scope truly required for the vision
Better Collaboration towards a common goal
"Sacrifice one Person"
Following thru
Typical policy - Be accountable for downstream work until DONE
Deployed, In use, Maintainable by others
Evolving Explicit Policies
What does it mean if Standard Work / Policies stays the Same?
Hint: Visualize, Limit, ...
Manage and Limit Work Size
Funded Active Initiatives
Manage WIP Levels
Measure Cycle and Lead Times
Requires some intelligent aggregation
How does Product/Business fit into the flow?
Challenging your comfort zone
Twitter: @YuvalYeret
Mail: yuval@agilesparks.com
Energizing technology delivery organizations in Israel and Worldwide...
We didn't discuss...
Management Role
Look at the "Toyota Kata"
HW/SW Integration
Synchronizing complex programs
Doesn't mean Kanban not Applicable!
Enterprise Change Management
Making things visible on high level is
already a disruptive change!
— Markus Andrezak (Germany)
IMO the decisions made at different
levels in the org differ in detail, but the
same heuristics apply … if principles are
— John Clifford (United States)
Fractal Kanban
Demand analysis is the backbone of
the Kanban Method and lies at the
basis of decision making. You’ll see that
organizations not studying their demand
are also not implementing Classes of
Service which means they are not able
to allocate against shifting variability
and more likely to end up with a static
Kanban Board.
— Maarten Volders (Belgium)
More at
Energizing a system
WITHOUT deadlines?
what about
Any Snowden fans in the room?
More classes? Work Types?
Patch / Hotfix
Quick, Willing to risk, Limited release
Fit to Budget
Trial / Customer Proof of Concept
Quick, Risk-ok, Debt ok, Pay later...
Low Hanging Fruit
allow only small simple work, expect very fast lead time
Emergent Practices driven by Kanban
Specification by Example / ATDD / BDD
Whole Team Ownership
Continuous Integration/Deployment
Zero Tolerance to Defects
Experiment with Team Structure
Develop T-Shaped People/Teams
Code Reviews
Reduced Release Costs
Faster risk/issue management
Coordination Costs
Total Flexibility
Value of Centralized Resources
Stable Teams - Dynamic Work
Should teams/capacity be allocated to Classes of Service?
Classes of Service
Flow with Fast Feedback
Limit amount of Teams/Tracks
Stimulate Swarming
Surface Versatility Challenges within and across teams
Experts go last!
Single Product Owner/Manager per Team?
Allocate capacity to Business Initiative?
Allocate team to Business Initiative?
Allocate PM to Business Initiative?
Typically Product Management aligned with Project and Team
Treatment Tags
Teams Pull Work
How are Product People mapped to Teams here?
BAs alignment to Teams?
Classes of
Is this another Class of Service?
Classes of Service: a mechanism for typing work items and is used to inform team decisions about prioritizing and swarming.
Will this affect Prioritization/Swarming?
Not necessarily...
Classes of Treatment
disclaimer: that's just my term for it (for now ;-)
Mechanism for typing work to inform team decisions about how to do the work and how to route it internally
Cross-Train at adjacent Processes
Keep tuned for more examples...
Not always necessary!!!
Portfolio/Projects Kanban
Manage Quantitatively
Operations Review
Drive Process Innovation
and Improvement

Taiichi Ohno would say you are a salary thief
Your innovation engine has stalled...
Books you might want to read
Kanban without Kanban
Limit Queues
Done - Build Quality In
Limit Concurrent Agendas
Transition to "Flow" focused iterations
Main visualization is CFD
Unsustainable Change Programs
Kanban-driven Change Programs are more sustainable
Like Aircraft - Change Programs can stall and spin out of control if turning too tight without enough power...
In bigger organizations - more "power"/"energy" is needed...
Multi-Group Synchronization
An adoption scenario
So what do we do?
Adoption Kanban
Limit Adoptions Gap
Multi-Stage Continuous Adoption/Integration
Ask Why people avoid adopting?
Early feedback via key adopter involvement
Backwards Compatibility / Transparency
Support 100K users for TC launch
Bottom line - Teams doing Product Development are also dealing with different kinds of demand, that would benefit from different kind of service.

Can we make it?
When should we start?
1w cycle time
2 cards/day
4 teams
16 cards
No dependencies
Dependencies Network
Who needs Teams???
Disclaimer: Your mileage may vary...
Sustainable Evolution anyone?
Tracking Projects
Fixed Date
Expand/Collapse Feature Lanes Kanban Board
When will we get Feature X?
When will we our OEM Y API be ready for integration?
Will we be able to consolidate the servers on time to avoid renewing hosting fees?
Never commit early unless you know why...
Real Options
Also covers Commitments at Card and Project level in much more depth...
Try... a few key cross-functional Task Forces where feedback is precious - risk, tight integration, stressed schedule
Unadopted Inventory accumulating
Ideal Team Formation
How "Clean" should it be
What route to take
What functions should be involved and how
Set of explicit policies to follow
Tip: Limit the amount of different CoT in use... keep it manageable
Leaders and Asymmetric Investments
Amount of available Real Options we encourage
How many people in one daily?
Can you think of ways you're applying different treatment to work that is of the SAME class of service/demand?
Full transcript