FUG Presentation: Enterprise DevOps by Serena Software (presentation)

1. 1
Copyright © Serena Software 2015
Creating High Performance Teams by using a DevOps Culture
2013Mark Levy, Product Marketing Manager
Mark Levy, Serena Software

2. 2
What is DevOps
It isn’t:
• Just tools
• Just culture
• Just dev and ops
• A job description
• Or another silo’d organization
The DevOps Principles
Culture
Automation
Measurement
Sharing

3. 3
Why DevOps
• Empowered, demanding customers
• Increasing digital competition
• Increased expectations of software
Enables IT alignment by aligning development and operations
roles and processes in the context of shared business objectives
CONTROL
Need to drive competitive
advantage and respond to market
needs
Agile practices have increased the
speed of engineering delivery
Still ruled by a SLA’s, stability and
an inherent resistance to change
BUSINESS DEVELOPMENT OPERATIONS
AGILITY CONTROL
Broken

4. 4
4
Components of DevOps

5. 5
• Deploy 30x more frequently with 200x shorter lead
times
• 60x fewer failures and recover 168x faster
• Lean management and continuous delivery
practices
• Greenfield or legacy.
• IT managers play a critical role
• Diversity Matters
• A better place to work!
What is a High Performance IT
CONTROL
Deployment pain can tell you a lot about your IT performance

6. 6
What is DevOps Culture
• Shared values and behaviors
• There’s no right culture for
DevOps, but there are
characteristics:
– Open communication
– Alignment
– Flexible
– Collaborative
– Respect and Trust
• If your organization isn’t these
things, you have to build them

7. 7
Organizational Cultures
How Organizations Process Information
Pathological
Power oriented
Bureaucratic
Rule oriented
Generative
Performance oriented
Low cooperation Modest cooperation High cooperation
Messengers shot Messengers neglected Messengers trained
Responsibilities shirked Narrow responsibilities Risks are shared
Bridging discouraged Bridging tolerated Bridging encouraged
Failure leads to scapegoating Failure leads to justice Failure leads to inquire
Novelty crushed Novelty leads to problems Novelty implemented

8. 8
Shared Risk and High Cooperation
• Self-­service deployments
• You built it, you run it
• You build it, you deploy it
• If I’m awake your awake
• Developers on call
• Warranty
periods
• Facebook’s push karma

9. 9
Bridging Encouraged
http://www.jedi.be/blog/2012/05/12/codifying-­devops-­area-­practices/

10. 10
• Team members are accountable but not responsible
• Foster complete transparency
• Focus on the situational aspects of the failure’s
mechanism and decision making process
• Capture a detailed account without fear of punishment or
retribution
• What happened and how to improve (Agile Retrospective)
• Start doing
• Stop doing
• Continue doing
Messengers Trained: Failure Leads to Inquiry
Blameless Post Mortems

11. 11
Transforming
Your
Organization
to
DevOps
Setting Goals
Gaining Executive Support
Building Pilot Projects
Training and Prioritization
Outreach And Evangelism

12. 12
Setting Goals
Get agreement up front on the metrics
Give the goals a timeline
Ensure goals are measureable and support the business
Understand the primary goal of the business
Go ask the business

13. 13
Goal Examples
Reduce time-­to-­
market for new
features from
quarterly to monthly.
Reduce the time it
takes to deploy a
software release from
12 hours to 90
minutes.
Increase the
percentage of defects
detected in testing
before production
release by 80 percent.
Increase service
availability from 98 to
99.9 percent

14. 14
Key 2: Gaining Executive Support

15. 15
• The right goals will get buy in
• Your DevOps transformation
will need some people, some
budget, some time
• You may have to move people
around, or change their
workloads
Air Cover

16. 16
• It’s tempting to just go for it and
hope for the best
• In some organizations this
definitely works!
• In others, you’ll want someone to
help cut through red tape and make
resources available
Skunkworks

