Theory of Constraints and Lean

April 29, 2008 — Posted by Al Shalloway

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

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

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban