This post was written by John Clapham.
08:30hrs and already Pipeline Conference was buzzing, drawn together by an interest (in some cases obsession) with continuous delivery, getting stuff done, and a desire to improve, practitioners were gathering ready for the day’s talks. Pipeline is in its third year, distinguishing itself by being tightly focused and carefully curated. All talks except the keynote (Jez Humble, more on which later) are selected anonymously by a panel of experienced enthusiasts, leading to a healthy breadth of perspective and practice.
Jez Humble’s talk was based on his experiences with the Puppet Labs Survey, a yearly occurrence (event is more appropriate) in which the IT industry are asked to report their DevOps, Continuous Delivery and Engineering practices. The findings are well worth a look especially as the factors which drive IT performance are neither intuitive nor immediately apparent. Reviewing the findings it seems many organisations put their energies into areas which will not provide best return.
The survey adopts Ron Westrum’s model for culture. I appreciate this model for its plain intuitive language and simple structure which invites self-analysis. The ubiquitous model maybe applied to any group size, from single team to large department. The model is expressive, I find the sections on treatment of messengers (people who deliver ‘bad’ news) particularly insightful. Even in isolation they are useful indicators of overall organisational culture.
Consider spending a day in an organisation (even your own) and watching leadership behaviour, what would you see? In this context, by leader, I mean a person carrying influence and responsibility who should be displaying leadership behaviours, even if they don’t have direct reports or a job title to suit. Look at the reception leaders give to failure, delays and reports of service interruption. There are often two phases; the immediate response (In Westrum’s worst case messengers are shot) and the response once the dust has settled and the caffeine buzz has faded. In the latter case I would hope to see retrospection and a search for improvements. Missing these learning opportunities leads at least to repeated failures, or worse, a frosty reception to these opportunities being hidden or glossed over. Often there is a temptation to blame individuals when in-fact it is the system in which they work that needs attention.
The classic example of this kind of learning culture is Toyota, who rose to new heights by learning and adapting faster than their considerably better established competition. Toyota production lines used a system called the ‘Andon Chord’ – literally a chord to yank to summon a group for an improvement conversation, or mirco-retrospective. The chord is pulled by the operator if a fault is passed into her workstation, or if a fault occurs at the workstation. In Westrum’s language, messengers were trained. Toyota created a culture where the use of the Andon chord was positively encouraged, such that it soon became routine. Now, take a moment to mentally walk around your organisation, can faults be recognised? If so, what happens when they are? who is notified? How are they treated?
The flip side of the treatment of messengers is another predictor of IT performance, how the messengers, or rather employees feel about their work, sometimes termed employee engagement.
So what’s the link here? Why does employee engagement drive business performance? One answer is to look to Maslow’s hierarchy of needs, outlined in the diagram below.
The theory behind it is well documented, it may be paraphrased by saying “Take care of a person’s basic needs (the kind of things they would lose energy worrying about) and they will have more energy to put into work”. Of course for creative, thought work, it is mental energy that counts. We are more creative and better focused when we are not stressed, have a sense of safety and a feeling that we may take risks. If we think back to the messengers, which messenger is most likely to be productive, the messenger who has engaged in fruitful problem solving, or the messenger who feels they have been mentally shot?
So why is all this culture and management speak useful for Continuous Delivery? Progress towards Continuous Delivery is generally governed by four things; tech stack, tooling (including deployment and monitoring), architecture and organisational culture. Improvements tend to be an incremental process of discovery. Culture (which is entwined with employee engagement) determines how rapidly, if at all, those issues are dealt with when discovered. A learning organisation is an active organisation, adept at surfacing and making changes that drive it towards better performance.
I wanted to close with a reality check, especially for anyone wondering where to start. We can draw conclusions about cause and effect from survey data, much like we can observe that a sprinter who trains hard and eats right is likely to run faster. This does not mean it is easy to put into practice, or that we can copy verbatim, far from it, each organisation has its own unique challenges and context. Even with established agile practices Nokia Music’s change from a three month release cycle to around fifty deploys per day took over a year. At Pipeline Joe McKevitt spoke with refreshing honesty about his continuous delivery journey, and four years of hard graft to bring change. An expert, independent eye is often invaluable in discovering where to focus efforts, but what really matters is to know where you are heading, and make a start.
Skelton Thatcher 