As a young naval officer, one of the recurring themes that was instilled early on was that you will get what you inspect. The way to get good results was to inspect things yourself – frequently and often. This was true of uniforms and conditions on a ship. Inspections instilled a discipline and a subtle message: We know, we care, and we expect things to work well.
On board ships that are at sea, there is a team of watch standers, each performing different roles and constantly monitoring the ship’s condition, location, seaworthiness, and battle readiness. If you want to be sure that sailors and ships are ready to perform their duties, inspect their condition. Watch, observe, and carefully note when things change. It is much easier and more desirable to solve issues when we identify them, rather than allowing them to grow into larger problems that threaten battle readiness.
In the technology profession, we tend to avoid issues we encounter in a project until they become major problems. “The project manager will handle that” or “I am just going to put my head down and code” are some of the reasons why. If we truly care about delivering technology solutions that meet our customers’ needs on time, we need to address issues when they arise. Otherwise, we are just irrationally hoping things will go our way, and that the issues will not cascade into a death march.
Transparency and Variance
Modern software projects, like ships, can be extremely complex. One of the failure points in software projects is that all too often we cannot see when things change for the worse. Problems are frequently hidden and linger because we don’t look for them, particularly in long projects.
How do Agile principles and techniques help us overcome this? Quite simply, we inspect frequently and often to ensure that we are on track to achieve the desired results. Inspection is one of the three pillars of scrum and is an important underpinning of why Agile methods work. These ideas are not new. Many can be traced back to W. Edwards Deming, who was an American engineer, professor, statistician, and management consultant. During the post WWII years, his ideas were widely credited with Japan’s rise from the devastation of war to becoming the second-largest economy in the world. He championed what is known today as Plan-Do-Check-Act (PDCA) as one of the principles of modern quality control. This is an iterative process, and one of many precursors to Agile processes and scrum. The Scrum Guide says it this way: “Scrum employs an iterative, incremental approach to optimize predictability and control risk. Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.”
Scrum or Agile processes insert inspection as a key discipline into every technology project. With the team looking at variances every day and measuring their progress, issues or obstacles are identified on the spot. When we find them, we shine the bright light of day on them, and we make everyone aware of them. And, as a result, well-run Agile and scrum teams experience much higher rates of on-time delivery. We don’t wait on problems, issues, or obstacles to snowball into larger ones that lead to costly delays. We go out and find them, address them quickly, and move forward based on the best information available at that moment.
Caring and Delivering
There are many other examples of things we inspect regularly when performance is important. Fire departments inspect their equipment daily because it is safety critical. Medical devices have a regular inspection cycle. Passenger aircraft have regular inspection cycles, and if they don’t pass a preflight inspection the issue is fixed - or they don’t fly.
Some might object these examples are not fair to compare with technology delivery, as delivery of technology is not as important. Ask yourself the question: Why is this the case? Companies today fail or succeed based on technology delivery. Sometimes, as in the case of the failed launch of Target in Canada due to supply chain and software project failures, thousands of jobs are lost. In the case of Target Canada “the debacle cost the parent company billions of dollars, sullied its reputation and put roughly 17,600 people out of work.”
You may not be working on a project the size of Target Canada today, but undoubtedly it is an effort that is important to your organization. It might be good to do a quick mental project inventory and ask:
Software projects don’t fail because the technology we use is faulty. Code compiles and performs in a predictable, consistent manner. The tools we use in technology perform as advertised and deliver predictable results. We must provide the intelligence and expertise to make them work correctly, and this includes being prepared for the inevitable challenges that arise.
Looking for Trouble?
Undoubtedly there is a lot of complexity and uncertainty to manage in technology projects. Business demands change, scope creep is constant, and expectations are often high. We need to step up and lean in when things begin to go wrong, rather than relying on ways of working that mask issues until they are delivery-impacting challenges.
Looking for problems may seem counter intuitive, but high-performing teams make a practice of it. They have learned that the way to avoid trouble is to aggressively seek it out, identify it, and remediate it as early on as possible.
Perhaps we should all be “looking for trouble." Inspection is one proven way to find it – and to improve the value we bring to the organizations we serve.
Matt blogs regularly on digital transformation and Agile at Genesis10.com. Please read his blog
Let’s continue the dialogue: Subscribe to the Genesis10 blog.