Post on 08-May-2015
DevOps isn’t Enough for your Dysfunctional
Organization
mandi wallsmandi@opscode.com
whoami
•Mandi Walls
•Consultant for Opscode, the makers of Chef
•@lnxchk
What I Do
•Visit Opscode’s customers
•Help them learn Chef
•Listen to their issues and problems
technical consultant as organizational therapist
Why DevOps?
•Shifting requirements for IT projects
•Shifting demands from customers
•Shift in the role IT plays in organizations
Why Dev + Ops
• It’s not really just about Development and Operations teams
•Everyone has a hand in creating better products
Are You Dysfunctional?
Deviating from the norms of behavior in a way regarded
as bad
What Makes for Dysfunction
•Arbitrary rules
•Workflows that people circumvent when they can
•Requirements that delay or derail a project
Origins of Dysfunction
•Specialization
•Prioritization
•Conflict of Incentives
Specialization
•Not a bad thing
•Necessary for complex IT structures
•Creates functional fanatics
Prioritization
•Conflicting goals
•Communication challenges
•Resource limitations
Conflict of Incentives
•Classic Dev vs Ops problems
•Also affects other teams
•Not new, not exclusive to DevOps
Tools to Get Beyond Dysfunction
Goals
•Goal setting is key
•Goals must be communicated
•Goals in change initiatives must be measurable
Communication
•Communicate, communicate, communicate
•Documentation
•Check points
Self Awareness
•What motivates your team members?
•What fears or doubts do they have?
•Does your team recognize its own dysfunction?
Training
•Good training is priceless
•Bad training is incredibly damaging
•Training in general is expensive
Working with People Issues
Executive Support
•Cleaning up dysfunction requires support from high levels in the org
•Have to be able to realign people and resources around new goals
•Skunkworks projects are tempting, but fail when scope expands
Management
•The power to create or disintegrate dysfunction
•May not be empowered to make real change
Fear
•Do I have the right skills?
•Will it be hard to do?
•Will I get fired?
Reluctance
•This isn’t exciting!
•We’ve seen all of this before
• I don’t need to know this
Path of Least Resistance
•Are people even following the currently proscribed processes
Boomerang Projects
•A sign of organizational dysfunction when your team decides to ignore an initiative, or “wait it out” because they believe it will disappear or lose traction before it gets implemented.
Making a Plan
•So you say you want some DevOps revolution
•Executive Buy In
•Organizational Assessment
•Readiness
•Pilot Project
•Reassess
Executive Buy In
•As discussed earlier, finding a sponsor in upper management smoothes your path
•Someone who has influence over all the teams you may need to involve
•Someone who is able to prioritize teams, support your goals, and articulate to others why your initiative is important and deserves resources
Assessment
•The fun begins
•Where is your process now?
•Synchronous discussion
Who
•Talk to everyone
•Ask everyone the same baseline questions
•You should get a good multifaceted view of the current state
Baseline Questions
•What is the primary goal of the company/team/project
Baseline Questions
•What is the most broken thing about the current process/project?
Baseline Questions
•What would you want to not see change about your project?
Another Interesting Question
•Drive the discussion towards who has influence
•Who would they most want to have on the team?
Generic Questions
•Tools being used
•Tickets and tracking
•Reporting and assessment
Specific Questions
•What’s driving you to DevOps?
•How long do deploys take?
•What’s your time-to-market?
Making Sense of Assessment
•The full scope of the team
•A list of tools and resources being used
•A list of potential weak spots to look out for
•Set a baseline for your goals
Readiness
•Getting at the squeaky wheels
•Training for any new tools
Build from the Assessment
•Determining what to do with the broken pieces
•Determining which of your current processes are beneficial and which could be harmful
Strong Foundation
•Align tools and people
•Set and communicate goals
Pilot Project
Choosing a Pilot Project
•Narrow but deep
•Shine light in all the dark corners
• Involve secondary teams, resources
Tough Conversations
•About goals and values
•About the priority of external requirements
Ultimate Pilot
•Greenfield when you can
•Work through it end-to-end
Hostage Situations
•Who is able to hold your project hostage?
Reassess
•Along the way, check point your progress
•How are you tracking towards your goals?
•What went well? What went badly?
Next Steps
API All the Things
•Make better use of human brains
•Common tasks can be automated
Create a Service Catalog
•Not in the SOA sense, but in the “I need some storage” sense
•Limit choices, speed up supported requests
FAQs
Timelines
•How long will this take? I want it to be done in [1,2,6] months!
Trust
• “How do I create a DevOps workflow but keep X team away from the tools?”
The Dreaded Question
• “Do I have to fire people?”
Can Large Orgs do DevOps?
• “I have too many people to do something like DevOps”
Q&A