2. AGENDA
00
01
02
03
04
05
06
Who am I?
Is this a DevOps?
What is a “good culture”?
An agile culture and correlating performance
Changing behaviors, not minds
The Anti-Patterns
Summary
4. Introduction
Colgate, Hershey’s, Premier League, Korean Air,
Kellogg’s, Wendy’s, MasterCard, BridgeStone,
Sprint, Ford, and many others.
Clients
Java (AEM, Tomcat, WebSphere)
.NET (Sitecore, Umbraco)
PHP (Wordpress, Drupal)
And whatever else the client asks us to do…
Tech Stacks
2004
University of Nebraska-Lincoln
Bachelor of Science in Computer Engineering
Education
Systems Architect, VML
TOM CUDD
10. A CULTURAL and PROFESSIONAL
movement, focused on how we build
and operate high velocity
organizations, born from the
experiences of its practitioners.
http://chef.github.io/devops-kungfu/#/
DevOps is …
22. “It was the system that made it bad,
not the people.”
– UAW negotiator Bruce Lee on the
NUMMI plant
(but probably not that Bruce Lee)
Lean Enterprise
23. “A bad system will beat a good person
every single time”
– W. Edwards Deming
Lean Enterprise
26. “... the way to change culture is not to
first change how people think, but
instead to start by changing how
people behave-what they do”
-- John Shook
episode 561WBEZ
(This American Life 2015)
About NUMMI -- quote in 2010
Lean Enterprise
27. Changing culture is achieved by the
deliberate, repeated, mindful practice of
everyone in the organization.
Lean Enterprise
28. Think like Amazon:
• Loosely coupled teams and systems
lead to autonomy
• Focus on testability and
deployability
• Encourage experimentation and
learning
Accelerate
29. Architecture and Leadership should
focus on:
• Coaching Engineers
• Outcomes
• Eliminating Blockers
• Delegating authority and autonomy
• Investing in technical management
Accelerate
30. You can act your way to better culture by
implementing these practices in
technology organizations
Accelerate
31. • Practice your form
• Beginners seem
uncomfortable, choppy
• Experience makes it seem
smooth, simple
Example:
http://codekata.com/
Kata
33. • Increased Collaboration
• Shared Responsibility
• No Silos
• Autonomous Teams
• Building Quality into the development process
• Feedback
• Automation
Markers of a Generative, DevOps culture
34. • Tribal Knowledge
• Super Hero Culture
• Silos
• Centralized Decision Making
• Quality at the end of the development process
• Information Hoarding
• Manual processes
DevOps Culture Anti-Patterns
36. Look For:
• Blocking resources
• Tickets with “status please?”
• Tickets with resolution requests (not
problem descriptions)
Do Instead:
• Use a wiki (or other knowledge repository)
• Answer questions to as wide an audience
as possible
• Let someone else “drive”
Tribal Knowledge vs. Increased Collaboration
38. Look For:
• Many odd-hours, off-hours
communications
• Stress-APGAR (Appearance, Performance,
Growth Tension, Affect Control,
Relationships) – from Harvard Business
Review
• Other teams circumventing process to get
to the “get things done” person
Do Instead:
• Monitoring use it or lose it vacation time
• Monitoring hours over 40 worked
• Rotate people on projects
• Collaborate
• Push rote work out of the system
Super Hero Culture vs. Shared Responsibility
40. Look For:
• Look for arbitrary or intentional limiting of
different team access to data or tools
• Ops work planned “in sprint 0 or 1”
• QA work planned “in the last sprint”
• Teams not co-located (physical or virtual)
Do Instead:
• Combined source control
• Combined document repositories
• Combined standups/statuses
• Proactive cross-team problem solving
Silos vs. No Silos
42. Look For:
• Work has to “go through someone” for
approval
• Arbitrary reprimands for “not following
process” or “governance”
• Fear based rule of law
• Senior contributors hoard information to
increase their importance to the projects
• Command and control structure
Do Instead:
• Trust people
• Team filled with both Junior and Senior
resources, requiring training and working
together
• Delegated decision making (caring about
outcomes, not the how)
• Pull based versus push based work
(Kanban)
• Mission command
Centralized Decision Making vs. Autonomous Teams
43. Quality at the end of the development process vs.
Building Quality into the development process
44. Look For:
• Bug/issue tracking late into projects
• Development in spurts based on QA
response
• Hours, budgets burned more as launch
approached (really a waterfall project)
Do Instead:
• QA teams and Ops teams building
automation together (with Devs, too!)
• As many technical resources from
different teams sitting together
(Dev+Sec+QA+Ops)
• Bugs tracked through the whole projects
with a centralized queue for Dev, QA, Ops
work
Quality at the end of the development process vs.
Building Quality into the development process
46. Look For:
• Who “owns” systems, tasks, processes
• Overly focused on “right way” vs. DONE
• Lack of trust or empathy (RTFM!)
• Trying to reduce or limit change to
systems, not information about critical
changes
Do Instead:
• Task tracking for issues, documented
release notes for builds
• Feedback on blocking resources
• Reaching “across the aisle”
• Expect information to be shared
• Direct radical candor in person or via video
chat (not email)
Information Hoarding vs. Feedback
48. Look For:
• “It’s faster for me to do it” than show
someone or document it
• “I don’t trust the machines to do it right”
• “It will take too long to automate” or “You
can’t automate that”
Do Instead:
• Pair engineers to document processes
• Automate something small rather than
nothing (tie small steps together later)
• Buy back any time through optimizations
or saved steps
Manual Processes vs. Automation
