The Entirely Random DevOps Days London Write Up

There are some great posts out there on the superlative DevOpsDays London 2016 Conference. Of particular note are Manual PaisDevOpsGuys  and Helen Beal’s DevOpsDays London: Making Happy. These are well structured, balanced pieces which neatly represent each talk along with insight from experienced authors.  I hate to disappoint, but this post is not one of those. It’s a random collection of the things that peaked my interest at DevOps Days London.


What is Legacy?
There was lots of talk of legacy, the BiModal debate rolled on. Much like the sporadic agile wars many of the detractors use out dated definitions as convenient ammunition, Gartner’s understanding of the challenges seems to have evolved away from its original strategy towards an exploit and explore approach for recent and legacy systems respectively.  Defining legacy is challenging, with considerations beyond just the age of the software or system. There were a few definitions I really liked:
“Legacy is code you can’t iterate on as quickly as you need to” – Casey West
“Legacy is code you don’t have automated tests for. – Micheal Feathers
“Legacy is where your customer money lives” –  Bridget Kromhout


The merits of really reading
I keep having the same conversation, like being in a endless loop, it goes like this:

Person: “Yeah, I know all about Conway’s law, it is super insightful”
Me: “Exactly, that example about teams building compilers, that’s a light bulb moment”
Person: “….the compilers?”
Me: (Thinks) “Have you really taken time to understand what you’re advising people to do, or are you just reciting tweets?”
Me: (Says) “ Check out the article, there’s lots more in it”

It is like this with so many topics, REST, OODA, Learning. That’s why I was so pleased to hear the ever-eloquent Gareth Rushgrove call out the value of reading academic papers in his talk.  These days we are so prone to snacking on sound bites we seldom get the satisfaction of a full reading meal, yet our brains cry out for this kind of nourishment. I believe papers, and source material in general, are the best way to gain a firm understanding of a topic, particularly because they build a picture of what motivated the author, not just what they did.  Much like software patterns, understanding the intent and motivation is key to successful application.


A couple of talks touched on burnout, as did a well attended and lively open space. What surprised me was how many people had direct experience of it, it remains an issue in the industry despite raised awareness and talk of sustainable, humane ways of working. Oliver Wood talked about his experiences working so many hours that he slipped a disk. Keen that others may avoid the same fate, he created GoodCoderBadPosture.  During his ignite he reminded us “you are ephemeral , you are not highly available“.  My talk (Things I learnt About DevOps When My Car Caught Fire) used the analogy of looking through the windscreen of my burnt out car, all the instruments you normally rely upon to sense the world are warped and confused, your view is fogged and distorted. If only we could see metal strain as readily as we can bad posture.

I noticed much of the burnout open space was concerned with what management and organisations can do prevent burnout, and recognise it’s occurrence. This is a reasonable standpoint given that our behaviours are generally shaped by the systems we work within. However In the spirit of DevOps we should also note that it isn’t a problem for effected individuals and their mangers to tackle alone.  While organisations take action, we might also ask ourselves:

1. “How would I know if one of my colleagues was suffering from burnout?”
2. “How would I help someone I thought on the verge of burnout?”
3. “How do my own behaviours effect the likelihood of burnout in my colleagues?”

There was a nice note in Jeromy Carriere’s talk, and a potential answer to question 3: “Work hard to make every alert exciting” this has implications for burnout, exciting alerts implies only being disturbed for hard problems, not simple switch flicking exercises.

There was plenty of talk of change, particularly the danger of not evolving and experimenting.  Change strategies were discussed, including the value of heading into conversations well armed with data.  It was clear from their talk that Microsoft are changing in places, for instance setting up open team rooms or neighborhoods.  I rate this approach, it appears to balance team privacy, open communications and the distractions of full open plan.

“It is not necessary to change, survival is not mandatory” – Deming (Who wasn’t present!)
“The riskiest thing is not to change” – Joanne Molesky

The change theme included the importance of investing time in the most valuable activities, and how to discover them. It highlighted that many of those valuable activities are operational features, not just shiny new toys to please users. If you’re in the mood for self reflection you might give some thought to this quote from Bridget Kromhout:
“When evaluating yourself don’t forget to look at the value you are adding”

A conference, with a culture
The thing I love about DevOpsDays, and the way it’s organised, is that it still feels like a community event, sure it’s scaled, but the level of friendliness, inclusion and support are almost as the first time I spoke in Goteborg 2011. The story of this scaling and principles behind it were told by Kris Buytaert, it’s surprising how many of the early adopters are still active. The conference manages to short circuit a lot of anchoring and group think by giving almost 50% of the time to open spaces. Taking responsibility for the schedule out of the committee’s hands into the delegate’s ensures that topics are relevant to attendees, right then and there. The willingness of speakers to stay and participate in these sessions is key to their success and makes for some great learning.  Not bad for a movement that still can’t agree what its about.


