Exec Leadership level workshop

1. September 18, 2019
Lean-Agile
Leadership Workshop
for Executives

2. 2
Working Agreements

3. 3
Agenda
Waterfall vs. Lean-Agile
Agile Product Management 1012
Q&A for Agile Transformation Journey3
Self learning aids: Reference videos, games and tools4
1
We begin with comparing and contrasting our current process (more like waterfall methodology)
vs. the new ways of working with Lean and Agile methodology.
Waterfall vs. Lean-Agile (1 hour)
1. Waterfall (fixed scope) vs. Agile (fixed cost & schedule) iron triangle
2. To adopt “value driven” mindset, we should first look at Culture. Why?
3. How to Make Your Culture Work with Agile by Michael Sahota (10 minutes video)
4. inside-out agility (slides 2-6)
5. Summary slide: focus on Culture first
6. Why Business Agility?
***** Logical break (5 minutes) *****

4. 4
What is Agile?
Agile
“An iterative, incremental and disciplined approach to development of
Products and Services, that emphasizes people, results, collaboration
and responsiveness. It transcends mere practices and techniques.”
“Using fast decision cycles to succeed under conditions of uncertainty
and to create value.”

5. 5
What is Lean?
In simple terms:
Lean = eliminating waste and continuous improvement

6. 6
Waterfall vs. Lean-Agile: Plan Driven vs. Value Driven

7. 7
What does Lean-Agile “Value Driven” Implementation look like?
Lean Principles Implementation in Agile
Eliminate waste Retrospectives, Feedback loops at every iteration
Amplify learning Retrospectives, Feedback loops at every iteration
Decide as late as possible Iteration Planning every 2 weeks
Deliver as fast as possible Short Iterations
Empower the team Intent based Leadership, Team Collaboration
Build integrity in Build Quality In: Continuous Testing & integration
See the whole Cross functional teams, breaking down Silos
Thinking/
Principles
Mindset/
Values
Process/
Framework
Engg
Practices
(kata)

8. 8
To adopt “value driven” mindset, we should first look at Culture. Why?
• Drucker: “Culture eats strategy for breakfast”.
• But if leadership focus should be on strategy, then why Culture/mindset?
• Let’s listen to couple of experts of Culture and Agility
• How to Make Your Culture Work with Agile by Michael Sahota (10 minutes video)
• Inside-out Agility by Pete Beherens (we will refer to slides 2-6)
• Focus on Culture first

9. 9
What kind of Culture You have?
• How to Make
Your Culture
Work with Agile
by Michael Sahota
(10 minutes video)
• What kind of
culture
would you
rather have?
(discussion
for 5 minutes)

10. 10
Growth Question: Why Typical Agility Transformation Journey is not sustainable?

11. 11
Growth Option for sustainable Agility: Lead You Transformation Journey “Inside-Out”

12. 12
Focus on Culture first!
• To adopt
“value driven” mindset,
we begin with
working on our Culture.

13. Why Business Agility Matters?
What is business agility?
An organization’s ability
to maintain competitive
edge in ever changing
and mostly adverse
business conditions, by
becoming & sustaining to
be lean enterprise.
Business agility is not a specific methodology or
even a general framework.
It has nothing to do with Agile, Scrum Lean or
Kanban. Here is a great reference blog:
Why Agile isn’t Delivering Business Agility
Processes & tools are just means to an end
(desired vision and outcomes).
Technical agility can create an effective
outcome with an efficient process, but it can
not guarantee business agility!
Formally, business
agility refers to distinct
qualities that allow
organizations to respond
rapidly to changes in the
internal and external
environment without
losing momentum or
vision.
(source: hrzone.com
HR glossary)
Another formal definition
of Business agility:
the ability of an
organization to sense
changes internally or
externally and respond
accordingly in order to
deliver value to its
customers.
(source: agilealliance.org
Agile glossary)
So for Value driven Mindset with appropriate mix of Culture,
what do we get? Business Agility! That’s the Nirvana for any
company, be it a large enterprise or a small startup!

14. 14
Agenda
Waterfall vs. Lean-Agile
Agile Product Management 1012
Q&A for Agile Transformation Journey3
Self learning aids: Reference videos, games and tools4
1
To get to “Value driven Mindset” with inside-out agility, you need to deal with Product Management,
which in my observation, has been the stepchild of Agile Adoption journeys for a long time.
Agile Product Management 101 (1 hour)
1. Why limit WIP (Work In Progress) at all levels? (multitasking vs. limiting WIP)
2. Prioritization with Journey Maps and Story Maps (delivering on cadence)
3. Agile Product Ownership in a nutshell by Henrik Kniberg
4. Prioritization framework for Scrum (value/risk)
5. Prioritization framework for ScrumBan/Kanban (optional)
***** Logical break (5 minutes) *****

15. 15
Why limit WIP at all levels? (Multi-Tasking vs. Limiting WIP)
Let’s look at the typical work week in the life of our persona “Sam the software Engineer”.
MULTI TASKING Monday Tuesday Wednesday Thursday Friday
8:00 10:00 12:00 2:00 8:00 10:00 12:00 2:00 8:00 10:00 12:00 2:00 8:00 10:00 12:00 2:00 8:00 10:00 12:00 2:00
Task 1 (8hours) DONE
Task 2 (8hours) DONE
Task 3 (8hours) DONE
Task 4 (8hours) DONE
Task 5 (8hours) DONE
If Sam allocates 25% to each 8-hour task, all 5 tasks are “done” at the end of the 5th week:
LIMITING WIP Monday Tuesday Wednesday Thursday Friday
8:00 10:00 12:00 2:00 8:00 10:00 12:00 2:00 8:00 10:00 12:00 2:00 8:00 10:00 12:00 2:00 8:00 10:00 12:00 2:00
Task 1 (8hours) DONE
Task 2 (8hours) DONE
Task 3 (8hours) DONE
Task 4 (8hours) DONE
Task 5 (8hours) DONE
If instead, Sam allocates 100% to each 8-hour task, then all his 5 tasks are “done”
at the end of 4th week, i.e. the first 4 tasks are “done” earlier than the first case:
Studies show a 30% reduction in efficiency when switching tasks
Imagine what
happens when
the enterprise
works like Sam
at it’s product,
portfolio or
service level!
You think Sam
is getting more
done, but all he
is doing is
getting started
on more work
What we need is to think in terms of incremental delivery on cadence instead of everything!
What does it require?

16. 16
Incremental delivery on cadence requires Getting Things Done (GTD)
Regardless of methodology, leadership needs to embrace "Stop Starting, Start Finishing“- GTD trait!
Limiting Work In Progress (WIP) reduces carry-over drag and shortens delivery timelines across entire product, portfolio
or service! Then only incremental delivery on cadence is feasible!
“Stop Starting, Start Finishing” in action on the team board (regardless of methodology): Visualize the work!

17. 17
Visualize the work: even process improvement related work!

18. 18
Incremental delivery on cadence– Begin with the End in Mind!
Plot that end state with Journey Maps and User Story Maps. You will be visualizing product portfolio or service
level or even strategy level work this way! This indicates that you are beginning to “Inspect and Adopt” with the
fuzzy nature of complex adaptive system called marketplace!
Begin with the End in Mind also means:
Embrace value based mindset with “Why->how->what” (See Simon Sinek’s talks on leadership or start with why).
Let’s look at examples of User Personas, Journey map and User Story Map.

19. 19
Examples of User Personas

20. 20
Journey Map– Begin with the Customer in Mind!
Plot that customer point of view of the end state with Journey Map, based on the User Personas known.
Let’s look at example of Journey Map for the 3 User Persona examples:
1
Student
(with Parent)
2
Test
Device
Log-in
PreACT
3
Register
Hi Shayla!!
View my
Repor ts
Explore
(ACT Profile)
For the
PreACT!!
4
Dates, Time, & Location
Accommodations
Rent Device
Review and Pay
EOS Opt-in
Save
Test Device
Registering for the PreACT
Cancel
5 Pay Online
Receive
ticket
6 Student is READY!

21. 21
User Story Map: Begin With End In Mind
• Planning a product, even an increment of product functionality begins with User Story Mapping
• Align epics/stories/tasks as per user activity (2nd line)– helps with grouping features (1st line) toward the activity
• High value items at the top and low value items at the bottom: MoSCoW (Must, Should, Could, Would have)
• Epics/stories/tasks (Product/Service Backlog) categorized by Releases (in the form of “Release Backlog”)
• Incrementally realize the Product Goals
• Let’s look at couple of Examples from our domain now
optionality
necessary
less
optional
more
optional
MVP (Minimum Viable Product): Must Have
Release 2: Should Have
Release 3: Could Have, Would Have

