I am 100% certain that, on the day they asked me to manage at Minitab, they did not tell me I would have to do so much process work. They didn’t clearly articulate that, as a 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.
Dave Nelson (the head of product development at Minitab) may have told me that I wouldn’t have as much time to test things myself, 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 after he became a manager. 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.
After I became a manager, I realized he was telling the truth. My first urge was to run away. But I was raised in the mountains of central Pennsylvania, where you are raised to look disappointment head on, suck it up, and power through. Trust me, we don’t run from pain. Of course, that’s mostly because no one tells us that “pain-free” is an option. After all, I was in my late 20’s before I realized that Novocaine existed. But that’s in the past; the point is that we learn to accept a little discomfort.
I considered calling my family for support, but I knew 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?”
Family member: “Then suck it up. And power through. 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—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.”
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. Really, 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 Novocaine-free dental work, stole a part of my soul and I’m holding a grudge. That’s all.
I learned about process while working in the medical device industry. Where there are medical devices, there is process, and lots of it. And rightly so—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 the medical device industry. While every industry is different, the approach many (including myself) took to process was the same. The focus on developing and following processes sometimes 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 that's heading.
The fact is that process is good but “process for the sake of process” is bad. Very bad. If we meet our process goals but we aren’t meeting the needs of our customers, it's still Game Over.
Customer Focus and Continuous Quality Improvement
And so I found my way to 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. Toward 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 initial urge was to run away. But, given my mountains-of-central-Pennsylvania upbringing, instead 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, and I’d like the experiences our customers have with Minitab to be pain-free. Unlike a certain dentist I know.
Here are a few generalized examples of the kinds of data we analyzed:
High Risk Areas of Development:
I studied areas of the application with the greatest concentration of bugs. The prevalence of these “high-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:
- Implementing additional reviews at key points in development
- Establishing more rigorous tests and development requirements for high-risk areas of the application
- Engaging customer-facing groups earlier in the development cycle to identify and fix issues before 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.
I liked it.
During those meetings, I gained a new appreciation for process. Yes, process for the sake of process is still 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 good process is developing it within continuous improvement. Gather and analyze data, then make process changes that improve your ability to deliver.
My team has one goal—to continually become better at developing software. Processes that support that goal: good. Processes that hinder that goal: bad.
It only took me 20 years to discover how good process can make the most difficult parts of developing software less painful. And that day was only slightly more euphoric than the day I discovered Novocaine.