Talk given by Graham Dick at DevOps Summit on 20th November http://www.devopssummit.com/london-2014/

1. © Lamri Ltd 2014
Making DevOps Business as Usual
Graham Dick
Lamri
20th November 2014

2. – Is a gap between Dev and Ops.
Symptomized by
• Excess work in progress
• Excess Service fragility
• Long project wait lines (shadow IT)
© Lamri Ltd 2014
IT and Ops
The Agile revolution
– Has brought Dev closer to the Business,
in an attempt to deliver Value faster
– But there is a cost ….
Business Customers
Dev
Ops
services
Agile closes the gap
gap
• The cost
Tension /
Back-pressure
Drives local
optimisation
The DevOps movement has emerged in response to this gap

3. © Lamri Ltd 2014
What does DevOps look like?
Ops
Dev
Measurement
• Deployment frequency
• Lead time to change
• Meantime to recover from failure
Automation
• Continuous integration / Testing
• Continuous delivery / deployment
• Version management of all environments
• Proactive monitoring of application health
Sharing to enable improvement
• Of ideas and problems
• Of success stories
Culture
• No-blame
• Freedom to experiment
• Local accountability
Deploy code 30 times more frequently
25% respondents report deployment times reduced to less than 1 day; 50%
reduced to less than 1 hour
50% reduction in failures following changes
75% of respondents able to restore service in under 1 hour (12 times faster than
lower performing peers)
2014 State of DevOps Report

4. © Lamri Ltd 2014
Talk about Culture
Leadership
(style, values, habits)
Strategy
(goals, success measures, rewards)
Structure
(roles/responsibilities, organisation)
Processes
(policies, operations, value chain, business processes)
People
(values, beliefs, attitudes, norms, habits)
Culture
Introduction to ICAgile – Ahmed Sidkey Feb 2014

5. © Lamri Ltd 2014
Talk about Culture
Leadership
(style, values, habits)
Strategy
(goals, success measures, rewards)
Structure
(roles/responsibilities, organisation)
Processes
(policies, operations, value chain, business processes)
People
(values, beliefs, attitudes, norms, habits)
Change
Culture
Introduction to ICAgile – Ahmed Sidkey Feb 2014

6. © Lamri Ltd 2014
For widespread DevOps adoption
Its not just Dev and Ops who need to change
Executive
Management
Finance
End Users
Project Sponsor
Line Management
The delivery
team
The ops
team
3rd party solution
component
Who is touched by changing tools or process?

7. © Lamri Ltd 2014
DevOps depends on people …
How receptive are they?
Early
Adopters
Active
Resistors
Late
Adopters
REMEMBER - this spread applies to the team AND external stakeholders

8. © Lamri Ltd 2014
Add in delivery pressure
and listening goes down!
Early
Adopters
Active
Resistors
Late
Adopters
1 Barriers to DevOps Adoption
38%
31%
16%
Lack of collaboration between silos
Cultural barriers to working together
Resistant to change
1 Serena

9. © Lamri Ltd 2014
Driving DevOps at scale means
Knowing the reason for change
What?
•“Two-minute elevator spiel” (Tom Peters) – keep to 30 secs
•The reason to instinctively support this project
•Normally based around a threat or opportunity
•Encapsulates the real reason for doing this
Good examples
•“Unless we start hitting our milestones, we will not exist”
•“Improve the margin by reducing wasteful rework”
•“We face a huge increase in business demand for change”
•“Prove we’re better than the outsource providers”

10. © Lamri Ltd 2014
Selling to the wider set of stakeholders
Whats in it for me?
Executive
Management
Finance
Higher initial spend;
early risk exposure 
can challenge
perceptions
The delivery
team
Focus on deployed
software is more
satisfying …. Fun ….
O&M
Greater release frequency
can be threatening – but
greater collaboration
allows O&M needs to be
better understood
DevOps makes life a little
easier – focus on deployed
software provides a more
objective view of progress
Management
Who is touched by changing tools or process?
End Users
Frequent releases help
ensure key customer needs
are met
Project Sponsor

11. © Lamri Ltd 2014
Demonstrating strategic alignment
attempting this helps discover whats important to key
stakeholders
•Increase profitable sales
•Operational cost reduction
•Perception of the brand, “squeaky clean” etc
Deliver IT projects reliably to enable the business
strategy to launch XXX services in XXX timeframe
Benefits
Deployed improved working practices, base on DevOps
principles
Desired
outcomes
High level
deliverable
• Lead time to change
•Deployment frequency
•Customer satisfaction
Measures
Agree the measures early and follow through

12. Feedback
© Lamri Ltd 2014
Drive demand for DevOps
Bringing key elements of practice to life drives and sustains DevOps
Current Situation Desired Situation
Senior
Management
Development
Management
Dev Teams
Process
Management
Senior
Management
Delivery Teams
(DEV & OPS)
Quality
Project
Management
Feedback
Govern
ways of
working
Govern
Support
using
process
Govern
Coach /
Review
Community that
drives demand for
process adoption
Ops
Management
DevOps adoption critically depends on
individuals
DevOps adoption supported by and in
best interests of organization
Ops Teams
Quality
Project
Management

