Uncharted Waters

Oct 18 2017   3:03PM GMT

Real Process Improvement

Justin Rohrman Justin Rohrman Profile: Justin Rohrman


Process improvement in software teams seems harder to come by, and sometimes stops altogether, after the first few tries.

We see the exact same phenomenon in exercise. Take a person that has never done anything athletic in their life and introduce them to a barbell and a squat rack. For the first 2 or 3 months, they will be able to add 5 pounds to their squat twice a week. No problem. Toward the end of this progression, things get difficult and they have to play a mental game of pushing through something very difficult. Eventually, they just can’t put any more weight on the bar without reconsidering some things.

This exact same thing happens in software teams. And I think this is why the kaizen, or continuous improvement people, don’t see a whole lot of success.

I was at a local software meetup last night and the speaker was describing some ways to improve performance through a process change. When he (the speaker) got to this company, it was basically the wild wild west. It was very difficult to predict the flow of a code change from the time it was made to the time it was shipped to production. Developers may have been using version control, or they may have just passed files back and forth. By the time a change was ready to test, the developers were on to something completely new. So, the test group was on their own as far as learning about a new change or asking questions.

process improvement

The speaker was a manager at this company. He designed a new workflow, and added some process visualization tools in their bug tracking system. After people bought into the new process — developers were using version control, bug trackers, and were working in a somewhat predictable way — the company boasted 40% performance improvements, and 19% less customer reported defects.

Now, I’m not sure how they measured any of those things. The point is that they introduced something very basic and obvious, and felt like that change made a big difference. This seems to be the basis of nearly all performance improvement.

Take some large obvious problem, make nearly and effort toward getting better, and you will see large (though maybe difficult to measure) improvements. This is the domain of things like scrum, kanban, and BDD. Each of these tools takes a problem, teams not talking to each other for example, and then puts a framework around the problem. I was working at a growing company in the early 2000s. We had different products, and each products had groups of teams. At the base of everything was a company wide SDK that everyone pulled from. The teams, projects, and products were constantly stepping on each others changes. We used scrum as a way to force people to talk to each other. Pretty quickly the amount of rework caused by misunderstandings or just missed messages was drastically reduced. After scrum, we struggled to agree on the next important problem, and even more on how that problem should be solved.

Making these large novice improvements is a great thing. It takes teams from chaos, a place where turnover is high and everyone is teetering on the edge of burnout, to a place of repeat-ability. Moving past that is hard. Jumping past that initial improvement takes consideration of skills, staff, process, and tooling. The improvements also come much slower, are harder to detect, and are smaller.

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: