A Tale of DevOps and Daring Do

http://www.flickr.com/photos/chodhound/7178026433

I recently read Phil Thompson’s great post around the value of story telling ‘Story telling in a business context’.  Reading it called to mind my favorite DevOps leadership story, but in a cautionary note Phil also talks about the dilemma of creating a tale to suit one’s own point.  He recommends a subtle caveat such as “It’s like that story where….”.  As it is so hard to authenticate tales from the past I’ll take that recommendation:  It’s like a story of daring do in the hay day of the industrial revolution…

The Avon Gorge in Bristol is a wide one and half-mile long valley cutting through craggy limestone on the edge of the city, in places it is almost a hundred metres deep. In the 1800’s engineer Isambard Kingdom Brunel was commissioned to build a suspension bridge across it, the chosen location was no less than seventy five metres high. Already the commission doubted Brunel’s calculations, forcing him to build two massive piers to narrow the span to two hundred and fourteen metres. Huge towers where constructed on either side of the river then ropes were strung across the gorge, followed by cables. After building sufficient strength, the plan was simple; a basket could be hung from an iron bar, allowing workers to cross with more cables and equipment. This approach would save long, expensive boat and land trips from side to side.

Everything went to plan until someone was needed to pilot the basket across the windy gorge. This was a time when trades had little protection, there were high injury rates, and workers were almost considered expendable. So when the work force were concerned about the safety of the basket, who took the job? It was Brunel himself. He made the first crossing, showing utmost faith in the design and trades that built it. In so doing Brunel set an example, demonstrated commitment, and earned the trust of the people he worked with.

I like this story, because it demonstrates the bold steps leaders (by which I mean anyone wishing to inspire or encourage, regardless of role or title) may take to gain support for new ideas and ways of working. This is particularly true of DevOps, Agile, Lean and similar learning methods – at first they might look different, maybe even as precarious as Brunel’s basket, but there are significant benefits to be found. Teams united by a purpose, and principles, are likely to discover those benefits, and learn, quicker than teams that are divided or fearful of change. Visible acts of leadership, and the stories that follow them, are as powerful now as they were hundreds of years ago.

This post was first published on the Kainos blog.

Anti Pigeon Holing or Why Leaders Should Consider Capabilities, Not Job Titles

Often during a DevOps or agile transformation, we demonstrate the potential of fresh ways of working with a single, pioneering team. Generally these teams produce solid results and there is a strong desire to scale the approach to more teams. This moment is something of a tipping point for the department, successful scaling leads to successful teams, leading to successful projects. How people are picked for those teams is crucial. A team’s make up is just as important as the practices it adopts; personalities, skills, experience and enthusiasm will all determine the drive, output and diligence of the team.

So how are teams created in your organisation? The easy way is to ‘do what we always do’: gather people finishing a project, or copy the template from the last team created, or maybe teams don’t change at all! Slightly more adventurous is to replicate the list of job titles in the pioneering team. These cookie cutter approaches may be successful, but only if the department is already populated by talented flexible individuals. However a little consideration will often yield better results, not just for the business but for the individuals in the team.

…for the rest of  post see the Skelton Thatcher Blog

Inflicting Trust

I often introduce teams to the notion of ‘inflicting help’, those well-meaning activities which deprive the recipient of an opportunity to learn, or practice.  For example, if I always helpfully facilitate retrospectives for a team, they will miss the experience of running their own. If someone helpfully handles all the build work for the team, ‘because they are best at it’ the team will not learn how to deploy for themselves.  This notion is of particular importance for agile and DevOps teams, as they cross skill, and share responsibility.

I also believe it is possible to ‘inflict trust’, that is give so much trust that it is detrimental to the recipient.  This idea may not be popular, how can it be plausible when the agile and DevOps communities talk so much about building trust?

Consider the following example.  It is day one for a new employee in the fictional organisation Great Western Widgets. At Great Western Widgets we deploy a few times each day, and we chase the Continuous Delivery Nirvana of making deployments boring. The new employee makes some code changes and is then is asked to deploy to production, following steps in the build book. “You’ll be fine, I trust you” says the senior engineer. Except things don’t go fine; the load balancer doesn’t route traffic away from the node that’s being deployed to, alerts don’t fire and eventually end users report multiple errors.
The new start suffers a massive dent in their confidence.  They are now far less trusting of their mentors, and apprehensive about battling a reputation for being ‘the one who broke production on their first day’.

In this instance the senior engineer was too trusting of the new start, they inflicted trust. In other, more severe situations, you may recognise this lack of support as a form of negligence. As leaders and mentors that’s something we should be wary of.  In addition to good intentions, it is often convenient (time wise or politically) to use the mantra of ‘high trust’ to expect others to do things, perhaps even things we wouldn’t risk doing ourselves.  Being ready to support, and if necessary rescue, those we are placing trust in is critical to creating an environment of safety, in which people are willing to challenge themselves. It is this feeling of safety that makes teams comfortable taking calculated risks, going fast and innovating. These traits are often seen to lead to high individual and team performance, not to mention a more pleasant work environment.

When encouraging learning and granting more trust, it’s often useful to consider various likely outcomes, if, when and how to step in. Doing the thing for the person is not an option, being ready, and available, to avert to disaster is mandatory.

One example is helping a child learn to carry a tray of drinks to the table, at some point they are going to just have to get on and try it, unless their parents want to follow them to every dining hall, café and pub they visit in their lifetime. So in that moment some steps are taken, almost without thinking; don’t use the best China, don’t over load the tray (you’ve just reduced the consequences of failure) and be ready with a tissue and some wise words if anything does spill (to encourage reflection and restore confidence). The converse, ‘inflicting trust’ would be to load up the tray with boiling hot drinks, fragile, expensive crockery put them into the hands of the wide eyed child and say “Off you go, I trust you”.

