“Yet study after study, analyst after analyst, say that developers are making the same mistakes they made in 2000. That they made in 1990. And earlier.” Stop making the same old mistakes, SD Times, Oct 2011.

This quote brought to mind a Google TechTalk on Scrum I watched some years ago. One of the founders of Scrum was answering questions about this software development management method. What was most fascinating was his examples of some of the things that typically go wrong in an implementation. It included not following close enough the Scrum process and not believing and using the numbers that represented the team’s performance (e.g., velocity metric). Gee, I recall thinking, that could describe just about any team struggling to implement any new method or technique.

The editors of SD Times in their article go on to describe different approaches to help people stop making the same old mistakes. This included the automation of tasks and other tools, “teach, inspire, wheedle and cajole programmers” to not introduce errors in the first place, and reward programmers for coding things right the first time. Again, I don’t see much new here. These are management techniques we’ve known and used for years. Have we not been using these? The editors of SD Times don’t address if any of these suggested techniques are actually known to work well or not (i.e., no “study after study” reference in the article).

What might really be going wrong? Was it those programmers consistently doing subpar jobs or was it management motivating those programmers with subpar techniques:

• “Get it done by tomorrow!”
• “Here is more to do, but no you don’t get any more time to do it!”
• “We need to improve testing to catch all those errors!”
• “Today we’ll do Scrum, tomorrow Lean, next week Kanban, then we’ll try out TSP and if that doesn’t straighten out the programmers, we’ll reintroduce Waterfall!”

So, is it the computer programmers (or any individual contributor) or is it management or is it both?

As much as saying “it is both” would be safe, my experience puts the problem directly in management’s lap. I always loved the notion by Dr. Edward Deming that “management owns the process” and the Software Engineering Institute’s often stated corollary that the “quality of the process determines the quality of the product.” So does that mean the solution is for management to take charge and fix things? Not necessarily. In many cases, the solution may be for management to back off micromanagement and instead empower the folks doing the work to improve based upon their own insights and knowledge. Management stays involved but is focused on helping these teams to be self-managing AND by providing overall strategic direction.

My career in helping organizations to improve has been successful in large part because the folks doing the work generally knew how to do a good job. When we removed the impediments to doing a good job, which were generally bad management habits, the existing teams dramatically improved in quality and productivity. It was also the case that once we reduced the bad management habits existing improvement efforts started to have an impact.

Does that mean we don’t need to help the individual contributors do a better job? No, of course not. But very often in my experience the “low hanging fruit” for rapid improvement is centered first on management practices and then on methodologies and individual practices.

Our improvement projects can make a huge difference in the performance of our organization if they help folks to stop making the same old mistakes. Just include in our thinking that removing management bad habits can have as much — if not more — an impact on performance than just trying to fix all those mistakes seemingly made by our individual contributors.

What same old mistakes can you see that your team or organization is making?