Eight weeks ago I was asked to present at the 5th annual Experience Agile conference in Lisbon, Portugal on 1 October because the organisers had seen what I had been posting on LinkedIn about non-technical skills, specifically teamwork and decision-making, and how this could also apply to Agile working to improve productivity and effectiveness.
Agile working is the concept of letting a team of experts understand the problem, identify what needs to be prioritised within the backlogs (list of actions to be completed at ‘sprint’ and ‘product’ level), come up with a plan to create something in the next ‘sprint’ (a finite period of time, normally 30 days) and then undertake a review and debrief before moving onto the next sprint taking the lessons identified/learned to improve outputs in the next sprint.
The key to an effective sprint is to have a group of people who are operating as an interdependent team, who can speak up and challenge when needed, who trust each other to do this, and all with the aim of ensuring the clearly articulated goals are met given the resources and constraints they have.
Agile is about being an effective team, but unfortunately, effective teamwork isn’t really taught in companies. How do you expect a team to operate if an organisation hasn’t taught the team how to build trust and collaborate? Or how teams communicate in a caring and challenging manner which reduces ambiguity and confusion? Or to understand and recognise the cognitive biases which influence decision-making? That is what my presentation was about.
“Moving from Known Knowns to Unknown Unknowns and the need to embrace failure.”
The presentation I gave looked at how in the ‘known known’ space, most things are relatively linear in nature which means we can develop processes, procedures and rules which can be followed as the ‘cause and effect’ process is relatively simple. However, once we start moving into the ‘unknowns’ then we need to start making use of non-technical skills, learning from experience, resilience and creative thinking if we want to be able to deal with uncertainty.
I did this by showing examples from a number of different domains I work in or where failures can be critical.
Unknown Known – Things that are right in front of us but we are unaware of. An astronaut who forgot to put the SD card in his GoPro (https://www.youtube.com/watch?v=8IRWC4P-U4c) and despite years of training, neither he nor the mission control team knew what ‘No SD’ meant on the display. A trigger to indicate something wasn’t right was that the red flashing light associated with recording wasn’t flashing like it normally did.
Known Unknown: Areas we do not yet understand but know to explore further. A surgeon who nicked a major blood vessel going into the liver as they were trying to remove a tumour and caused a situation which, had the anaesthetist not picked up on the proximity of a tumour to the major blood vessel during the ‘Sign-In’ process (which was facilitated by the WHO Safe Surgical Checklist) and consequently ordered lots more blood for the theatre, the patient would have died.
Unknown Unknown: Things we don’t yet know are a possibility. A cave-diving colleague of mine who was exiting a submerged cave system they had been exploring was transiting through an area of really poor visibility. He was following the guideline ‘blind’ using touch as he couldn’t see where to go. The line then went down into the silty bottom of the cave until he couldn’t go any further as his shoulder was now touching the floor of the cave but the line was still in the soft mud/silt. He then had to make some decisions which meant he let go of the line and had to use best judgement as to determine where the line would come out on the other side of the silt. He had to keep calm as he was no longer able to determine which way was out. if he managed to swim in a straight line while not being able to see which way to go. After a couple of attempts, he found his way out. In hindsight, he realised he could have solved the problem a different way but given his cognitive tunnelling, this option wasn’t available in real time.
In each of the cases, effective debriefs which looked not just at the outcomes and the technical skills but also included non-technical skills, meant that true lessons could be learned, not just identified. For an effective debrief to happen, everyone must be in learning mode and not blame mode - this is hard if products are not being delivered in a timely manner.
The final part of the presentation was about how to innovate in VUCA environments. There is a need to be able to create systems where we can fail safely and practice failing. Dave Snowden, who joined the high performance team workshop Brian Rivera from AGLX Consulting and I were running the following day, highlighted that the military, especially the military aviation community, spend 99% developing and 1% doing, whereas in industry these numbers are often reversed so there isn’t an opportunity to learn to fail in a safe manner. However, it is essential that non-technical skills and learning to fail are developed in the industry so that learning can really happen, not just have lessons identified.
I would recommend anyone in the IT industry who reads this and wants to improve their team and organisational learning read ‘Beyond Blame’ as it describes the journey of an IT company who have a disaster and fire the ‘last person to touch the system’, however, they realise that the world is complex and that same person was also the only person who could help unlock the reasons why the failure happen. Ninety minutes of your time well worth investing.
The second day I co-facilitated a high performance team workshop using the GemaSim computer-based simulation which has been developed specifically to create an uncertain, complex and ambiguous environment which requires closed-loop communications, sharing of mental models, decision-making under uncertainty with clear leadership which maintains the clearly articulated goals at the start of the mission, all in a fun and engaging manner. The 24 team members were split into two groups which then changed over during the day. One was a GemaSim session run by me, and the second was a debrief and behavioural marker scheme session run by Brian.
At the end of the day, we then had a wash-up and Q&A session with myself, Brian, Dave Snowden from Cognitive Edge and author of the Cynefin framework and Nigel Thurlow who is the Chief Agile Officer for Toyota Connected (Toyota Production System) in which some great topics were discussed.
This was my first exposure to the Agile community. In fact, I walked onto the stage and said “I know nothing about the Agile community and have had limited contact with IT teams, however, people are people and these concepts are applicable in the many domains I operate in, healthcare, oil and gas, high-risk dive teams and the corporate sector, only the stories change.
My takeaway was that there are some amazing opportunities out there for teams to improve, to apply the hard-won lessons from high-risk industries and apply them to the Agile community, but there needs to be a recognition that change isn’t easy but the rewards are certainly worth it. Learning and applying non-technical skills is not a ‘sheep-dip’ approach to performance development. It takes time and that means leaders need to invest and innovate if they want to succeed. Innovation leads to failures. But you can fail safely, as long as you have the right mindset that goes with the need.