22. 22
User Story Maps- couple of examples from Insurance domain
• use case scenario 1
• Persona: Millennial Sam
• Scenario: Millennial Sam uses mobile product to purchase travel insurance policy
Payment
Processing
may be later,
once
Millennials
like MVP in
targeted user
tests!

23. 23
User Story Maps- Exercise for Insurance domain
• use case scenario 2
• Personas:
• Call Center rep Anthony, or
• Self serv option for Sam (Millennial persona)
• Scenario: Web/Mobile product to maintain (“UD” or the CRUD) of plans purchased

24. 24
How to Prioritize Stories: MoSCoW Principle as an option
MoSCoW
– Prioritizes stories in four categories
Must Have - Stories that must be included in the project delivery time-box for the project success
Should Have - Stories not critical but should be included if at all possible
Could Have - Less critical but nice to have stories
Won’t Have - Least critical and lowest payback items
• Appropriate mix of stories in each category can be implemented for a release/sprint
• Example 50% can be Must have, 30% Should have, 15% Could have and 5% Wont have

25. 25
User Story Map: Another Example of Scenario/Workflow level Story Map

26. 26
Example of Product/Strategy level User Story Map
Plot that end strategy with User Story Maps at strategy level.
User Story map at product/portfolio/service strategy level looks like this, showing products/services/business lines
instead of activities/scenarios or steps in a scenario:

27. 27
Product Owner Role
Agile Product Ownership in a nutshell
by
Henrik Kniberg

28. 28
Product/Service Backlog Management - Priority Drives the Planning
Iteration / Sprint
Release
Priority
High
Low
Roadmap
Value
Risk
Cost
Knowledge

29. 29
How to Prioritize Stories: Risk Analysis as the other option
High Risk
Low Value
High Risk
High Value
Low Risk
Low Value
Low Risk
High Value
Value
Risk
Low
High
High
Avoid Do first
Do Last Do second
Value
Risk
Low
High
High
To optimally prioritize feature it is important to consider both risk and value
Business Dimensions
 The desirability of the story to a broad base of users or customers
 The desirability of the story to a small number of important users or
customers
 The cohesiveness and ordering of the stories in order to deliver the
release end-goals
 Business seeks for advice from the technical team but if there is
disagreement, Business might still push for the feature
Technical Dimensions
 Technical Complexity
 Technical Feasibility
 The technical risk that the story cannot be completed as
desired
 The impact the story will have on other stories if
deferred (consider high risk story first)

30. 30
Value HighLow
Risk
High
• New Mobile Product
• Mobile app for maintenance
• Corporate Product
• Voice and Chat Bot
• Demand Generation-VC
• Analytics Dashboard
• Performance Evaluation System
• TMQ 3.0
• Customer Loyalty Program
• Benefits Estimator
• Policy advisor “Help me Choose”
• Website translation-affiliate
• Video content- frontad
• IMG REST API conversion

31. 31
Continuous delivery regardless of cadence requires Pull System (Lean / Kanban)
So far, we talked about Incremental delivery with cadence, let’s now look at continuous delivery in the modern
world of Kanban-land.
“Stop Starting, Start Finishing” is also known as the Kanban mantra: Visualize the capacity to do work!
Prioritization in Lean / Kanban is done differently than Agile / Scrum. There is always one priority in the
Kanban-land: the one you are currently working on, and nothing else! You got it! Stop starting, start finishing!
• Work type classification-based priority:
E.g. CTO wants to allocate 10% to Innovation first, then 30% to defects & tech debt before 60% NPD work!
E.g. Airlines allocate Business/Product/service lines in terms of mileage plans, seating scheme and so on…
• Class-based priority: Manufacturing world of “class of service” works in service based knowledge work too!
“Run” queue below has: Expedite, Fixed, Standard and Intangible

32. 32
Agenda
Waterfall vs. Lean-Agile
Agile Product Management 1012
Q&A for Agile Transformation Journey3
Self learning aids: Reference videos, games and tools4
1
Q&A for Agile Transformation Journey (1.5 to 2 hours)
1. Visual board with projects queue and “Gantt chart” as queue:
What does Gantt Chart for “high risk, high value” (say Q1 2020) projects look like
a) to discuss and pre-populate the risk/value quadrants with (say Q1-2020) projects
b) to do the same with a Gantt Chart for those (ToDo).
The earlier one (a) will generate discussions about what not to do, and the later one (b) will generate discussions on why.
Focus on “need by” (journey map level) date instead of “ship by” (story map level) date since we do not know capacity to do that work
i.e. when we can ship what. c) Show Gantt chart view and table view from Wrike for “High Value” projects (In order of High/Low risk)
2. What process framework works for which project?
Process evaluator tool: (45 minutes)
 Overview: How we selected Scrum, ScrumBan or Kanban for your team
 Compare and Contrast prepopulated 3-4 projects and evaluated framework (Scrum, ScrumBan or Kanban, and neither i.e.
waterfall)
3. We may need more time for interaction on problems and issues at their level... e.g. rework, lack of innovation, etc...
Perhaps we can do this as future session.

