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

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.

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?

Footnote:
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.”