Five Gators Of The Apocalypse?

Wacky gators arcade machine

I generally dislike war and military metaphors for team and making activities.   Admittedly IT has a lot to learn from the military in terms of teams and scale, but in the wrong hands these metaphors seem to encourage unproductive conflict and counter-collaborative behaviours. This strikes me as odd because although prepared for conflict, the military spend much of their time avoiding or minimising it.  However, I do need to call upon a slightly violent metaphor to describe the relationship between constraints encountered when building a continuous delivery capability in an organisation.

The process of change reminds me of the nineties arcade game Whacky Gators, where a number of cheeky gators poke their heads out of caves, and you biff them with a large hammer, hands, or other appendage depending on personal preference. You never know which gator will appear, or when, and more than one might show up at once.

When encouraging continuous delivery (and by extension DevOps) those gators might be named: Culture, Tools, Organisation, Process, and Architecture.

These five are interdependent constraints, each affecting the other.  However, while inside Whacky Gators is a fairly simple randomiser determining which gator will surface, behind the scenes our organisations look more like a hideous HR Giger meets Heath Robinson mash up.  We can’t readily inspect them to determine what to change.

My theory is that when one constraint is eased it will reveal a new constraint in a different area. This is a tenet of most agile and learning methods – surface a significant issue, deal with it, see what surfaces next.  Often a method, and our expertise, focuses on just a couple of areas, we’re well versed at solving problems with technical solutions, or just improving our own team’s capability in isolation.

A good continuous delivery capability involves the whole engineering organisation (a great one involves the entire organisation). This means it is crucial to consider all five constraints, and when there is a problem be ready to shift focus and look for the solution in one of the other areas.  In fact, this simple shifting may lead to the root of a problem.  Do reams of process indicate a risk adverse culture?  The solution may not be more process, but a different attitude.  Are those tools covering up or compensating for some thorny, unspoken issue no one dared to face?  When trying to improve delivery capability there may be a temptation to replace an old tool with an improved version, maybe the need for that tool (and associated overheads) can disappear with an ounce of process and a healthy dollop of collaboration?

Returning to our Whacky Gators metaphor, the big question is how are you playing?  Do you simply wait for that same familiar gator to return?  The one you’re most comfortable dealing with?  Do you hover where you are comfortable while other opportunities pass by or, are you nimble, and brave enough to tackle each constraint as it appears?

While I was looking up Whacky Gators, I couldn’t resist a peak in the machine service manual, there I found this uncanny quote on success, as applicable in the game, as it is in change:
“The player does not score extra points by hitting harder; a light touch will activate the circuits and will lead to higher scores.”


Before we learn, must we first unlearn?

Sometimes I read something and think, this is awesome, how did I miss this one? Sometimes, I even get carried away and write more than 140 characters about it…

One such article explores the concept of ‘unlearning’, as a precursor, or catalyst, to learning. Learning feels like a common denominator across agile methods. But agile is not just about learning how to get better at building stuff, it’s about learning how to introduce and encourage change.

The article is ‘Unlearning Ineffective or Obsolete Technologies’ by William H Starbuck, currently a visiting professor at Cambridge. The article is an absolute goldmine, but Starbuck is also remarkable for having a CV that has to be one of the most simultaneously impregnable and impressive of all time.

The abstract grabbed me straight off: “Often before [people] can learn something new, people have to unlearn what think they already know.”

We’re familiar (and often lazy) with concepts like keeping an open mind, and perhaps techniques like DeBono’s thinking hats which invite other perspectives. Deliberate unlearning though, seems counter intuitive and somewhat destructive, especially if the ultimate aim is to learn more.

The article is packed with great antidotes to reinforce the messages, from how a navy spent weeks bombing aquatic mammals they believed were submarines to exploding steam boats and Sony Walkman development.

Frankly I’d recommend you stop reading this now, and read full the paper, but if you don’t have the time available, allow me to offer a summary:

Starbuck suggests that there are three key points to recognize in order to encourage learning.