The key question to ask yourself is:  When you suggest someone tries something for the first time, which style are you using, supporting or inflicting trust?

There’s no script for agile – what can we learn from Improv theatre?

It’s always good to hear a new perspective on a seemingly familiar subject, it often provokes thought, inspires action, and encourages change.  Paul Goddard has introduced one such perspective on coaching teams in his book ‘Improving Agile Teams’.  There are plenty of books with similar titles, but the clue here is ‘Improv’ – the book shows readers how improv theatre techniques and games are of benefit to agile teams, both aspiring and experienced.  

I’m confident improv needs no introduction, the likes of Paul Merton, Josie Laurence and more recently, The Mighty Boosch have brought the art to the mainstream. Something you quickly realise reading the book is just how spontaneous improvisers are.  There are subtle cues, and openings the players use to both support, promote, and challenge each other.  Take a look at the expressions on the faces of Ryan Stiles and Jeff B Davis in the first minutes of this Improv-a-ganza clip, you’ll see reactions to unexpected events, and rapid adaptation to changing circumstances.

The idea of using improv techniques to improve team collaboration is an appealing one, the principles of agile and improv seem closely aligned, success in entertaining an audience and working effectively on complex, creative projects requires trust, collaboration, respect and a sense of play.

The book draws out five principles;
Safety – concerned with creating an environment in which teams (players in improv speak) can trust and rely on each other, supporting, encouraging, accepting failure and learning together.
Spontaneity – the business of developing an open mind, to increase creativity and receptiveness to others ideas.
Storytelling – as a method of engaging, inspiring and developing empathy, not just applicable to conversation, but also in user stories.
Status – identifying status, and manipulating it in a safe way to identify issues and further creativity and collaboration.
Sensitivity – the ability to sense, or listen and respond appropriately to others, in order to work effectively with them.

These are novel choices for what must, by extension, be agile principles, but the book explains the thinking behind these, and grounds them in current theory. For instance, in safety pointing out that absence of trust is one of the five dysfunctions of a team .  It’s nice to see Mihaly’s flow model get a mention too.

What I really like is that these principles are used to introduce a improv games and tips designed to further the maturity of teams.  These range from simple, everyday exercises that most teams would be comfortable with, to techniques that may challenge both team and coach.  It’s interesting to run through the techniques, and think “Could I run this with my team?”  if the response is ‘no’ then it’s likely attention to one of the five principles is warranted.

There are fifty or so techniques in the book, some quick and simple and great for livening up stale meetings (like conducting a stand up without using the letter ‘S’) while others require more time, and set to explore a particular area with a team.

One technique is ‘The physic Stand Up’, when team members aim to give someone else’s daily report.  I’ve seen this in action, and it’s fascinating, especially when vociferous people give reports on behalf of more timid people, there’s a strange mix of relief (that’s what I’ve been wanting to say) and shock (did they really just say that?).

I found the status techniques are particularly interesting, especially as it’s an area less explored by agile.  The Dinner Party game is aimed at understanding and recognising status, and the responses it elicits.  In brief, players are invited to an imaginary dinner party, split into two groups and asked to show either high or low status behaviors.  The groups then switch for the same amount of time before retrospecting on the experience.  

Sounds simple?  I’d suggest reserving judgement until you’ve tried some of the techniques, either in a safe environment or on the ‘stage’ of the shop floor.  There are great benefits to be found, experimenting with improv is both challenging and thrilling, the learning is definitely in the doing.

P.S.
In a similar vein, I’d highly recommend the book Artful Making, an unlikely collaboration been a Harvard Professor and a director/playwright.  It draws agile and leadership lessons from the world of makers, particularly experiences running a busy theatre and working with groups of actors.

An Agile Cambridge Reading List

Welcome to my not-entirely complete Agile Cambridge 2015 book list.  Why isn’t it entirely complete?  For starters, many books were mentioned in passing, Kevlin Henney in particular throwing out quotes and titles at rate so ferocious my free conference biro melted into wispy nothingness.  I’ve listed books which either cropped up in multiple talks or seemed interesting and novel (groan).  Secondly, the list currently captures recommendations from talks I attended – a fraction of the content across three tracks and around fifty talks, tutorials or workshops.  If you think I’ve missed any crucial reads do let me know, I’d be happy to include them.

In all cases I’ve aimed to link to the home site, rather than anyone’s favorite online re-seller

Mindset by Carol Dweck, on building a growth mindset to reach our potential.

Drive by Dan Pink, influential book on motivation, summarized at TED.

Thinking Fast and Slow by Daniel Kahneman, the source of the System 1 and System 2 thinking styles.

Eight Behaviors For Smarter Teams, and Smart Leaders, Smarter Teams by Roger schawarz, A PDF is available here.

Minimum Viable Book by Emily Webber & Amy Wagner, a growing collection of stories from people who create things.

Lateral Thinking by Edward De Bono, the inventor of the technique describes its value, and approaches.

Being Agile In Business by Belinda Waldock, primarily aimed at non-software businesses, but relevant to software organisations, introduces agile with practical methods.

A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware by Gary Gruver, Mike Young, Pat Fulghum.  This book has solid agile and continuous delivery content.

Build Quality In by Steve Smith Matthew Skelton et al (I’m one of the al!)  experience reports from a diverse range of continuous delivery practitioners.

More Agile Testing by Janet Gregory and Lis Crispin, they have a neat mind map of the book, in their words: “two world-renowned agile test experts ask tough questions about agile testing – and provide definitive answers”