DevOps and Deviance: How Bad IT Practices Become Accepted as Normal

peter waterhouse of ca technologies had a really fascinating article on what it can learn about the study of the “normalization of deviance” phenomenal which is worth a closer look.

waterhouse states that the devops movement, with its focus on collaboration across development and other it functions, is now regarded as the best way of establishing the culture and environment needed to support fast and reliable software deliver. so maybe the secret to helping it identify and eliminate poor practices is to take the benefits of devops and then guidance from other fields that are fighting normalization of deviance.

in healthcare, for example, studies illustrate seven factors that lead to a normalization of deviance, all of which are it relevant:

the rules are stupid and inefficient – in healthcare, accidents occur when practitioners disable equipment warning systems because alarms are seen as distracting. this happens in it all the time, like in operations where staff will filter out noise and alerts they regard as irrelevant. it also surfaces when testing is skipped because of manual processing and set-up delays.

knowledge is imperfect and uneven – employees might not know a rule exists, or they might be taught a practice not realizing that it’s sub-optimal. in it this persists because many new employees feel uncomfortable asking for help, or when the application of new technologies distort logical thinking.

the work itself, along with new technology, can disrupt work behaviors – to support goals of more continuous software delivery, organizations are introducing many new technologies and methods – like microservices and containers. new work practices and learning demands may lead staff to poorly implement technology or use it to perform functions it was never designed for.

we’re breaking rules for the good of the business – staff may bypass rules and good practice when they’re incentivized on faster delivery times or delivering new functional software enhancements. for example, repeatedly procuring additional (but unnecessary) hardware to rush through an update, rather than addressing the root-cause of performance problems.

the rules don’t apply to us…trust us – autonomous agile teams are beneficial, but empowering them to select their own one-off tools or to bypass compliance policies can compromise program objectives or lead to security breaches. unfortunately in today’s fast-paced digital business, talented professionals often feel completely justified in playing the trust card.

employees are afraid to speak up – violations become normal when employees stay silent. how many times has poor software code, costly projects (and bad managers) been tolerated because people are afraid to speak up? even in it organizations that have a strong blameless culture, people will stay quiet for fear of appearing “mean”.

leaders withhold or dilute findings on application problems – whether you work in healthcare or it, no-one wants to look bad to managers. rather than present ugly news, many will distort the truth; presenting diluted or misleading information up the command chain. in it this behavior is easily normalized, especially if teams get away with reporting technical vanity metrics over business outcomes.

no sudden cultural reawakening in it or liberal sprinkling of collaboration fairy – dust will eliminate ingrained bad practices, but devops and lean thinking can help identify warning signals. this starts with leaders visualizing the flow of value delivered by software applications, pinpointing all the bottlenecks and constraints impeding delivery.

analogous to pathway stepping stones, these are all the value interrupts which, when lifted, reveal all the process and technology issues causing good people to do the wrong things. immediate candidates are software release and testing processes, but don’t restrict analysis to the development side of the software factory. every stone, be that enterprise architecture, stakeholder engagement, vendor management, operations or customer support can hide ugly behaviors that over time can become normalized.

waterhouse says that identification is just the start. next comes the hard part, with leaders using evidence to impress how behaviors impact current performance and business outcomes. this might involve using new tools, but this again courts disaster when advanced technologies becomes a vehicle to automate bad processes.
read this blog on 5 things devops is not.

waterhouse concludes that as with anything involving people, the organizational and psychological barriers encouraging staff to break rules or for their colleagues to remain silent is where most attention should be focused.