DevOps/Flow workshop for agile india 2015

Understanding and
Implementing DevOps
Flow
Yuval Yeret
AgileSparks CTO
yuval@agilesparks.com
@yuvalyeret on twitter

Ongoing
Production /
Done
Roadmap Agile
Development
& Testing
Release
Activities
Done Ongoing DoneOngoing
Release
Backlog /
Product
Requirements
Done
Ongoing
Deployment
Done
A
B
C
D
E
F
H
J
G
K
L
M
I
Agile Development
N
O
P
Q
R
s
T
U
V
V1V2V3
Continuous
Integration

• How frequently are you deploying to
production?
On demand –
multiple times
a day/week
Between once a
week and once a
month
Between once a month and
once every 6 months
Less frequent than every 6 months

What is your Change Lead Time - How long does it take for a small
change to go all the way from start to production?
<1 hour
<1 day
<1 week
<1 month
<6 months
>6 months
DevOps
Continuous
Delivery
Elite

Is this your workplace?
http://www.youtube.com/watch?v=FGfplQ1FUFs

“There are very few secrets
out there anymore.
The only competitive
advantage becomes speed.
Organizations need to keep
embracing innovation and
new technology models.
At the end of the day, it’s
about getting from point A to
point B quicker than
everybody else.”
Rollin Ford, CIO, Wal-Mart
http://www.slideshare.net/abbielundberg/cio-dilemma

DevOps/Flow workshop for agile india 2015

“I call this the IT downward
spiral”
Gene Kim
http://itrevolution.com/construction-phoenix-project-and-selling-devops-downward-spiral/

The IT Applications Development and
Maintenance Expectations &
Landscape
Throughput/Value
Speed
Availability/Uptime
Cost

Aiming to break the legacy conflict between Dev & Ops by leveraging
lean/agile thinking/practices at a wider scope than just the
development
: http://devops.com/features/devops-killed-developer-star

0
1
2
3
4
5
6
7
8
9
10
Delivering effective
throughput for our size
Provide Visibility -‐ minimum
surprises to our stakeholders
Engaging/Motivating our
people
Improving how we do things
on an ongoing basis
Be confident in our process
Be flexible/fast TTM -‐ be
able to deal with changing
priorities/requirements
effectively
Be trusted by our
stakeholders/partners
Be versatile -‐ so we can work
according to Business
priorities not R&D skills
Deliver good quality -‐
minimum complaints and
rework due to defects
Work in a sustainable pace -‐
reasonable balanced load
over time without churning
our people or our product
Value -‐ Deliver useful
software that maximizes
customer satisfaction and
business success
What are YOU looking to improve?

Reaching Goals in Complex Systems
Today, we are
here
Tomorrow, we
want to be there
Our target
destination
The way as we
envision our path
toward reaching
our goal

Reaching Goals in Complex Systems
The way as we we
ended up getting
there

After we build it, Will they come?????
Will they Stay?????
The faster the market moves, the more affected we are by
trends and competition, the harder it is to really know for
sure up front.

We live in uncertain times…
Where are your projects ?
http://www.derailleurconsulting.com/blog/complexity-and-noise-in-systems-development-projects

Try this: Create a Stacey Matrix for
YOUR projects/products

Sabre vs. Mig 15
Mikoyan-Gurevich
MiG-15
North American F-86
Sabre

Sabre vs. Mig 15
Kill Ratio
6:1

The Improvement Loop
Colonel John
Boyd
OBSER
VE
ORIENTAT
E
DECIDE
ACT

The Improvement Loop
Continuous Improvement is GREATER than Might
If you are spinning through more OODA loops than your enemy, you
will win
Colonel James
Boyd

http://www.slideshare.net/jurgenappelo/management-
30-in-50-minutes

Accelerate Time to Market &
Improve Productivity
Taiichi Ohno
Toyota

Ongoing
To Do Agile
Development
& Testing
Automated
Delivery
Auto
Deployment
Agile
Planning
Done Ongoing Done
B
C
F
H
J
G
L
I
DevOps Vision
O
P
Q
R
s
T
U
V
Frequent Feature Delivery
Continuous
Integration
Predictable, Repeatable,
Non-Event
U
Powered by
strong automation
Production

