This blog is somewhat of a response to a comment on my JIT blog.

I really like The Goal and think the Theory of Constraints (TOC) is brilliant.   I believe it can be applied to software development in two ways.  One is very valuable and the other must be dealt with with great care.  First, the one to be careful.

The main lesson of TOC, in my mind, is that you must optimize the whole when making changes and not merely improve one part of the process.  In manufacturing, finding your bottlenecks and how they relate to other steps is a bit easier than in software development because you can see where your inventories are building up.  You can also track errors a little more easily. 

Attempts to use TOC to improve the process within a group often does two things.  It somewhat assumes that the process is stable enough to use TOC on and it overly focuses on the group.  Processes need to be flexible and a micro focus on a process may be inappropriate.  However, if TOC is used on a team’s process, then you have focused on a sub-step already – and are not using TOC properly.

Using TOC in software development is most useful when one takes a bigger look at things.  I have discovered that for many companies, where they think they have a problem is not really where the problem exists.  Net Objectives got into analysis and process training years ago after we’d been doing technical training for a couple of years.  A particular incident made us switch from a technical training company to a “improve the organization” company.  We had done several design patterns courses at a company at their request.  At that time, if someone wanted technical training, we delivered it. Now we look to see if that really their problem.  Anyway, on a chance meeting with a team lead of the company  several month later I realized that although the development was being blamed for delays (“they had it last”), the real challenges in the organization were poor communication between the software and hardware teams (the hardware team was the customer here).  Therefore, although we had done great technical training at our client, that wasn’t their bottleneck and I hate to say it, we hadn’t really improved them as a development organization.

Since then I’ve seen many cases where the group that is struggling is struggling because of:

• The impact of another group’s ineffectiveness
• Process issues over which the group has little control
• Enterprise issues that the group has no control over
• Interactions with other teams that they don’t know how to deal with

As people are getting better at writing code and better at Scrum these issues are becoming more and more rampant.  Part of this is because the other constraints (code quality, testing, team process) have been helped quite a lot by patterns, TDD and Agile/Scrum.   Thus, the constraints have shifted from within the team to between the teams.

Unfortunately, many thought leaders, particularly in the Scrum arena, are not wanting to go outside of the box and look at how to go beyond the team.  Team interactions are starting to become the constraint of organizations.  Simply saying – have your teams figure out how to solve these problems – is happy thinking.  People need to be provided with tools to help. 

You probably know my thoughts here already – Lean Thinking.  Probably more on that later.

Alan Shalloway

Technorati Tags: Lean Managing Lean-Agile Scrum

tag with del.icio.us