This picture makes many people cringe.
In the software world, we repurpose many many tools from the manufacturing world. These tools, like PCDA, 6 Sigma, and Kanban have long, successful histories in the manufacturing world. Software people grab them because they work. But do they work as well in software? Sometimes. Sometimes they would work better with a bit of tweaking. Sometimes they are just not the right tool for what we are trying to do.
For example, how many projects are there that count defects per KLOC (thousand lines of code)? This was the predecessor to the 6 Sigma process we now have. It sounds like an interesting metric but, what does it mean? Should I be relieved when I get a score of 3.1 or concerned? If there is only 1 defect in total, I should be happy, right? Maybe. But what’s more likely; the case that the testing hasn’t “really started”, the coding efforts are much better this cycle, or that there’s something so catastrophically wrong with the code, that no one can test further?
As any aficionado of Tim “The Toolman” Taylor knows, “any tool can be the right tool.” GIs are notorious for repurposing tools. So are stoners, the incarcerated, and anyone who needs to do something “now” that they aren’t properly equipped for. Don’t believe me? When I taught at a “drop out high school” I was constantly amazed how quickly random items could be converted into pot pipes. It always amazed me how much engineering the students could do if they were interested in the outcome. And we usually squandered those abilities with “busy work.” But this is not a STEM education article. 🙂
Maybe our company have a rule that blocks our folks from doing effective work which they have to “work around” to get their jobs done. Maybe we don’t have the budget to buy/build the tool we really need. But could we “fab” (fabricate) something that would meet our needs? Will we allow/sponsor our employees to do that?
I once worked for a company that decided that we had too large of a backlog of Category 1 defects. All other work was to stop until the Cat1’s could be resolved. They installed a triage process to make sure only “important” work got done. Seemed reasonable. Except that we had hundreds of little “Cat3’s” on the books, too. These were projects that were mostly under 2 hours to fix and they would never, by definition, be worked on. And worse, it made our defect inventory look huge! My group developed a tool called “QuickPicks” which inventoried the Cat3’s and referenced them to larger work that was going on. The thought was that if you were working on a module to resolve a Cat1, you were to look at the QuickPick list to see if any of the Cat3’s applied to the same module and “just fix it” if the effort to do so was under an (arbitrary) hour of work. By time we got the Category 1’s under control, we had reduced the Category 3 inventory by about 50%. This was “free work” getting done to keep our business customers happy while resolving larger work. How much did it cost? A meeting done over several lunches where the team was b– er, “discussing” projects, a web-enabled Excel sheet (basically stored on an existing SharePoint site), and the willingness of management to let us present the tool to the development team and encourage them to use it. All-in-all, basically a “free” process improvement effort.
So what’s the right tool for what you’re doing? There’s a better question: What’s the purpose of the measurement or tool? What are we hoping to learn from it? Can we compare it to something else or take action based on the measure? Do we need to take action or is the information we’re gathering, well, informational? And can we display the information graphically so we can communicate it to the stakeholders who need to have it?
As engineers, we need to make sure we are properly equipped to complete our tasks. As engineers, we need to be involved in the improvement of our workplaces and industry. We need to feel like the metrics we collect benefit us and aren’t just “busy work” which has been “imposed” by management. As engineers, we need to take a moment to figure out what the requirements are, even for our tools, then check them to see if they are meeting those requirements. If they aren’t, we have processes available to us to improve the tools (or the requirements). Let’s use them!