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 \u2013 frequently and often. This was true of uniforms and conditions on a ship.\u00a0 Inspections instilled a discipline and a subtle message: we know, we care and we expect things to work well.\u00a0\nOn board ships that are at sea, there is a team of watch standers, each performing different roles and constantly monitoring the ship\u2019s 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.\nIn the technology profession, we tend to avoid issues we encounter in a project until they become major problems. \u201cThe project manager will handle that\u201d or \u201cI am just going to put my head down and code\u201d are some of the reasons why. If we truly care about delivering technology solutions that meet our customers\u2019 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.\nTransparency and variance\nModern 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\u2019t look for them, particularly in long projects.\u00a0\nHow do agile software methods help us overcome this? Quite simply, we inspect frequently and often to ensure that we are on track to achieve the desired results.\u00a0 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\u2019s 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: \u201cScrum employs an iterative, incremental approach to optimize predictability and control risk.\u00a0 Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.\u201d\nScrum 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\u2019t 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.\nCaring and delivering\nThere 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\u2019t pass a preflight inspection the issue is fixed \u2013 or they don\u2019t fly.\nSome 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, \u201cthe debacle cost the parent company billions of dollars, sullied its reputation and put roughly 17,600 people out of work.\u201d\nYou 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:\n\nAre you getting what you expect from your team, or are your customers consistently disappointed with your delivery?\nDo your instincts tell you that there are there hidden issues and problems that might end up derailing your project down the road?\nDo you know enough about the issues and challenges that your project is facing at a level of detail that allows you enough time to address them before delivery is delayed?\n\nSoftware projects don\u2019t 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.\nLooking for trouble?\nUndoubtedly 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.\nLooking for problems may seem counterintuitive, 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.\nPerhaps we should all be \u201clooking for trouble.\u201d Inspection is one proven way to find it \u2013 and to improve the value we bring to the organizations we serve.