Ongoing
To Do Agile
Development
& Testing
Automated
Delivery
Auto
Deployment
Agile
Planning
Done Ongoing Done
B
C
F
H
J
G
L
I
DevOps Vision
O
P
Q
R
s
T
U
V
Frequent Feature Delivery
Continuous Deployment
as part of development cycle
Predictable, Repeatable,
Non-Event
U
Powered by
strong automation
Production
The real

As of 2014 - Enterprises are going DevOps
as well...
*As reported by various DevOps tools/services vendors we are working with
Oct 21-23, 2014, SF
http://devopsenterprise.io

Firms with high-performing IT
orgs are winning
more likely to
exceed
profitability,
market share
& productivity
goals
Puppet Labs Webinar 2014 State of DevOps
2x higher market
capitalization
growth over 3
years*
50%

High-performing IT Orgs are
More Agile
30x 8,000x
more frequent
deployments
faster lead times
than their peers

High-performing IT Orgs are
More Reliable
2x 12x
the change
success rate
faster mean time to
recover (MTTR)

So, which organizations/contexts
can benefit from DevOps?
Return
Investment

But when the
typical Enterprise
meets DevOps…
See Kent Beck’s idea as described by Markus Gartner at http://www.shino.de/2010/11/04/software-g-forces-the-effects-of-acceleration/

The 3 ways
towards DevOps
Gene Kim
http://itrevolution.com/the-three-ways-principles-
underpinning-devops/

Ongoing
To Do Agile
Development
& Testing
Delivery
Deployment
Agile
Planning
Done Ongoing Done
B
C
F
H
J
G
L
I
Use Kanban to work towards Biz-Dev-Test-Ops Flow
O
P
Q
R
s
T
UV
More Frequent Feature Delivery
Continuous
Integration
U
Production

2009-08-29
orem ipsum dolor sit amet, nse ctetur adi pis
cing elit nisl
2009-09-01
orem ipsum dolor sit amet, co nse ctetur adi
pis cing elit nisl
2009-09-02
orem ipsum dolor sit amet, nse ctetur adi pis
elit nisl
Analysis Development Acceptance ProdNext
Definition of Done:
• Customer accepted
• Ready for production
Ongoing Done
Definition of Done:
• Code clean & checked in on trunk
• Integrated & regression tested
• Running on UAT environment
Ongoing DoneOngoing Done
Definition of Done:
• Goal is clear
• First tasks defined
• Story split (if necessary)
2 3 3 2
Feature / story
= completed
= blocked
= who is doing this right
now
2009-08-20 2009-09-30
(description)
• Panicfeatures
(should be swarmed and kept moving.
Interrupt other work and break WIP
limits as necessary)
• Priority features
• Hard deadline features
(only if deadline is at risk)
• Oldest features
2009-09-03
ipsum dolor sit amet, co nse ctetur adi piscing elit nisl
2009-09-02
orem ipsum dolor sit amet, co nse
2009-08-27
orem ipsum dolor sit amet, ctetur adi pis cing
elit nisl
2009-08-27
orem ipsum dolor sit amet, adi pis cing elit
nisl
2009-08-20
orem olor sit amet, co nse ctetur adi pis cing
elit nisl
2009-08-30
orem ipsum dolor sit amet, co adi pis cing
elit nisl
2009-09-08
2009-08-20
orem ipsum dolor sit amet, co nse ctetur adi
pis cing elit nisl
2009-08-25
2009-08-22
orem ipsum dolor sit amet, co
2009-08-25
orem ipsum dolor sit ctetur adi pis cing elit
nisl
Task / defect
Hard deadline
(if applicable)
Date when added to board
orem ipsum dolor sit amet, co nse ctetur
(description)
(description)
(description)
Why
(description)
Who is analyzing / testing right
now
= priority
= panic
What to pull first
xxxx kjd dj d xxx
Kanban kick-start example
Henrik Kniberg www.crisp.se/kanban/example
version 1.2
2009-11-16
(description)
2009-08-26
orem adi pis cing elit nisl
=task =defect
43

Lower WIP è More collaboration.
Can you explain why?

