Learn how the other resources of knowledge will help Scrum Master to play his role more effectively to build a high performing team.

1. MAKING SCRUM
“MORE” EFFECTIVE
WHAT CAN WE LEARN FROM OTHER
BODY OF KNOWLEDGE

2. ABOUT MYSELF
• Sudipta Lahiri (Sudi)
• 25+ years in the industry
• Agile/Lean practitioner (85%)
– ex-Head of Enginieering, Digite
• Led Development of SwiftKanban and SwiftALM products
– ex-Head of Professional Services
– Today, Head of Products
• Agile/Lean Coach/Consultant/Student (15%)
• Organize the LimitedWIP Societies in India
2

3. WHY THIS TALK?
• We have been following the SCRUM practices and doing the
ceremonies…
… but HAS THERE BEEN A FUNDAMENTAL SHIFT?

4. LET’S START WITH
THE BASICS…

5. THE FULL LIFE CYCLE
(FROM PMBOK)
Execut
e
Monitor
Plan
Initiate
Close
#NOPROJECTS
Requirements
Design
Development
Testing
Acceptance

6. SUCCESSFUL DELIVERY NEEDS
(FROM PMBOK)
• Scope Management
• Time Management
• Change Management
• Cost Management
• Quality Management
• Risk Management
• Communication Management
• Human Resource Management
• Partner Management
Agile Methods value the items on the left MORE!

7. OBJECTIVE OF THIS
TALK:
HIGHLIGHT SOME PERSPECTIVES
FROM OTHER BOK

8. PLAN

9. LET’S COVER TWO ASPECTS…
• Forecasting
– Assuming you are asked to give one for a given scope!
• Estimation

10. FORECASTING:
DETERMINISTIC OR PROBABILISTIC?
• MSP is Deterministic
• 99.9% of Management
Reporting is Deterministic… but
is that RIGHT?
• We make assumptions in estimates
• We make assumptions about
complexity
• We make assumptions of skillsets
• We make assumptions of requirement
clarity/volatility
• We make assumptions of risk
• … yet, FORECAST IS DETERMINISTIC!

11. PROBABILISTIC FORECASTING:
MONTECARLO SIMULATION BASED…
• You simulate a set of
parameters
• Run 1000s of simulation runs
• Derive a distribution of Lead
Time with associated %
probability

12. FORECASTING:
ANOTHER ASPECT
• Sometimes, scope/expectation is defined and you have to forecast
schedule/resources, UPFRONT!
• SCRUM is based on a constant throughput/velocity
– We do find min and max; that captures variations not well understood
• What about the variations that we do understand?
– Constant teams with Constant skill profile…
– Does your throughput factor in seasonality?
– A critical lead(s) pulled out… for proposal, for helping another team?

13. FORECASTING:
THE AGILE EVM WAY…
• You need to UPFRONT plan as:
– Map your resource allocation
– May your expected timeline of what
features and stories will get done per
unit time, say monthly
• Yes, you will need to estimate too!
– Compare with actuals to get planned
and get schedule variance
– Get your time sheets; use that as cost
– Compare your planned resource
allocation with actual time to get cost
variance!

