1Copyright   ©  Serena   Software   2015

Creating  High  Performance  Teams  by  using  a  DevOps  Culture  

2013Mark  Levy,  Product  Marketing  Manager  

Mark  Levy,  Serena  Software

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

CultureAutomationMeasurementSharing

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

Components  of  DevOps

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

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

Organizational  Cultures

How  Organizations  Process  InformationPathologicalPower  oriented

BureaucraticRule  oriented

GenerativePerformance  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

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

Bridging  Encouraged

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

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

Transforming  Your  Organization  to  DevOps

Setting  Goals

Gaining  Executive  Support

Building  Pilot  Projects

Training  and  Prioritization

Outreach  And  Evangelism  

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

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

Key  2:  Gaining  Executive  Support

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

• 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

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

• 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

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

Key  3:  Building  Pilot  Projects

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

• 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

• 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

Key  4:  Training  and  Prioritization

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

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

• 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

• 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

• 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

• 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

Key  5:  Outreach  and  Evangelism

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

If  you  feel  like  you’re  talking  about  it  too  much,  you’re  probably  just  about  right

Over  Communicate

34

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

Having  Patience

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

References

37 37

Thank  You