33. 33
Agenda
Waterfall vs. Lean-Agile
Agile Product Management 1012
Q&A for Agile Transformation Journey3
Self learning aids: Reference videos, games and tools4
1
Self learning aids: Reference videos, games and tools (1 hour)
1. Changing role of functional manager
•The Surprising Truth About What Motivates Us video for 10 minutes by Dan Pink
•"Greatness" video for 10 minutes by David Marquet
2. Training with Gamification (Chocolate Lego Scrum game, by Dana Pylayeva)
3. Penny game (15 minutes game)
•Two 5-minute short rounds that make participants internalize
the 5 lean principles by the end of the 2nd round
•5 minutes to harvest 5 Lean principles: value, value stream,
(product development) flow, pull, and perfection (w/ continuous improvement)
4. Process evaluator tool: (45 minutes)
1.Compare and Contrast Scrum, ScrumBan and Kanban
2.How to select Scrum, ScrumBan or Kanban for your team

34. 34
Training with Gamification

35. 35
Exercise: The Penny Game
Round 1:
• Each person flips all pennies, one at a
time
• Pass all the pennies to the next person
when you are done
• The time keeper will record the total time
it takes everyone to flip all coins

36. 36
Exercise: The Penny Game (Continued)
Round 2:
• Flip each penny one at a time
• Pass each penny to the next person one at
a time
• The time keeper will record the total time it
takes everyone to flip all coins

37. Process Framework Evaluator –
An Example Questionnaire
Questions Explanation
Planning:
Despite the PO trying to do so, is it impossible to lock down the scope for your chosen timebox?
Do you have more than 25% scope churn during the chosen timebox?
Scrum: Scrum works best when requirements are stable for the duration of the Sprint so that the team can commit to their
delivery.
Kanban: Some scope change can be accommodated. By dropping the fixed timebox, Kanban can allow teams to adapt more easily
to quickly changing priorities.
Scrumban: Iteration planning is done at a regular interval, with the goal of planning is to fill the slots available - not fill all of the
slots, and certainly not to determine the number of slots.
Decomposition:
Even after trying your best, is it impossible to break features into incremental pieces of value to be
delivered within the chosen timebox?
Both Scrum and Kanban work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can
help new teams recognize deficiencies (work not completed at the end of the sprint) and adapt (retrospective).
Scrumban: Can you decompose work to lock scope for the timboxed duration?
Estimation:
Is it hard or impossible for the team to size the work in the chosen timebox?
Does estimation take more than 3 hours?
Kanban: Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items. Work should be
comprised of similarly sized activities for Kanban.
Scrum: Scrum absolutely requires that all work be estimated so that the team can commit to the sprint.
Scrumban: Scrumban does not require estimation.
Responsiveness:
Is your top priority to optimize responsiveness to customer needs?
Must work begin in the current timebox (cannot wait until the next one)?
Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity.
Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the
potential cost of productivity.
Predictability & Productivity:
Is your top priority predictability and productivity for larger projects?
You can achieve predictability and a high level of productivity using any agile framework.
Scrum provides more guidance on how to handle release planning and progress tracking so is preferable for new teams.
Process Oriented Culture:
Does your team culture demand a higher degree of process ceremonies?
Although Scrum has fewer ceremonies and artifacts than many other methodologies, it has more than Kanban and can more
easily be integrated into a culture requiring them.
Shared Team Members:
Do you share engineers with other teams? Does your team lack all the required skills to complete
the work?
Scrum: Scrum teams work best when they do not have dependencies on people outside of the team
.
Kanban: With Kanban, others can see when there is work for them to do and pick it up at that time.
Variety in work (complexity & size):
Are your work items of approximately similar size & complexity?
Both Scrum and Kanban work very well with similar sized work items.
However, in Kanban the variability between different sized items makes it difficult to adhere to SLAs.
Source: Steve Sanoff

38. Thank You