14. Original budget 48.57 MM 1020 MD
Original timeline 10
Original Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10
Productivity 100% 100% 100% 100% 100% 100% 100% 100% 100% 100%
Overall Development Resources 14 14 18.5 18.5 18.5 18.5 18.5 18.5 18.5 18.5
Overall ST Resources 3 3 3 3 3 3 3 3 3 3
Overall Development Resources 14 14 18.5 18.5 16.5 18.5 18.5 18.5 18.5 18.5
Overall ST Resources 3 3 3 3 3 3 3 3 3 3
Technical Requirement 1 2 2 4 4 2 2
MMF 1
User Story 1.1 2 2 4 1 1
User Story 1.2 2 2 2 2 2
User Story 1.3 1 1 1 1 1
ST Resources 1.5 1.5 1.5 1 1
MMF2
User Story 2.1 2 2 2 1 1
User Story 2.2 2 2 2 2 2
User Story 2.3 1 1 1.5 1.5 1.5
ST Resources 1.5 1.5 1.5 1 1
MMF3
User Story 3.1 2 2 2 2 2 2 2
ST Resources 1 1 1 1
MMF4
User Story 4.1 2 2 4 5 6 6 6
User Story 4.2 2 2 2 2 2
User Story 4.3 1.5 1.5 1.5 1.5 1.5
ST Resources 1 1 1.5 1.5 1.5
MMF5
User Story 5.1 2 2 4 5 6 6 6
User Story 5.2 2 2 2 2 2
User Story 5.3 1 1 1 1 1
ST Resources 1 1 1.5 1.5 1.5
Total (Current) 17 17 21.5 21.5 19.5 21.5 21.5 21.5 21.5 21.5
Planned value 85 85 107.5 107.5 97.5 107.5 107.5 107.5 107.5 107.5
Cumm. Original Plan Value 85 170 278 385 483 590 698 805 913 1020
Weeks
AGILE EVM: CAPACITY VS TIMELINE
14
Original Wk1 Wk2 Wk3 Wk4 Wk5 Wk6 Wk7 Wk8 Wk9 Wk10
Overall Development
Resources 14 14 18.5 18.5 16.5 18.5 18.5 18.5 18.5 18.5
Overall ST Resources 3 3 3 3 3 3 3 3 3 3
Total (Current) 17 17 21.5 21.5 19.5 21.5 21.5 21.5 21.5 21.5
Cumm. Original Plan
Value 85 170 278 385 483 590 698 805 913 1020
0
200
400
600
800
1000
1200
ManDays
Planned Value
Detailed resource
timeline level
planning at the Story
Level, time
consuming and full of
assumptions...

15. AGILE EVM: TRACKING EV
29-11-2016 15
• If you are using SCRUM with a Task Board, give 100% credit when full
story/feature is done.
• If you are using SCRUM with a Value Stream map
– Two alternatives:
• Give a certain % completion to each stage of the value stream completed on their estimated
size
– For example: Requirement done is 20% value earned, Design completed is 15% value
earned.... OR
• Stick to Agile emphasis on “working software” and give 100% value earned when a card is done
• Aggregate across the Board weekly and you will get the EV trend
• To track Actual Cost:
– Get a weekly resource allocation OR
– Get your TimeSheet data

16. AGILE EVM TRACKING: PV VS EV
29-11-2016 16
20 40
95
149
204
258
313
418
523
628
733
919
1104
1290
1475
1546
1616
1686
1757
1827
0 0 0
50 80 100
150
200
308
350
0
200
400
600
800
1000
1200
1400
1600
1800
2000
wk20wk21wk22wk23wk24wk25wk26wk27wk28wk29wk30wk31wk32wk33wk34wk35wk36wk37wk38wk39
Planned Value
Earned Value
Actual Cost
Schedule
Variance
Cost
Variance

17. EXECUTE:
BACKLOG
GROOMING

18. ESTIMATION
PLANNING POKER GOOD… BUT CONSIDER..
• Flow Efficiency
• Impact of business pressure for
Throughput improvement over
time

19. FLOW EFFICIENCY
(FROM THE KANBAN METHOD)
VALUE ADD (VS) NON-
VALUE ADD
(EVEN) FOR A FLOW BASED
SYSTEM…

20. If you agree that estimation is perhaps
a “questionable”, what alternative
criteria can be used?

21. SO, THINK COST OF DELAY
(PRINCIPLES OF PRODUCT FLOW DEVELOPMENT)
Cost of Starting
Delay
Cost of Starting
Delay
Cost of
Finishing
Delay
Cost of
Finishing
Delay

22. DEMAND SHAPING WITH RISK ASSESSMENT
(FROM ESP, ENTERPRISE SERVICES PLANNING)
DEFINE A RISK/IMPACT
FRAMEWORK
… AND THEN USE IT TO PRIORITIZE!

23. EXECUTE:
REQUIREMENT
DEFINITION