17. 17
Silos
• Exist for reasons
• Based on “Silos of Excellence” with
Management oversight
• Primary focuses on policies,
systems and structures
• Secondary focus on people,
principals and values
• Batch and Queue model
• Has to be addressed in a
constructive Manner

18. 18
• Prominent team members that people
look up to
• Look for informal lines of influence
• “Let’s see what Bob thinks of that” or “We
should ask Jane”
Non-­Executive Influencers
Look for the People Everyone Wants on Their Team

19. 19
19
The Role of Management in a DevOps Transition
• Workload prioritization
• Influence on external teams
– “Who do I have to talk to to make this
happen?”
• Managing personnel issues
– Orgs in transition may end up moving
people to new teams, changing
someone’s role drastically, letting people
go, or other scary things
• You want someone respected in your
organization to back your project
• Getting top down alignment

20. 20
Key 3: Building Pilot Projects

21. 21
• CAMS
• Creating a Culture
• Building Automation
• Measuring all the Things
• Sharing What Happens
If these aren’t natural to your team,
you need a place to practice
Why a Pilot?

22. 22
• Management support
• Start small, but deep
• Flush out all the gnarly bumps in the road
• Starting small is:
• less expensive
• Is not a threat
• Can be called an experiment
• Representative of real work
Picking A Pilot

23. 23
• Teams that are open to experimentation
• Working with modern platforms
– Programming language, OS version
– Also interfaces – loosely coupled
upstream and downstream
• Brand new, greenfield is good but legacy
will work also
• Established projects with a new release
are too!
•
What Makes a Good Pilot

24. 24
Key 4: Training and Prioritization

25. 25
• Train everyone
• On new tools, on new workflows, new patterns
and best practices
• Training is part of sharing
• Internal DevOpsDays
• Host a DevOps Safari
• Team members joins the DevOps team for a
couple of weeks
“People do not truly believe in new things unless
they have actually experienced it”…Machiavelli
Training

26. 26
Moving Workloads
• The folks who have to learn new
things have to have time to do it
• Some of their current work will
have to be deprioritized or moved
• Everyone on the team should get
a chance to do new stuff – don’t
leave someone behind to maintain
the old stuff alone

27. 27
• Don’t kill anyone for DevOps
• It takes time to learn new
processes and tools, no matter
how excited the team is about it
• Your entire project will take time
as well
Setting Expectations

28. 28
• Any change has effects on the
organizations involved
• It’s likely that adoption and
enthusiasm will not be universal
• Up to management to incentivize,
reward
• Make the hard decisions about an
individual’s future with the group
Helping the Lost or Disgruntled

29. 29
• No
• Expecting brand-­new individual
contributors to change your culture
is a losing proposition
• Organizational change can be
created with new leadership
– Still requires influence,
credibility, the right person
Hiring for DevOps?

30. 30
• Split and Seed
• Add more teams quickly
• Each team has someone with DevOps Experience
• Grow and Split
• You don’t have to destroy an existing team
• Team members feel more continuity
• Internal Coaching
• Well running teams do not need to be split
• Coaching can be hand selected for new teams
• Coaches can be moved from team to team
Patterns for Spreading DevOps

31. 31
Key 5: Outreach and Evangelism

32. 32
• Talk about the New Awesome!
• Internally
• Externally
• All the time
• Show KPIs that support the change
• Tell your story with data
• Use different venues
• Brown bags sessions, formal workshops, larger talks, All-­Hands
• Documents, video, graphs!
Showing Off

33. 33
If you feel like you’re talking about it
too much, you’re probably just
about right
Over Communicate

34. 34
• It will take time
• Some will be experimental
• You won’t do it perfectly the first time
Having Patience

35. 35
• Aspire to create a generative
culture
• Align with the business and set
measurable goals
• Get an executive sponsor on board
• Pick the right pilot
• Train and prioritize the teams
• Communicate and share
In Summary

36. 36
References

37. 37
37
Thank
You