Agile v agility_v4_md

Marc Danziger
CDO, Enterprise Consultant
Agile v. Agility – And Growth

- Your name
- Your company
- Your superpower
Introductions

© Copyright Net Objectives, Inc. All Rights Reserved 3
Marc Danziger
marc.danziger@NetObjectives.com
CDO, Enterprise Consultant
Chief Delivery Officer Marc Danziger is the Chief Delivery Officer of
Net Objectives. With over 20 years of
experience, Marc is a leading practitioner in
project and program management, project
rescue, product portfolio management, SAFe,
Scrum and business architecture. He helps
companies transform to Lean and Agile
enterprises.
He has a Masters in Planning Theory from U.C.
Berkeley where he studied with the originators
of the concepts of Wicked Problems and
Design Patterns.

Lean Management
Project Management
Kanban / Scrum
ATDD / TDD / Design Patterns
technical
ASSESSMENTS
CONSULTING
TRAINING
COACHING
Lean for Executives
Product Portfolio Management
Business Product Owner
Product Owner
Onsite SPC
Leading SAFe
SAFe Architecture
PM/PO

Agile is about practices
s
*Sprint = Iteration
• PM
• POs • POs
• Users
• POs
• Users
• BAs
• PM
• POs
• PM

Agility is about overall control and responsiveness

Agile | Lean Principles
• Take a systems view
• Limit WIP
• Manage batch size
• Build short feedback loops
• Create / support persistent cross functional teams
• Decentralize decision making
• Develop talent

BUSINESS AGILITY
BUSINESS INCREMENTS
PRIORITY AND SEQUENCE
RELEASE PLANNING
Business

MANAGEMENT AGILITY
CONTINUOUS FEED OF BUSINESS VALUE
MANAGING THE FLOW OF WORK
WIP MANAGEMENT
Manage
ment

ADAPTIVE MANAGEMENT
IDENTIFYING IMPEDIMENTS AND DELAY
CONTINUOUS ORGINIZATIONAL IMPROVEMENT
WORKING ON AS WELL AS IN
Manage
ment

TEAM AGILITY
SELF ORGANIZATION
SPEED OF PRODUCING QUALITY
BUSINESS INCREMENTS
Team

TECHNICAL AGILITY
BEST ENGINEERING PRACTICES
TDD, DESIGN PATTERNS, EMERGENT
DESIGN, CONTINUOUS INTEGRATION,
REFACTORING
CONTINUOUS IMPROVEMENT
Team

ENTERPRISE AGILITY
FREQUENT INCREMENTAL
DELIVERY
TIGHT COUPLING OF STRATEGY AND
DELIVERY
RESPONSIVE TO CHANGE
Enterprise
Agility

Lean is based on the idea
that delay is the root
problem.
…let’s discuss

1. Identify the actions taken in the value stream
ApproveRequest Reqts Sign Off
Review Deploy
Analysis
Design Code Test

120 hrs` 280 hrs 240 hrs 8 hrs2 hrs
2. What was the real time from start to finish of the action?
ApproveRequest Reqts Sign Off
Review Deploy
Analysis
Design Code Test
0.5 hrs 160 hrs8 hrs 8 hrs 100 hrs

3. What was the average time working on this vs working on other things?
Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hr
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 600 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 200 hrs

80 hrs320 hrs 80 hrs 320 hrs
80 hrs
160 hrs 80 hrs 80 hrs 80 hrs
4. Identify time between actions
Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hr
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 600 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 200 hrs

80 hrs
5. Identify any loop backs required
65% defective
Repeat 3X
20% rejected
Repeat 1X
Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hr
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 600 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 200 hrs

5. Identify any loop backs required
6. Calculate % time worked
80 hrs
0.5 hrs 160 hrs8 hrs 8 hrs
120 hrs` 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
65% defective
Repeat 3X
20% rejected
Repeat 1X
Avg Time Worked
Total Cycle Time
% time worked = 14.9%
509 hrs
3433 hrs
509 hrs
3433 hrs
Avg Time Worked
Total Cycle Time
Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hr
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 600 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 200 hrs
Approve
.1 / 7.9 hrs
Request
0.5 / 0.0 hrs
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 60 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 / 200 hrs
0.5 hrs 160 hrs8 hrs 8 hrs
120 hrs 280 hrs 240 hrs
100 hrs
8 hrs2 hrs
160 hrs 80 hrs 80 hrs
65% defective
Repeat 3X
20% rejected
Repeat 1X
80 hrs
80 hrs

80 hrs
Approve
0.1 / 7.9 hrs
Request
0.5 / 0.0 hr
Reqts
60 / 100 hrs
Sign Off
1 / 7 hrs
Review
2 / 0 hrs
Deploy
3 / 5 hrs
Analysis
40 / 60 hrs
Design
40 / 80 hrs
Code
80 / 200 hrs
Test
40 /200 hrs
65% defective
Repeat 3X
20% rejected
Repeat 1X
160 hrs 80 hrs 80 hrs
65% defective
Repeat 3X
20% rejected
Repeat 1X
80 hrs
80 hrs
Eliminating
delays between
what you do
Getting better
at what you do
Which gives a better return?
0.5 hrs 8 hrs 8 hrs 100 hrs160 hrs

