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”