I’m one of Opencast’s Scrum Coaches, here, I’m writing about “The Dirty Dozen, getting your scrum teams ready for the airfield”.
My first engagements with Lean and Agile came from Aircraft Engineering, where there was an extreme focus on safety above absolutely everything else. User needs, product value and the bottom line simply had to take a back seat to ensure that the people carrying out the work left the hangar at the end of the day in the same condition that they first arrived in.
For this reason, the perspective of decision making, organizing and continuous improvement had a much more savage (but more effective) dynamic, which made adapting to an office-based environment pretty tough. It turns out that when people aren’t always in imminent danger, businesses can (and usually will) place operational requirements above the human factors that go into delivering them. It’s harder to fix the human aspects of delivering work than it is to put your head down and do the work, so when there’s work to be done, it’s a great excuse for not fixing the interactions.
Agile in software, without explicitly stating this as an intention, does take some of that human focus and human value back, but, in the spirit of kaizen, there’s always more that can be done.
Human Factors is the practice of understanding human behaviour, psychology, anatomy and basic human physiology. It’s a mandatory module in a lot of mechanical and electrical engineering studies for this reason. This is often overlooked in software and process engineering despite a lot, if not all of the same risks to performance persisting.
One of the main things that’s considered on a day to day basis, when Human Factors is part of your everyday working life is the concept of “Compos Mentis” – being able to think or act clearly or responsibly and particularly “The Dirty Dozen” – 12 key factors that can inhibit this ability, particularly when working in a team.
“Working well both individually and in a team” is a popular line in most job applications, but this can go much deeper than simply being able to pair program without snatching control of the cursor off your teammate. In Engineering, where your life is often in the hands of your co-workers, this means being open about your own abilities, monitoring your teammates for signs of stress or injury, being aware of when everybody last ate, last rested…the list goes on! It also requires everyone to be comfortable with challenging the knowledge and capability of others, quite bluntly and objectively, without either party taking offence. This is just part of the everyday mindset for everyone in a workshop, whether they’re managing the team or the workload – everybody understands why and everybody has equal footing when pointing out the next potential risk.
At first glance, it may seem like a lot of these practices wouldn’t transfer well into an office environment, or may even cause friction, but it’s a level of team maturity that everyone should strive for and find the limits to, especially when it can lead to a better outcome for everyone.
Next time, I’ll be going through that “Dirty Dozen”.