Theory of Constraints

Theory of Constraints

Image Source: chuansong.me

I recently attended a meet-up where one of the presenters spoke about Theory of Constraints. While a lot of us use this term, only a few truly understand it and can put it to good use. Luckily for me, the presenter was one such person and did a great job at explaining it to the audience. As he went along explaining the paradigm to us, I couldn’t help but notice how nicely it fit with the Agile and Lean philosophies. This blog post is about that connection.

But before we go any further, let’s first understand what ToC is. The website for Theory of Constraints Institute describes ToC as a way of identifying and managing bottlenecks that restrict the entire system’s output. It is a set of management tools devised by Dr. Eli Goldratt and introduced in his book “The Goal”.

ToC says that, at any point of time, there is a single constraint throttling the system. Eliminating/ easing this constraint improves the output. You then have to evaluate the entire system again to find out the next constraint. Rinse and repeat.

The above has an interesting corollary. An hour lost on the constraint is an hour lost by the entire system. However, an hour lost on a non-constraint is no loss for the system overall. So when we continue to improve something and still wonder why there is no improvement with the system at large, possibly we are trying to optimise something that is not the constraint choking the bigger system. Yes, we might still end up improving a sub-system but local optimisations do not help the larger scheme of things.

Eli structured the following 5-step process for ongoing improvement:

Theory of Constraints

Image Source: Theory of Constraints Institute

When we get bowled over by methodologies like Agile, Lean, Six-Sigma, etc., we forget that these methodologies primarily help to Elevate the Constraint (Step 4). Some of them might also contribute towards other steps but we still need to perform them.

Faster is Slower

Hourglass

We have all read that story during our childhood where a fast rabbit (or was it a hare) was beaten by a slow, yet steady, tortoise. The importance of sustainable progress was taught to us well in advance but we forgot the lesson while growing up.

We are so rushed about everything that we have forgotten the pleasure of enjoying the moment. Hang on, this blog post is turning into a lecture on “living in the moment”. Well, that’s not what it is going to be. It’s going to be about the challenges I have been facing with some projects while trying to match an aggressive timeline set by the client.

At present, I am managing two projects for a client based out of Nigeria. One of the two projects is a daily-deal web application and the other is an e-commerce site. Both these applications are doing fairly well and generating a sizeable revenue to the client. And the company I work for is happy too, well, at least financially.

But these projects are becoming a death march despite my desperate efforts to the contrary. (I didn’t know Wikipedia had a page on death march in project management).

I can see the development team working till late everyday. The code quality is going down. Time is being spent more on fixing bugs than writing features.

My initial thoughts on this state were that perhaps the team is doing a shoddy job, delivering poor quality work that too late. Which is why they are having to work late to meet the deadline. But I was wrong. Mea culpa.

The whole problem is with the deadline. The word has actually begun to signify a point in the future beyond which lies death.

The whole situation starts like this: the client has a brilliant idea (every month or so) that needs to be taken to the market immediately. The team is expected to start coding even before they have a firm grasp of what they are working on. All this can still make sense as Agile is meant to allow, in fact welcome, frequent change. But not when all the 3 sides of the iron triangle (scope, resources, and time) are set by the client thus strangulating quality that lies within the triangle.

The developers (considering themselves a part of the same team as the client and equally responsible for its success) agree to the deadline often factoring in extra hours in a day and a few Saturdays. Even at this juncture everything looks possible; a stretch goal but possible.

While they are in the middle of the release, suddenly a mail comes announcing some hotfixes (a fix or a quick feature that needs to be deployed to the production site ASAP and has priority over current release / features). The team, again feeling responsible for the application, does those fixes. But the tragedy of this whole story is that the darned deadline doesn’t move a minute!

Mike Cohn, a highly respected writer, speaker, and practitioner of Agile, wrote the following in his book Agile Estimation and Planning:
Leave some slack. Especially when planning an iteration, do not plan on using 100% of every team member’s time. Just as a highway experiences grid- lock when filled to 100% capacity, so will a development team slow down when every person’s time is planned to be used.

This is where we are going wrong. Not only we factor the full eight hours per day of each team member, we also include a couple more so as to meet the deadline. Which is why we never have enough time to write good code in the first place, do a thorough code review, or test the app well. In some cases, unit tests are skipped altogether so as to deliver on time.

This is why I have begun to realise that in trying to become faster, we have become much slower. While we somehow manage to deliver on schedule, a lot of issues that should have been taken care of before releasing to production are looked at after the release. Thus the point of stability moves to well beyond what could have been a justified release date or the deadline with a reduced scope. And it causes heartburn to everyone: to the users who face issues due to buggy code, the client who faces user’s complaints, and the dev team who work day-in day-out.

I have actually experienced an automobile analogy of the above. I had to meet someone at a destined place and time. In order to avoid being late, I rode my motorbike much faster than I normally would only to get into an accident. The meeting got cancelled, my motorbike got damaged, and I got hurt. Faster became slower and expensive.

Considering the software context again, the client frequently gives the example of Apple as a benchmark of quality. However, in trying to attain that benchmark, I would not let my organisation become Foxconn. The team has had enough and I have had enough. It’s time to take a stand even if it means like the one below:

Hold Strong

Image Source: http://www.wsm.ie

Game On!

“Well served!”

“Nice spin!”

“Just missed the net!”

“Deuce!”

These aren’t the standard phrases that you would expect to hear at a development company.

But at VinSol (the company I work at), you would hear them many times a day!

Ever since we got a new Table Tennis table, 60 minutes of game play has become a part of our daily routine.

To the average manager / employer, it might seem as a waste of time.

For those who are truly looking to get the best out of their team, this is just what the doctor ordered.

I have seen productivity rise both before and after the game play.

While teams work diligently during the day knowing that their day is shorter by an hour; after the game, they carry the high energy levels to their desk and work with the same zeal they show when trying to win a point during the game.

Not to mention the camaraderie it generates while playing together.

Also, I found an interesting pattern with the teams who are playing regularly.

The sportsman spirit they show during game play is also reflected in their work.

We use Agile frameworks like Scrum and XP to deliver the great work we do.

These frameworks have mature individuals as their cornerstone.

I have seen sportsman spirit transforming into maturity while working with these individuals.

Besides, daily game play also takes care of one’s fitness aspects thereby relieving one of his computer and chair and allowing one to relax his mind and exercise the body at the same time.

I believe that writing good code is an art, not something that can be inculcated by merely reading books and online tutorials.

If we expect such creative skills from individuals/teams, then even we need to think out of the box on how to inculcate such skills in them.

At VinSol, the new TT table was the one of such solutions.

Game on pal!