MAY 2016CIOAPPLICATIONS.COM9systems, lack of test data and performance information cause people to take short cuts in design, coding and testing there'll eventually be quality and cost problems. · Runner in the crowd ­ a web developer is assigned some refactoring or documentation work, but doesn't want to be distracted from working on a cool new project. She knows that the release process is usually delayed, so decides to hold off on the updates; intending to slip them back into the next release at the last possible moment ­ it never happens. Some marathon runners have been cheated by casually slipping into the race from the crowd just before the finish line. This example is no different ­ release bottlenecks are causing bad behaviors, resulting in unnecessary technical debt and apps that are hard to support. · Nobbling the `competition' ­ a new autonomous agile development group ignores advice from the Enterprise Architecture (EA) team. In their minds the current architecture is too rigid and cumbersome, making it completely impractical to implement. By excluding EA they gain some immediate wins, but over time they start to encounter problems integrating and scaling applications; with many new reliability and security problems surfacing.People will duck, weave when processes and architecture are complex, inflexible and overgoverned. It happens when you have rigid change advisory boards, standardization dictates and many other procedural roadblocks, which while not necessarily wrong, are often out of step with agile and DevOps practices. In the short term these dodges and workarounds might seem fine, but watch out when they're accepted as "normal behavior" and start compromising the quality of applications.What's Your Cheat Score?To start addressing these issues build what's called a cheat index ­ a scale from the ridiculous to the sublime measuring our tendency to introduce practices that circumvent established procedure or sub-optimal technologies. Doing so requires taking a Gemba Walk leaf out of the Lean book; traversing your software pipeline and observing all your poor practices, elements of waste and people behaviors - up, close and personal so to speak.Next up begin linking and correlating this metric/score to your key indicators of performance ­ lead times, deployment frequency, and customer conversions and so on; gaining a warts-and-all picture of the business outcomes from cheating. Be prepared for some surprises because you never know - some cheats might actually be beneficial.Now enact a series of initiatives designed to improve your cheat profile. These could be as simple (or difficult depending on your perspective) as education and training, but most likely involve automation to remove any constraints, bottlenecks and waste that cause people to cheat. Then it's a case of `rinse and repeat' ­ assessing the impact of initiatives, adjusting your goals/targets, and finding more opportunities for improvement.Most people don't want to do the wrong thing, but they will when process and procedure works against them. Often the behavior isn't seen as wrong; it's just a "white cheat" needed to get a good job done. Any DevOps initiative should take this into account; examining the people factor at all times. Always consider that a culture is governed by behaviors ­ anything you can do to improve these will go a long way to increasing employee satisfaction and value. Peter WaterhouseMost people don't want to do the wrong thing, but they will when process and procedure works against them
< Page 8 | Page 10 >