Summary of Kanban
• Visualize – Understand your system
• Limit WIP – Stop starting start Finishing
• Manage Flow
• Make Process Policies Explicit – to enable
empowerment/delegation to teams and people
• Implement Feedback Loops – Own your process
• Improve Collaboratively, Evolve Experimentally
(using models/scientific method)
45

Agile Team board & flow
DevOps E2E board & flow

0
20
40
60
80
100
120
1 2 3 4 5 6 7 8 9 10
Time
Burndown / Burnup
How do we Visualize the work status
in more depth?
0
20
40
60
80
100
120
1 2 3 4 5 6 7 8 9 10
TOD
O Work in
Process
(WIP)
Done
48

The Cumulative Flow Diagram
• Introduced in Lean Product Development by Don Reinertsen and David
Anderson
• Visualize where the Features/Stories are in the workflow across time
0
20
40
60
80
100
120
1 2 3 4 5 6 7 8 9 10
TOD
O Work in
Process
(WIP)
Done
49

TO DO IN PROGRESS DONE
Elad
Inbar
Elad
Mushon
Mushon
Inbar
Inbar
Mushon
Elad
TO DO IN PROGRESS DONE
1 8 1
TO
DO
IN PROGRESS DONE
1 8 1
How to do a CFD
50

How to do a CFD
0
20
40
60
80
100
120
1 2 3 4 5 6 7 8 9 10
51

What can teams learn from
Cumulative Flow?
Work in
Process
(WIP)
Average Cycle Time Real Done
Burnup
Total Scope
Dev Burnup
Done Burnup
52

Exercise – How would YOUR CFD
look like?
• Decide which steps/stages you would want
to see in a CFD for your release level view
• How would the CFD for your last year look
like?
53

Work in Process
• High Work-in-process leads to longest lead times
• Low work-in-process greatly reduces lead times
• Results in more effective and safer projects
54

Kanban for Hybrid mode life-cycles
55

First step – Reduce and Control
Project/Feature size
Success Rate
(On time, Budget, Quality, Customer Satisfaction)
Size
Chaos report for IT/SW projects performance - 2012

Key Measurement – Work in Progress –
57
WIP
WIP
Stabilize
Reduce

http://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

http://www.sep.com/lk2009/sterling-mortensen-case-
study-hewlett-packard-laserjet-development/

Ongoing
To Do Agile
Development
& Testing
Delivery
Deployment
Agile
Planning
Done Ongoing Done
B
C
F
H
J
G
L
I
DevOps != Continuous Deployment
O
P
Q
R
s
T
UV
More Frequent Feature Delivery
Continuous
Integration
U
Production
Continuous Deployment/Delivery will bring any
organization a lot of benefits…
but
there is a lot of value to be gained by DevOps
mindset/practices/tools even without going all the way

Dealing with expensive transaction overheads

quick roundtime for
short trips – no waits
More efficient
But longer time, less
flexibilityPragmatic
Tradeoffs

DevopsTools
Traditional
Processes
Ideal Batch
W/O
DevOps Investment
Reduce Batch Size
Further
WITH
Great automation and
leaner processes
DevOps != Continuous Deployment

http://clogeny.com/technology/devops-and-automation

How would a kanban system look like to
support each of those transfer modes?
Batch of 1
Batch of 6
Weekly Batch
68

Ongoing
To Do Agile
Development
& Testing
Delivery
Deployment
Agile
Planning
Done Ongoing Done
B
C
F
H
J
G
L
I
Dealing with the Silos structure effect on people’s actions
O
P
Q
R
s
T
UV
U
Production

Try Feature/Service/Product
oriented
BizDevTestOps Teams

Product owner
- Where are we going & why?
- Priorities
Scrum overview – structure
PO
SM
Users
Stakeholders
Helpdesk
Operations
Management
Product
Backlog
Sprint
Backlog
... etc ...
Team
Direct communication
Scrum Master
- Process leader/coach
- Impediment remover
Cross functional, self
organizing Team
- How much to pull in
- How to build it
- How to test it

