A Tale of DevOps and Daring Do

7178026433_1c9565e716_khttp://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.

Advertisements

Inflicting Trust

everestladder-2

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?

The Final Countdown; Adjourning Agile Teams

5310895988_fbe55be401_o

www.flickr.com/photos/mbiddulph/5310895988/

When introducing agile  I’m sometimes asked to assist with the creation of teams, I’ll be asked questions like:  how many testers do we need?  Is ten people enough?  Who manages performance?  Should they wear shorts?  These are predominantly valuable questions, lucky covered at length elsewhere.  Something that’s very seldom planned is what happens when these teams disband.  And yet, without due care team members may end up demotivated, disappointed or feeling unappreciated.  In the age where everyone is fighting to retain smart people, and to transform their organisations, at the expense of a little forethought, it seems a high risk to take.

New teams are recognised  to move through similar phases, regardless of their domain.  Tuckman’s stages of group development is the ubiquitous cycle, suggesting that teams move through the following stages as they gel and become productive:
Forming – When a team gets together there is a buzz, there is expectation, and caution as they figure out their mission and their colleagues.
Storming – The team realise what they are up against, both from their mission, and each other, there is vying for position, conflict and resistance.
Norming – The team start to behave as more collaboratively, making progress towards goals, and developing team relationships, they are increasingly effective as a group.
Performing – The team is stable and performing its best, there is respect, understanding and a strong sense of shared purpose.

The sequence provides a useful heuristic for what to expect as a new team gets together.  Of course progress isn’t strictly linear, and teams iterate through these stages.  Something as simple a desk swap may prompt a little storming, with care though the overall trend remains towards performing.

Having studied and developed the concept, a decade later Tuckman added a fifth stage.  It is sometimes referred to as ‘mourning’ although I suspect that’s largely due to rhyme compatibility with the other stages, Tuckman named it ‘adjourning’.

Imagine this:  you go on a sunny holiday with a bunch of  new friends, sure the journey was a bit fraught, it took a while to get used to the new place, pace and lifestyle, there were some heated words along the way, in the end everyone is getting along, doing their thing and generally having a good time.  The holiday peaks when everyone gets together, sharing experiences and ideas, the energy is tangible.  Then one day you notice someone has left the group; “needed elsewhere” apparently.  Next day the hotel barman disappears, then you notice no-one is organising activities anymore.  The swimming pool is turning a curious green hue.  Two people wonder off because ‘there’s a more interesting holiday going on over there’.  The kitchen runs out of food – the chef is only there once a week, mumbling about “other priorities”.  The manager who used to stroll over enthusiastically and ask; “how can I help today?” now seems afraid to look you in the eye.  Slowly people drift off until the sense of fun and bonhomie are lost.  Triumphs forgotten, you kill time until the holiday reaches its end date.  A sense of loss and a slow fade to boredom becomes the overriding memory.

The adjourning phase in teams is important because it sets up the attitude, enthusiasm and levels of energy taken to the next team.  What is carried forward is largely based on the emotional response someone has looking back at the project.  The final weeks are particularly important because we are recent creatures, more recent negative experiences will replace older positive feelings.

Sensitivity to the adjourning phase is especially important during an agile transformation, and when introducing change in general.  In those early days a change initiative needs allies and evangelists to support and promote it.  Peer to peer recommendations are particularly respected, and people who have enjoyed a project help form a cohort of change agents.  The opposite is also true, word of a poorly handled team will soon spread, and be seen as part of the ‘new way’.

So you need to make sure that a team has a positive emotional response when they think about the project otherwise, regardless of what ‘facts’ or ‘reasons’ are given, it’s the emotional side that will determine whether a similar initiative is supported, or resisted.  I’d suggest the following:

Mark The Occasion – Lunch, cakes, a flaming aquatic Viking burial for the team board, anything that underscores that the project is done.  No need for speeches, but be sure to say thanks, recognise achievements, and just mark the last time the team exists in this form.  Often it feels more useful to do when the whole team can attend, rather than the calendar close date.

Close it down – Agree what work should be completed, rather than allowing that nagging unfinished, lost opportunity feeling.  Consider the tasks that will make it possible for other teams to work with product when handed over.

Retrospect – There are two motivations for this, firstly to gain learning and insight for future projects, secondly so team members feel like they’ve been heard and that things will improve in future projects.  A good option is to hold a ‘futureospective’ focus the retro on the future, asking each participant to choose a couple of initiatives they’d introduce to their new team.

Communicate – Often team changes are requested by outside influences,  it is good to soften the feeling that team changes are being ‘done to them’, especially in an agile environment which encourages self organisation and team responsibility.  If the team faces a slow wind down with people moving over a few weeks, explain why, ask for input into how the team’s remaining commitments and assets should be managed.  Again you’ll uncover solid ideas and increase engagement.

In the aspect of adjourning agile teams are no different to any other, except perhaps that they are expected to move through the stages of group development more often and more rapidly than their counter parts.  We should be mindful that our search of agility does not lead to disenfranchised groups and teams that never truly form due to prior poor experiences when disbanding.

Compared to the effort we put into forming a team the effort required for a successful adjournment is small, and the rewards are high; raised enthusiasm, engagement and even increased support for transformation.  So let’s not short change our teams, lets facilitate the closing phase of team life with as much thought and attention as the beginning.