I am 100% certain that, on the day they asked me to manage at Minitab, they did not tell me that I would have to do so much process work. They didn’t clearly articulate that, as a Quality Assurance manager, I’d spend a considerable part of my time discussing how we develop software rather than actually developing software. Perhaps I should have known. A better engineer probably would have known. But, me? Nope, I didn’t see it coming.
Ok, fine. Dave Nelson (the head of Product Development at Minitab) may have said that I wouldn’t have as much time to test because managing does take a considerable amount of time. I vaguely recall a story about him having to come to grips with not being able to code as much. But he didn’t mention process. He definitely didn’t mention process. And, quite frankly, I assumed he was lying about the rest of it.
Eventually I realized my fate. And, of course I considered running away—who wouldn’t? But I was raised in the mountains of central Pennsylvania. And when you grow up in the mountains, you are raised to look disappointment head on, suck it up and power through. After all, I was in my late 20’s before I realized that Novocain existed. Trust me, we don’t run from pain. Of course, that’s mostly because no one tells us that “pain-free” is an option. But, that’s in the past; the point is that we learn to accept a little discomfort.
And of course I considered calling my family for support but I knew that our conversation would go something like this:
Me: “I really don’t know what I was thinking- I have to do all of this process work. I’d rather just test software.”
Family member: “Did you get paid last month?”
Me: “Yep.”
Family member: “Then suck it up. And, by the way, if this is your biggest disappointment in life, consider yourself lucky. Now excuse me while I grab a shovel and dig myself out of my house – we got two feet of snow last night.” (I also should note that I grew up not knowing there were things called snow blowers.)
Me: “Ok, Mom. See you after the spring thaw.” Click.
The harsh reality of process development
And so I accept that a part of my job is process. Development processes. Testing processes. Project Management processes. The Software Development Life Cycle, as we sometimes call it. Don’t get me wrong, I understand and appreciate the need for processes. I do. As organizations become larger and more complex, we need some safeguards to ensure quality. It makes perfect sense. It’s just that process work, like Novocain-free dental work, stole a part of my soul and I’m holding a grudge. That’s all.
Some background.
I learned about process while working in medical devices. And, where there are medical devices, there is process. And, rightly so, lots of it. If I were in an operating room, with one end of a medical device within inches of my heart and the other end attached to a power supply, I’d want to know that someone dotted their i’s and crossed their t’s. The medical device industry takes process seriously and I can’t thank them enough for that.
The soul sucking part came after I left medical devices. While every industry is different, the approach many (including myself) took to process was the same. The focus was on developing and following processes and sometimes that resulted in “process for process sake”. Essentially, we sometimes took our eye off the ball. In fact, we used to have a joke in manufacturing that you could build a solid, accredited quality system to support the manufacture of cement-life jackets and, well, you know where it’s heading. The fact is that process is good but “process for the sake of process” is bad. Very bad. If we aren’t meeting the needs of our customers—Game Over.
Customer Focus and Continuous Quality Improvement
And so I found my way to Minitab. At Minitab, our customers are our priority and we take it seriously. Very seriously. We also have processes and, like many companies, we’ve been guilty on occasion of focusing on it and forgetting the purpose of it all.
Towards the end of last year, I’d pretty much had it with process for process sake. You see, because of my many years of soul sucking process work, I have a pretty low tolerance for any process that doesn’t help us improve our ability to deliver. I had noticed meetings where we talked about how to implement process without a lot of talk about why we were doing it.
Again, my urge was to run away. But, I sucked it up.
So, what did I do?
I did what any engineer would do - I opened Minitab and I analyzed data. I studied quality data. Delivery data. Any data that could help me understand how well we were meeting customer needs. We develop software for our customers – that’s what we do. The only thing that really matters is how well we are doing that. Unlike a certain dentist I know, I’d like our customer interactions to be pain-free.
Here are a few examples of the data we analyzed (Note that some of the specifics needed to be removed but you’ll get the gist of it.):
High Risk Areas of Development:
I studied areas of the application with the greatest concentration of bugs. These “high risk” risk areas can be seen in the Pareto Chart below.
Source of Defects in the Software:
I studied the source of issues—how and when they were being identified within our Software Development Life Cycle. The Pie Chart below illustrates this data.
Types of Software Defects:
I studied the type of "bugs" found. The Pareto Chart below illustrates that data.
Results of Continuous Quality Improvement
After the data analysis, I brought a group of engineers together and we reviewed the results.
From that review, we identified some key improvements including:
- The implementation of additional reviews at key points in development
- More rigorous test and development requirements for high risk areas of the application
- Engaging customer-facing groups earlier in the development cycle to identify and resolve issues before their release.
These were all process improvements. There was no fanfare. No big process rollout. Just a group of engineers in a room talking about how to make software better. It reminded me of my manufacturing days and I liked it.
During those meetings, I gained a new appreciation for process. Process for the sake process is bad. But that doesn’t mean that process is bad. It’s all in our ability to analyze data and make good decisions.
I found that the key to process is that it should be developed within continuous improvement. Gather and analyze data. Then, make process changes that improve our ability to deliver.
We have one goal—to continually become better at developing software. Processes that support that—good. Processes that don’t improve that or worse, hinder it—bad.
It only took me 20 years; that’s not so bad. The result was only slightly more euphoric than the day I discovered Novocain.