Kanban is the japanese word for signalling card, but a signal for what? In the 1950s a Japanese delegation including Sakichi Toyoda (founder of Toyota) and Taiichi Ohno (on of the masterminds behind the Toyota Production System) went to
the United States to observe how Ford was mass producing cars. They were not impressed. During a stop at an american supermarket they witnessed how items were automatically resupplied once sold. The beauty of this concept was its ability to ensure a sufficient number of items was available to customers, without having to bind too much cash in unneeded inventory.

Reading the InfoQ newsletter the other day, I found that "Kanban is the hottest buzz since the dawn of XP" (eXtreme Programming). It is really so? Kanban is great for limiting queues of items with a certain level of uniformity - but does software requirements fit that? We certainly have queues of work that needs to be controlled - and requirements certainly can be described in a somewhat uniform way. The question really is - before implementing a kanban system to limit work-in-process, do you know for a fact that this is your biggest issue? I look forward to see kanban systems implemented in software development organizations where highly varying task size, complexity and context is addressed effectively.

By Sune Gynthersen

At a retrospective meeting with a client not to long ago, a really interesting point came up. The client had deliberately attempted to push a lot of feature work onto the development team, while keeping a fixed deadline - presumably to have the team work harder, and thereby producing more features before a particular deadline. Interestingly quite the opposite happened.

A total of 7 features were requested by the customer, while neither deadline nor scope change could be tolerated. The result? 7 features were reported done on the deadline. Unfortuately it turned out - in production - that only 2 was working as supposed, meaning that 5 was more or less defective.

When these numbers were clear to everybody an obvious question came up. Could the team instead have aimed for a total of 4 features (instead of 7), and actually completed 4 features upon the deadline (instead of 2)? Significant amounts of time had been invested in 5 features that were not completed anyway.

Who were to blame for this? The development team were only doing their best, trying to accomplish a goal not set by themselves. How could the client know any better? They did not know the kind of problems that are induced by using a push approach.

What the client and the development team had experienced was simple physics.

Little's Law:
Work in process = Flow time * Throughput

Little's Law describes the relationship between multiple key variables in any value stream (including software development projects)

What Little's Law says, is that - The more work you start, the longer it will take you to finish (given that your capacity/throughput is stable). Now imagine what happens if the customer asks for a fixed deadline - The amount of work that can be done before that deadline is indicated by the current capacity.

How about if we attempt to get higher throughput/capacity by increasing the amount of work, and asking people to work harder. Which variable do you think will be affected? ..you guessed right, Flow time will increase, as throughput (or capacity) does not increase magically over night.

I wonder how many people in the software industry are trying to outrun Little's Law, by putting pressure on the "floor" workers (e.g. developers and testers) ?

Lesson learned?
1) Don't try to run above the speed limit indicated by your current capacity. You will pay more and get less.
2) Favor pull systems over push - for instance as advocated in Scrum.
3) Never attempt to fix scope if you have a fixed deadline.

By Sune Gynthersen

The other day Danish newspaper Politiken had an article about how Toyota is renting a ship to store unsold 1200 cars in the harbour of Malmö, the Swedish town just across Øresund from Copenhagen. My guess would be that there's some hansei - reflection in Japanese - going on at the world's best manufacturer and the inventor of Lean. Obviously, Toyota has been producing to forecast and not to actual custumer pull. Some of the questions the people at Toyota probably could be asking themselves are these: Why didn't we sense the actual market conditions during the fall of 2008 and changed our production schedules? Why did we resolve to wishful thinking about customer demand? Why did we end up with overproduction? - the worst of Toyota Production System genius Taichi Ohno's seven types of waste in manufacturing.

When I saw the picture of unsold cars accompanying the article in Politiken I once again had the thought: Wouldn't it be nice if overproduction could be much more visible in software development? In much software development people are also producing to very uncertain forecasts without being in contact with the actual customer pull. And in software development the forecasts come in the form of big specifications of features that in many instances end up being delayed. And even worse, features not being used by the users when finally implemented.

If we had to rent ships to store all the implemented, but unused features, there might be some more hansei going on to avoid implementing those features in the first place?

By Thomas Blomseth

Maybe you have made some great improvements in your software development organization in 2008 and now it might be easier to reach the expected milestones and get value out to customers/users in a faster way. You might even have introduced some Agile or Lean practices (maybe Scrum) and started to work in a more iterative rhythm with increased collaboration and feedback.

Don’t relax and think it is good enough, because it can be so much better!

When your teams and individuals on a regular basis starts to search for new and improved ways of doing their daily work, you are moving in a direction, where more of the sleeping and hidden potential of the organization gets activated. When people get used to the rhythm of continuous improvements with regular retrospectives, instant kaizen events etc., they will start learning to see some of the candidates for removing wastes and be more efficient. 

Continuous improvements with a structured and constant improved process to find the most important candidates to improve, is key to more business success in your organization and it is essential for you to do it better than your competitors.

It is not only about improving development practices in your development team, because you might just sub-optimize areas with lower impact and poor ROI. Off course you can get a lot of value by having an efficient development infrastructure and teams working with automated testing, emergent design etc., but the bottlenecks might be in the value streams involving people outside development. Working on the right prioritizes with enough knowledge of the business problem, so you can make a simple and optimal solution, often requires an efficient collaboration between business the development team and here might be candidates for larger improvements.

Unfortunately I know of many teams and organizations not doing any kind of regular improvement activities in teams, projects or on a department level. That’s a shame, because they could do it much better and be much more competitive with an improved bottom-line in the company.

So start doing continuous improvements as an individual, in your team or organization, and you will over time learn to see what is really blocking you not to do it better. Just keep in mind that it can take some time and there are a lot of different techniques to get into the root cause of the problems, so you can focus on the constant and sustainable small steps with the largest impact.

By Mads Troels Hansen

Believe it or not -- I saw this question posted dead serious at LinkedIn the other day. It made me think, we need to spend more efforts on training everyone to see the negative impact of individual performance measurements.

Have you ever been in an organization where testers were praised for no. of defects found? Though it is harder to measure, wouldn't you agree that it would be more useful to praise people for "no. of bugs that were never introduced due to close collaboration and mentoring of developers"? I need to emphasize that the latter is of far greater importance than the number of bugs discovered.

And here's the important part -- Doing individual performance ratings will seriously constrain peoples innovative abilities, and thus their abilities to do real value stream improvements. In addition, individual performance ratings will encourage people to NOT help each other, even when it is clear it will be of greater benefit for the company.

Promise me you won't do it

By Sune Gynthersen