One of the profound findings during the productivity improvement era of the 20th century was the notion that if we focus on productivity, we improve productivity a bit, but if we focus on quality, we improve productivity a lot. We can often vault our team or organization to the next level of performance just by doing nothing more than what we are currently doing, but with a renewed commitment to quality.

The Project Management Tool’s “First Time” approach, in particular, was a handy method to get everyone to focus on lean like activities. We drove down the wasted time that occurred in multiple compiles and multiple test executions. Besides resulting in very few defects getting into the software, we experienced a secondary effect that was unexpected, but obvious in hindsight.

When programmers spent less time fixing defects, especially those found by formal testing and by the customer, they had more time to work on their next software assignment. As quality went up, our productivity skyrocketed. In Is Your Project Management On Steroids – Maybe You Should Kick The Habit, I referred to a Monte Carlo analysis that I had done that suggested we could fix our backlog of defects over a two year period. Well, we did. But we also delivered on a flood of new requirements in that same period that were requested when our customers saw that we were finally successful at delivering quality software on a timely basis.

It is amazing what happens in an organization when programmers start to deliver code that simply works the first time. The entire character and dynamic of the organization changes. We discover that many of the process steps in the development life cycle were only there in reaction to a history of defects and re-work. They become unneeded and the time spent doing them often vanishes or becomes completely irrelevant, even as we continued to do some of them through habit.

Strangely, there are often negative consequences to successful quality and productivity improvements. In the article, Want To Stress Your Test Team? Give Them Good Quality I mention how software test organizations, organizations with a vested interest in having defects in a product, reacted in often negative ways to significant improvements in software quality. Few improvement efforts, even successful ones, happen without some internal resistance that must be managed.

A focus on quality will provide a boost to productivity. It is often a bit counter-intuitive, as a renewed quality focus will often require more time upfront as the team focuses on doing it right the first time. This focus, however, will pay off over the long term with fewer defects and less re-work in the future. This will, of course, work for any activity, not just software development.

Do you have examples where a focus on quality made a difference in project productivity?