Agile works best with
Feature Teams
Henrik Kniberg
Client team
C C C
Test team
T T T
DB team
D D D
Server team
S S S
Feature team 1
C
C
S
D
T
T
C
S
D
T
Feature team 2
D
S
DB
Server
Client
User
Communities
of interest
NOTE: HR Structure can be either according to competencies or
features. The important thing is for day to day work to solve as
many integrations/dependencies within one team and minimize
ongoing coordination costs

Feature
Teams &
Component
Teams
Compared
http://www.featureteams.org/
by Craig Larnman & Bas Vodde

Feature Teams & Component Teams
Compared
http://www.featureteams.org/
by Craig Larnman & Bas Vodde

DevOps Team – Enabling DevOps
• For developers to take responsibility for the systems they create, they need
support from operations :
– to understand how to build reliable software that can be continuous deployed …
– They need to be able to self-service environments and deployments.
– They need to know how to do packaging, deployment, and post-deployment
support.
• Somebody needs to support the developers in this, and if you want to call
the people who do that the “devops team”, then I’m OK with that.
The crucial thing is this: the “devops team” is NOT on the hook for the
systems that get built, or for deploying them, or writing the build and
deployment scripts, or for the operation of those systems. Nor should
there be “devops specialists” on development teams doing this work: this is
core developer work, the same as writing code, and developers need to own it..
http://continuousdelivery.com/2012/10/theres-no-such-thing-as-a-devops-team/

See Kent Beck’s idea as described by Markus Gartner at http://www.shino.de/2010/11/04/software-g-forces-the-effects-of-acceleration/
Leverage the friction/pain to drive/focus
improvement efforts

Policies – Rules of the Game
http://www.soccer-training-guide.com

Policies are a key part of improving continuously

Assess your DevOps Maturity and
take the next steps
https://www.ibmdw.net/urbancode/docs/continuous-delivery-maturity-model/
*AgileSparks DevOps Readiness Model – Early Draft – Oded Tamir – ask him to show it to you today…

Remember Maslow?
• Self-actualizationMastery
• Decentralized Control / Self-organization
• Autonomous teams that can deliver without dependenciesAutonomy
• Love/BelongingPurpose/Mission
• Sustainable Pace
• Healthy Software Craftsmanship
• Healthy Architecture
Technical Safety
Job security
Physiological
http://en.wikipedia.org/wiki/Maslow%27s_hierarchy_of_nee
ds

Across
4. deploy to production more
frequently than you can shoot a photo
on your phone. and have been doing it
for many years now.
6. Father of Extreme Programming
and now a distinguished software
engineer at Facebook.
8. only slightly less trendy than
"Mobile"
12. security tool where Gene Kim was
CTO
13. without it continuous is very hard
14. Salesforce is one of the first
companies to drive this trend
15. care mainly about delivering value
to production
17. The Don of Product Development
Flow
19. the bird that rose from ashes and
a great DevOps book
Down
1. used to store grain as well people in
functional organizations
2. one of the main reasons we need to
iterate
3. we like to get it early and often
5. the tool that used to be called Hudson.
7. Integration, Delivery, everything.
8. master of the kitchen as well as turns
infrastructure into simple code
9. care mainly about uptime and availability
10. indication of availability
11. release should be routine, not this
16. Build, Measure,
18. not just a video streaming service but
also one of the great DevOps companies out
there
The
DevOps
Puzzle
http://www.agilesparks.com/services/devops

• What would you start with?
• Draw a line or mark your cards
84

The practical steps this will drive you to adopt:
People/
Structure
Changes to working teams
More DevOps-oriented
organizational structure
Overcome Silos using
DevOps metrics/score-
cards used to govern the
organization
Processes
More frequent
reviews/approvals/integrati
on/testing/deployment
Leaner processes with
fewer/lighter gates
Higher quality built in to
avoid downstream
blockages in
Test/Deploy/Production
Self-service over handoffs
(e.g. IaaS)
Tools
Continuous Delivery
Pipeline
Virtualization
Infrastructure-As-Code
E2E Kanban
Test Automation
Infrastructure-as-a-Service

DevOps/Flow workshop for agile india 2015

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to DevOps/Flow workshop for agile india 2015 (20)

More from Yuval Yeret (20)

DevOps/Flow workshop for agile india 2015