13. Feedback
© Lamri Ltd 2014
Drive demand for DevOps
Identify practice leads
• Senior staff taken from
the line
• Part / full time role
• How we “work here”
• Harvest improvements
from project
retrospectives
• Championing it across
the organisation
• Ensure project staff
suitably skilled
Process
Management
Senior
Management
Delivery Teams
(DEV & OPS)
Quality
Project
Management
Feedback
Govern
ways of
working
Support
using
process
Govern
Coach /
Review
Govern

14. © Lamri Ltd 2014
How does Practice Leads approach
work?
• Staff
– Organisationally
managed by practice
lead
– Funded by projects
– Embedded in project &
ops teams
• Ensures
– Maintain delivery focus
– Identify and share best-practice
– Stick to / Enhance the
processes
– Enhanced visibility into
project risk
Project 1
Project 2
Project 3
Project n
Practice Leads

15. © Lamri Ltd 2014
Adopt Service Thinking
Service 1
Service 2
Service 3
Service n
Helps address culture
“you build it you run it”
Common approach to delivery
Encourages cross-skilling, common ownership of code
Start to think in terms of annual team plan
Business & technical environments
Approach to doing work
Plan in skills improvement
Fill Timebox with Points
from the Prioritized Backlog
Points Based
Sizing
Monitor In Points;
Work is Countable
velocity and estimating errors
used to refine estimation basis

16. © Lamri Ltd 2014
Drive demand for DevOps
“Quality” & “Management”
• Quality team
– Independent of
projects
• Carrot and stick
– Ask: is the
project/function
working the way it
intends?
– Provide coaching
– Harvest improvements
• Accountable for project success
– Our approach is the least-risk way
of delivering
– Support / facilitate
– Remove obstacles
– Support team’s continued use of
practices that work even in times of
stress
– Process compliance is important

17. © Lamri Ltd 2014
Implementing
Adopting guerrilla tactics
Function 2
Function 1
Delivery
capability
Function 3
Function 4
Initiative 4
Initiative 3
Initiative 5
Initiative
6
Initiative
2
Initiative
1
• People want to improve the
organisation
• Many improvement initiatives
 Overwhelmingly good stuff
• Find the needy and the willing
 Who are they?
 How can you hook them in?
• Form alliances
• Don’t take over the world
• Much can be delivered through
existing initiatives
• Ownership stays with the people
that know the work
DevOps

18. © Lamri Ltd 2014
If we want the benefits from DevOps
strip out silos to make the organisation more Agile
• Adopting DevOps in a typically
complex setting
– Isn’t just going to happen
• Recognize it’s
processes/tools/attitudes that
require
– Widespread adoption
– Sustainment over time to maintain their
relevance
• It’s a change programme …
– Needs selling
– Needs funding
– Needs delivering
– Needs sustaining

19. © Lamri Ltd 2014
Lamri Ltd
7 Mowbray House
Olympic Way
Richmond
North Yorkshire
DL10 4FB
graham.dick@lamri.com
p +44 (0) 1748 821824

20. Organisational Benefits …
only realised when we have DevOps at scale
• Waves of mergers & acquisitions,
rationalisations, cost-cutting, investment etc etc
– Multiple Dev centres
– Multiple Ops centres
– Organised by line of business, by technology
LOB Dev 1
• Personal networks – that used to ‘get stuff done’
– are stressed, or don’t exist at all
• Poorly aligned management, Misaligned toolsets,
training and backgrounds
IT Ops 1
LOB Dev 2
LOB Dev 3
IT Ops 2
Conspires to make collaboration harder © Lamri Ltd 2014

21. • Many of these questions are
answered with a mix of tool and
process
solutions for consistency and
completeness
• Or look to best practice models
© Lamri Ltd 2014
Scaling DevOps – multi project; location;
geography
needs consistent answers to many questions
• What versions & platforms
constitute this release?
• What does this version do?
• What steps do we need to take
to go-live whilst maintaining
service delivery?
• Who do we need to inform?
• How do we resolve incidents
and prevent their re-occurrence
• How do we ensure our people
have the skills needed to work
in the new ways?
• When will we deliver; what
might go wrong?
• How well are we performing?
Build &
unit test
Platform test
Deliver to
staging
• Either work out your own
Acceptance
test
Deploy to
production
Post deploy
tests
(CMMI, ITIL etc)

22. © Lamri Ltd 2014
In Conclusion
Level 5 Optimising
DevOps
Track and use performance data
to optimise processes and
automate manual steps
Level 4 Managed
DevOps
Dev & Ops – use of metrics to
understand and resolve
problems. The relevant
developer called to fix problems.
Level 3 Fundamental
DevOps
Process, automation & metrics
shared across projects / services.
Hand-off issues reduced.
Learning from experience
Level 2
Projects /
services use
automation -
differrently
Little sharing of approach / tools
so issues at handover. “React”
and firefight when problems
occur
Level 1 No DevOps yet Fire-fighting, finger-pointing