24. REQUIREMENTS DECOMPOSED RIGHT
• What if you don’t get small incremental changes/CRs OR defect fixes?
• What if you get a large BRD/Requirement Document and you need to
start from scratch?
• What if your requirements have been decomposed traditionally?
• We understand INVEST… but how do you go about it?

25. STORY MAPPING
(FROM JEFF PATTON)
• Build a role based
chronological sequence
• Visual and Powerful
• Prioritize your stories,
vertically
• Plan your Release boundaries

27. EXECUTE: DESIGN

28. DESIGN
(FROM LEAN ENGINEERING)
• Do we need a Design activity
separately OR it is part of
Construction?
• Do we need a Design
document?
• Do we need to get a review
done of Design document?
• Concurrent Design
– (vs) Point based Design
• Deferred Commitment
– Don’t decide if you don’t act on it
– Don’t lock yourself too early!

29. EXAMPLE: A DEPENDENCY BOARD
REQUIREMENT WHAT WE DECIDED?

30. EXECUTE:
DEVELOPMENT

31. FROM MULTIPLE BODIES OF
KNOWLEDGE
FROM XP
• Pair Programming
FROM DEVOPS
• CI
– When do you run builds?
– How frequently do you run
builds?
– How long do your builds take?
– How frequently do you leave the
build broken?

32. EXECUTE: TEST

33. AGILE TESTING
THE WRONG WAY…
UI
Services
Unit
Tests
THE RIGHT WAY…
UI
(5%)
Services
(15%)
Unit Tests
(80%)
Manu
al
C
O
S
T
R
O
I

34. EXECUTE:
PACKAGE/RELEASE

35. (FROM THE DEVOPS WORLD)
• Continuous Deployment

36. MONITOR:
KAIZEN

37. CONTINUOUS IMPROVEMENT
RETROSPECTIVES
• A periodic activity…
• Looking back
• Often, in a system that is still
not in control
TOYOTA KATA
• A continuous process…
– One small incremental step at a
time
• Works better when you have a
pattern or rhythm in your work
– Look for flow/uniform cadence

38. VALUE STREAM ANALYSIS
(TASK BOARD VS SEEING THE PROCESS)

39. RISK AND
COMMUNICATION
MANAGEMENT

40. RISK MANAGEMENT:
(AT A TEAM LEVEL)
FROM SAFE BOK…
• A defined activity of PI planning
• Risk Management Strategies
– Resolved, Owned, Accepted,
Mitigated
FROM PMBOK
• Qualitative Risk Management
• Quantitative Risk Management
• Risk Management Strategies:
– Mitigation, Acceptance,
Transference

41. COMMUNICATION MANAGEMENT
(FROM SAFE: TO THE PROGRAM LEVEL)
Dependenc
y Tracking

42. … BUT WE CAN DO MORE!
MULTIPLE POINTS OF
FAILURE…
• Managing stakeholders
– Managing egos and taking
everyone along
• Managing Risks
– Beyond the team/program
KANBAN CADENCES
• … from The Kanban Method
• A set of meetings at defined
frequency to cover defined
objectives!

43. Strategy
Review
Risk
Review
Monthly
Service
Delivery
Review
Bi-WeeklyQuarterly
Kanban
Meeting
Daily
Operations
Review
Monthly
Replenishment/
Commitment
Meeting
Weekly
Delivery
Planning
Meeting
Per delivery cadence
change change
change
change
change
change
change change
change
info
info
info
info
info
info
info
info
info
change info
Doing things better
Focus on Service Delivery
Doing
the
right
things
Getting things done!

44. IN SUMMARY…

45. ACROSS THE LIFE CYCLE, YOU CAN
LEVERAGE FROM OTHER BOK(S)
Execut
e
Monitor
Plan
Initiate
Close
Requirements
Design
Development
Testing
Acceptance

46. THANK YOU FOR YOUR TIME TODAY...
• For any questions or
clarifications, reach me at:
– @sudiptal
– slahiri@digite.com
– lahiri.sudipta@gmail.com
• I share my experiences at:
– http://sudi-thoughts.blogspot.in/
• Join Limited WIP Society
Meetup
46