1.Learning cannot happen without unlearning – current beliefs are blinkers, something is required to demonstrate that people should no longer rely on their current beliefs and methods – “Expertise creates perceptual filters that keep experts from noticing technical and social changes”
2. Organizations make it difficult to learn without first unlearning. Policies and practice are often created from individual’s beliefs, and these polices mesh together to form a kind of structure, in which it is difficult to change a small part. This creates a self-perpetuating situation discouraging change, where it becomes hard to change anything without dismantling the whole system.
3. Unlearning by people in organizations may depend on political changes. I think the key point here is that unlearning may need to be enabled by people changes. The motivation may be political or something more mundane, the change in influencer is the significant part. This is because information is interpreted by people, influential people create ways of working, culture and policies. Any modification to these may be seen as a threat to the individual and suppressed, rather than exploring suggested change. Starbuck suggests this is why senior managers are prone to overlook, and miss-interpret bad news.

I hear things that support these views time and time again, phrases like “our Agile culture was going no where until so-and-so joined, or so-and-so finally left”. Other disruptions seem to foster unlearning – particularly stronger collaboration and a better appreciation for the challenges of other teams, something very visible in the DevOps movement.

Starbucks goes on to identify methods, or viewpoints, to encourage unlearing.

Dissatisfaction – A common reason for doubting, and reconsidering current approaches, he observes that this can take a long time, presumably requiring a high level of discontent before people are motivated to seek change.

“It’s only an experiment” – There is a mind trick that goes on when we are in experimental mode; we take calculated risks, and we are more observant, we want to evaluate outcomes, rather than preferring a particular one. Often there is less to loose if the results aren’t as predicted. Starbuck puts it: “[Experiments] create opportunities to surprise”. As a side note, Cynefin recognizes the value of this, and promotes safe to fail experiments, nice post here.

“Surprises should be questions marks” – In other words when something surprises us, we should not dismiss it, or categorize it as an interesting anomaly, but look to see if it challenges any of our beliefs or assumptions.

“All descents and warnings have some validity” – Starbuck admits that this is a little over zealous, and there are sources of dissent that don’t provide value, never the less in many cases there is something to gain. Often these comments are attempts to warn or inform, and merit attention.

“Collaborators who disagree are both right” – or rather, there are elements of truth in both arguments. In these situations the art is discovering how the seemingly contradictory elements can both exist. This doesn’t mean creating a compromised win-win situation. It means challenging assumptions and seeking new models until there is understanding.

“What does a stranger think strange?” – Strangers haven’t been exposed to, or adopted, your ways of working, and therefore are more likely to challenge and make valuable observations. In my opinion this is yet another reason to pay close attention to new hires, especially if they are new to the industry or fresh from college.

“All casual arrows have two heads” – If I’ve interpreted it correctly, this indicates that we should change the way we consider flow, by recognizing that there are two directions for each path and we should seek out overlooked feedback routes. Starbuck illustrates with a great example: Mass vehicle manufacturing was once be based on accumulating inventory. Materials were shaped into components, components into cars and customers selected cars from the vehicle inventory. That’s one direction for a causal path. Taiichi Ohno saw the opposite direction and created Toyota’s just in time system, where the absence of inventory to serve customer demand stimulated flow.

“The converse of every proposition is equally valid.” – This pithy phrase is almost immediately caveated to indicate that not all propositions have a valid converse. I guess the aim is to train ourselves to explore the converse, a neat method of flipping our perspectives. Are leaders really leading their people, or just servants to them?

Summing up then, Starbuck puts forward a set of useful techniques to help us overcome our inherent biases and tendency to filter what we consider threatening or bothersome. Even if you don’t agree with the techniques it’s a useful reminder, and the goals are worthwhile. These techniques may avoid some other more catastrophic event, like being fired or going out of business, being the trigger for unlearning. The term unlearning is convenient but perhaps a misnomer, nothing is discarded, it is more a recognition that current beliefs, ways of working ,or processes, no longer serve us; that it is time to seek alternatives.

Ok, come in…

So I’ve decided to try blogging again. Much to my own surprise I started by deleting all my previous posts.  They were generally concerned with the epic battle to keep my rusty vw camper from the scrap heap, photography and cameras.  Deleting the posts was quite a cathartic experience, given that these days we tend not to tidy up after our digital selves.  Like space junk, this string of debris can collide with us when we least expect it to.

I’ve left just one post, my first on wordpress, partly for nostalgic reasons, and partly to remind me to see other perspectives.  In the post I wrote:  “why should I write down things which I already know, for an audience I don’t? “

It was a light hearted comment but since then I’ve begun to really understand the value of writing things down.  It helps consolidate thoughts, and learn through feedback. I’ve also been incredibly gratefully for all the things I’ve learnt from blogs and talks, and glad that those authors did take time to share their thoughts.

I still don’t know what this blog is about, but it might just touch on building things, Agile and DevOps.