Download - Ignite slides
Teaching devops to fish ...
(this is not actually about fish)
(picture of a fishing boat)
I've often said that it's my goal to engineer myself out of a job. I never expect to succeed,
because each time I engineer away a problem, a new and more interesting one is revealed by removing the first problem. You've heard the
adage “give a person a fish and they'll eat for a day; teach a person to fish and they'll eat for a lifetime” – I'd like to add to that, “they might
also help you invent a better net”(repairing nets)
But how does this relate to devops? Well, devops is a cultural innovation; it aims to break up silos
and replace a silo culture with a symbiotic culture, because cooperative systems are more resilient, creative and simply more functional.
(picture of grain silos)
I've noticed that as old function-based silos are broken down, new multi-functional ones can
form along lines of business boundaries. Teams naturally conform to sizes of 8-9 people due to
communication issues. So accepting this happens, what can we do to minimise its effects?
(team behind dry stone wall)
You might have heard of Mihaily Csikszentmihalyi (mee-hy cheek-sent-mi-hy-ee); he
described the concept of creative “flow”, but also introduced the idea of a systems model of creativity, in which social interactions and
environmental affordances provide a fertile bed for creativity to grow
(picture of growing ground)
In a devops culture, those social interactions are provided by colocation to some degree, but only within a team; you need to promote interaction between teams which often requires some level of formality and planning to achieve and keep
going.(picture of creative team meeting)
An affordance is a property of an environment which allows an individual action, for example a
map affords navigation. In a devops culture, shared knowledge and understanding of the
infrastructure, architecture, and capabilities of others afford reduced time to market, promote
innovation, reduce rework, and improve quality
(picture of a map).
By providing and improving frameworks to promote knowledge flow and increase social interaction we build a better environment for
creativity. These frameworks need to exist on a continuum of scales and formalities; let's have a
look at some
(image of circles on a number line, overlapping, smaller on the left to larger on the right)
Information radiators we should all know; dashboards and displays which constantly pump knowledge about systems into the environment, with implied context and without interactivity;
they have the dual purpose of informing knowledgeable people, and encouraging
enquiries from those walking past.(picture of sweet dashboard)
“Pop up” classes provide quick, focussed, fairly localised knowledge sharing; eg at the end of a
standup, just before lunch. These tend to happen naturally when a team is functioning well, but
can be kick-started by one or two keen individuals who just want to share something
cool. This needs to be encouraged.
(picture of group study)
Brown bags are slightly more formal, organised further in advance, and last a little bit longer; but
their lunchtime placement keeps the formality low and promotes a more fluid discussion. They
can have speakers from inside or outside the team, department, or organisation; they generally
go for about an hour.(picture of brown lunch bags)
Kata sessions are single-topic focussed, and encourage a larger number of people with a little knowledge to share that in 3-5 minute bite-sized
pieces; eg “cool things we can do in Splunk”.
(picture of tai chi)
Dojos are a little larger again and more formal than a kata session, with a couple of experts
giving a 1-2 hour interactive class on one or two focussed topics of interest; there may be pre-
work or homework. An example might be “using OAUTH for identity federation” or “shell
scripting from zero to hero”
(picture of a dojo)
Hack days are the largest formal knowledge-mixer, creating whole short-lived teams from
individuals who might not normally work together, and having them develop a single
product/idea/process over the course of a day (plus time for display/voting)
(pictures of the REA hack day)
You should aim to share as much knowledge as you can, perhaps even slightly more than you are comfortable with, to counteract the tendency to
build and fortify silos of knowledge. How creative are cultures where only high priests have
the hidden knowledge?
(picture of a high priest)
You should aim to share knowledge of your environments, skill sets, processes, plans,
architectures, successes and failures, especially to those that you don't work with directly
. (picture of sun shining through trees)
You'll help prevent silo formation, engage the curiosity of your peers, increase the recognition
of capabilities of individuals, improve the quality and speed of decision making, short-cut the path
to discovery of good (and bad) technologies, provide protection against human outage, and
improve the environment for creativity to thrive(pictures of thumbs up)
I'm not saying you have to share absolutely everything; some things don't share well, like
root passwords on financial servers; but perhaps you can share the fact that there is a financial
server, and it's replicated across two continents; this might change how a team architects an
application that produces or consumes the data it holds.
(picture of sharing)
… as the sage (might have) said:
“Give a person a fish and they eat for a day.
Teach them to fish, and they'll eat for a lifetime.
Teach them how and why nets are made like this, and they could help you invent a better net”
(picture of mending nets)
A rising tide lifts all boats after all; if I can help you engineer me out of one job, think of the cool and interesting problems we'll be able to work on
next once we've been able to step beyond the current problems and have seen what lies ahead.
(picture of bright field beyond trees)