The document discusses the evolution of program management, emphasizing the importance of agile approaches, particularly the Kanban method, as a response to the limitations of traditional planning. It highlights the shift towards lean program management and the necessity of adapting to fast-paced market demands through velocity-based tracking and probabilistic forecasting. Overall, it advocates for a more flexible, efficient approach that prioritizes understanding user needs and improving project delivery.

1. Agile Program
Management
Scaling it “right”
with the Kanban Method!
1
@sudiptal

2. 2
Distinguished Fellow, Kanban University
@sudiptal

3. Your takeaways
(I hope)…
• Understanding Program Management!
• Lean Program Management…
• What Changed
• Getting it done right…
@sudiptal 3

4. What is a Program
• A collection of “projects”
• A collection of “applications” is generally called
a “Portfolio”
• Collection could be based on different dimensions!
• Geography, Customer, Vertical, etc.
@sudiptal 4

5. Why do we do
Program
Management?
Qualitative
Dimension
Account Mining,
Market share Risks,
Stakeholder
Expectation
Management,
Procurement,
Human Resources,
Attrition
Quantitative
dimension
Scope, Cost. Time
Quality, Budget
Capacity and
Resource Planning
Identify issues for Escalation,
Steering Committee
engagement
@sudiptal 5

6. Why the change?
• We cannot figure out the new-age applications/products
• We don’t fully well understand what the market wants exactly
• We don’t fully well understand what user experience works
• We don’t fully well understand what market positioning works
• We need to build fast and get feedback
• Build fast means that it must be small, independent, valuable, testable scope items
• This is specifically true for software development
• Manufacturing, Construction or other industries could PERHAPS do well with
traditional planning and execution
@sudiptal 6

7. Why the
change?
• Traditional planning was based on Estimates:
• We used to spend a lot of time on Estimates
• Had to do detailed Scope Analysis
• Had to do detailed Design
• Make estimates on Resource Availability
and Skills
• Then, derive an Estimate
• This model had high dependency on the
accuracy of Estimates
• Since, this would fail, we would depend on
Contingency and then, all the estimates
working
@sudiptal 7

8. Why the
change?
Not much with reference to the
expectation from Program/Portfolio
Management but…
… the nature of what the Programs
are tracking are widely different!
@sudiptal 8

9. Understanding
Lean Program
Management
• Application of Lean principles
to Program Management…
• So, you would expect:
• Reduced lead times
• Lower inventory and
storage costs
• Decreased overall costs
• Improved productivity
and efficiency
• Greater quality
• Higher customer
satisfaction
• Unfortunately:
• The ecosystem missed
some of the original
objective of what where
the programs for!
• Got everyone
focused to product
delivery
• To some extent, it has
been trivialized the
problem to “Flow”
@sudiptal 9

10. Lean Portfolio
Management (from SAFe)
• Do you have to do SAFe for
Program/Portfolio Management?
• Does not address any of the
qualitative aspects of
Program/Portfolio Management?
@sudiptal 10

11. What changes?
• New age planning CANNOT be based on
Estimates:
• If you don’t know what you need to
build (but just have an idea), what will
you estimate??
• So, we fall back to the next option: Velocity
• Capacity and Resource planning can be done
based on the same
• # of cards/per unit time per unit person
• Concern: How does this work without
consideration of the card size/effort?
• Sprints are of tight duration; a card should
finish in a Sprint
• # of points/per unit time per unit person
• Concern: Why is this estimate fast and
accurate?
• Its relative! Its does not delve into the
details… we poll for a relative size
• # of hours/per unit card
@sudiptal 11

12. How do we do it
right?
Kanban Method has multiple answers…
@sudiptal 12

13. Work flows
in two key
forms…
• Velocity based tracking
• Must have: Groomed stories + Past velocity date
= “Deterministic” Forecast
• SCRUM would work...
• Good to have: Probability based LT forecasting
• Kanban will give you the edge…
Major enhancements, New Projects
• Production Support, Small enhancement, Ops
• Must have: Probability based LT forecasting
• Kanban is a must!
Continuous stream of tickets…
Let us look at them in more detail…
@sudiptal 13

14. Legend:
@sudiptal 14

15. Doing Project/Program management, quantitatively
@sudiptal 15

16. 1. Getting a sense of where are we…
@sudiptal 16

17. 2. Expand that to identify the issue…
@sudiptal 17

18. 3. Quantify your problem!
Scope Spillover = 2 cards
Timeline Spillover = 17 days
@sudiptal 18

19. 3. What options do you have? People dimension…
@sudiptal 19

20. 3. What options do you have? Scope dimension…
The most important thing is to get
a cross-project view of these
quantitative dimensions,
independent of which team, in
which project, located in which
part of the world, is contributing to
it!
In large programs, work is spread
across teams, across locations,
across geographies, across projects
@sudiptal 20

21. We can still get
better…
Velocity driven
forecasting is
deterministic
• Kanban shows that completion forecasts are probabilistic
• Avoid this trap… business does not like probability
• Ask “when do you need it?”
• Adjust the scope using a process like Story Mapping!
@sudiptal 21

22. WIP…
Doing Program Management,
quantitatively for continuous
flow of tickets.…
@sudiptal 22

23. Doing Program
Management,
qualitatively…
• Design a lightweight
Kanban Board like this…
https://www.linkedin.com/pulse/how-use-kanban-boards-project-risks-issues-actions-logs-craig-cherlet/
@sudiptal 23

24. Doing Program Management, qualitatively…
A more scalable implementation for larger Programs…
@sudiptal 24

25. We think of Card level CT…
… but focus on Column level CT!
Column level aging => Card level aging
No WIP on Risks!
@sudiptal 25

26. Thank you...
26