Delay has three non-obvious causes.
(along with a bunch of obvious ones)
• Batch Size
• Work In Progress
• Multitasking

What’s batch size?

Waitingforapproval
Workingonapproval
ReadyforRequirements
Requirements
Readyforsignoff
ReadyforAnalysis
Analysis
ReadyforDesign
Design
ReadyforReview
Review
ReadyforCode
Code
ReadyforTest
Test
ReadyforDeploy
Deploy
Done
SignOff
.1 60 1 40 40 2 80 40 3
320 8 80 160 320 8 80 100 80 120 160 2 80 280 80 240 80 8
-------------------------------------- Development Team ---------------------------------------- Product Managers --
map value stream to kanban board

What’s multitasking?
…really?
We all live it.
Because we focus on utilization / busyness,
more than getting stuff done.

Costs of Interrupting a Team
What we think will happen What does happen
Current state
Rework
Overhead
Planned Work
Rework
Overhead
Planned Work
New Features
Rework
Overhead
Planned Work
New Features
Extra work
The cost of interrupting a team is not
just the delay of other work, it is the
additional work it creates that would
otherwise not have to be done.

How We Manage People

here’s a
spot!
…and
another!
Operating a product development process near full utilization is an economic disaster.
Don Reinertsen

QUESTION
What is our goal?
That is, what must we make sure we are doing in
order to be successful?
…FINISHING. Nothing else matters.

Source: Standish Group
Study of 2000 projects at 1000 companies
Usage of Features and
Functions in Typical System
WASTE
and the
DELAY OF VALUE

Input
Priority
BUSINESS DISCOVERY BUSINESS DELIVERY
Planning Staging Ready to
Pull
c h u n k i n g s l i c i n g
Decision
High enough business
value?
Decision
Technically feasible,
sufficient ROI?
Iteration
0
Iterative
Development
Incremental
Deployment
Support &
Feedback
Decision
Ready to release?
Decision
Is there capacity?
Define acceptance
criteria and
feature sequence
Build iteratively, deploy
incrementally
Review business value ,
approve, and prioritize
Define value
increments and
sequence
Define
product
backlog
The Value Stream
Doing
“Left of Do”

1 2 3
but incrementing calls for a
fully formed idea
courtesy Jeff Patton
“incrementing” builds a bit at a time...

1 2 3
to allow you to move from
vague idea to realization
courtesy Jeff Patton
“iterating” builds a rough version, validates it,
then slowly builds up quality…

Program: Straight Through Processing
Value Criteria
Improve
Operations
Increase capacity for
handling transactions
Customer
Satisfaction
Shorten resolution time
Reduce Cost Reduce manual processing
cost (headcount)
Synopsis
Customer transactions/requests/issues/problems are handled by process associates in
the customer service area. The volume of transactions which need to be resolved on a
daily basis is nearing the capacity of what can be handled within a 24 hour period; in
addition, resolution time is longer due to the manual effort involved in resolving the
problem.
The company is committed to investing in technology which would automate (no touch)
current manual processes, handle more requests in a shorter amount of time, with a
reduced number of process associates.
Investment
Budget $20M
Payback / ROI 1-3 years

Business Backlog for STP
Program: No touch STP
High Low
Plan Setup Ent. Data Workflow Auto. STP
Bus
Inc
Bus
Inc
Bus
Inc
Bus
Inc
Bus
Inc…
9 months
Plan Setup
Ent. Data
Workflow
Auto. STP
80% 10% 10%
6 months!
4 months
1 month of a dev team’s
vs.
Realizing value 3 months sooner!

UX
Client
Server
DB schema
C
System Evolution vs. Business Evolution
Iterative = Start with what we know, implement some, show the customer, adjust
Incremental= Feature Driven ... Value in short cycles ... Slices vs. Layers
BIG Batch
1
1
small Incremental
VALUE
2 3
MORE Business
VALUE ... OR DONE
C
UX
Client
Server
DB schema
4 ... 50
Iterative Business Slices

Time to add new high
value functionality
Time Spent Fixing Bugs Within and Across Systems
Time lost to building things of less importance
Time Available for New Features
Years in future
Current ??? Years?
%ofcapacity
Maximum capacity of the team

Leadership in Transition to
Lean | Agile (or anything else)
• Transition as work
• Need for exceptional, shared clarity of vision and process about
values and about transition
• Organizational change naturally follows process change
• Wash, rinse, repeat – you’re never finished

There is more value created
with overall alignment that
with local excellence.
- Don Reinertsen
Visualize the result, allow teams
to form their own solutions.

Observations Related To Moral Conflict
No fixed recipes for organization,
communications, tactics, leadership, etc.
Wide freedom for subordinates to exercise
imagination and initiative – yet harmonize
within intent of superior commanders.
Heavy reliance upon moral (human values)
instead of material superiority as basis for
cohesion and ultimate success.
Commanders must create a bond and breadth
of experience based upon trust – not mistrust –
for cohesion.
- John Boyd, “Patterns of Conflict” slide 118

Agile v agility_v4_md

Recommended

Recommended

More Related Content

What's hot

What's hot (16)

Similar to Agile v agility_v4_md

Similar to Agile v agility_v4_md (20)

More from Marc Danziger

More from Marc Danziger (17)

Recently uploaded

Recently uploaded (20)

Agile v agility_v4_md