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

A task board has been used by many teams when doing Agile development to have a shared place to manage tasks in the iteration.  I have used it myself in a lot of different formats when working with R&D development, customer projects and also working together with offshore teams.

It can be a great tool for the team and creates more collaboration, feedback and risk mitigation when having a visible task board.

But, you might also have more frequent requests from other teams or customers and maybe you also work with maintenance tasks of existing products in production. It can be challenging to combine focus in the iteration with different ongoing requests.

One alternative approach to the traditional task board and iteration planning can be a Kanban system. Kanban is the Japanese word for visible card and originates from the Toyota Production System. It is used to minimize inventory, enforce Just-In-Time and eliminate waste.

I have used the Kanban approach to extend the traditional task board with limits on the number of concurrent tasks in different states to reduce work in progress and apply a more pull oriented process. When working with many different specialists in one team, I have also seen high value by extending the board with more states to manage the work of the different specialists. It makes it much more visible and easier to follow the flow and find wastes in the process.

In one team we combined the Kanban approach with a two week release rhythm and that enabled the team to both have a rhythm of planed activities and also do more frequent business requests depending on their capacity and the business prioritization.

The combination of the more traditional iterative processes together with a Kanban approach is very interesting, and I think many teams and organizations will find a lot of value and increased productivity looking into this area.

By Mads Troels Hansen

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

By Bent Jensen

Some thoughts that popped up on my first day of attending our Poppendieck course on 23th of June.

Knowledge inventory

The concept of “Zero Inventory” is not desirable and in fact does not hold in Toyota (go to the production plant and notice the trucks on the park yard outside the factory with inventory waiting to load it into the factory – the drivers are sleeping some times), its all about having the correct amount of inventory.
So! Mary keeps a log book containing what programs she installed on her laptop and what problems she experienced (hope she doesn't mind me telling this in public). When there is a problem on the laptop, she goes to look into the log book instead of googling it again spending time on finding the same site as 6 months ago, wasting time on finding already acquired knowledge – relearning, which is waste.  
Well. This log book is knowledge inventory. Knowledge that we keep close to us, ready to use, but it takes up space and the more we have, the more difficult it is to find the knowledge we need. In software we do not have physical inventory, like wheels ready put on a car in a car factory plant, but we have knowledge inventory. So how do we produce the correct amount of knowledge inventory?

Knowledge briefs

Lets go to the source. When we make knowledge and put it into our repository (perhaps a wiki), we should make the knowledge condense, then it is easier to find - and use. But it is difficult to make knowledge brief! If I make a four page documentation of a feature, and come back six months later, I will spend time  

Because knowledge in wikis are knowledge inventory, and tend to grow and grow. Too much get a burden, you cannot find things and when you find a document, its four pages long and the valuable knowledge is hidden in a lot of irrelevant noise. (Can search engines solve the problem of finding useful knowledge in a split second on the internet? I don't think so.)

So what about a wiki that have limited space? You can only put 2400 characters on a page, because if you put on more, you build up too much knowledge inventory. “If you cannot fit your knowledge into an A3, use an A4”. Constrain yourself to condense it even more – extract the important parts e.g. the exceptions in the business case that you only found out about later, and spent time on trying to grasp.  

I want to make an exercise on our next workshop to practice the art of making knowledge brief, to avoid building up knowledge inventory.
And last thoughts: Are knowledge always written? Can you build condensed knowledge in pictures and graphs?

By Jesper Thaning

How do you define quality in a software product? Few defects, no crashes, happy customers?

I believe that software quality really comes down to a few metrics. One is the amount of defects that makes it out of your lab. Another is your ability to maintain the product throughout its life cycle.

The bug metric is one I think most people in the software industry would agree on. So one might ask, why are we still creating them in high volume? Are we really at a point where it is not feasible to lower the rate at which we introduce bugs? I hardly think so. I think developers need a change of attitude towards bugs.

I like to tell myself that for every bug I pass down the "software assembly line" to the testers, I am responsible for the time they waste on finding, reproducing and reporting this bug. Or even worse, if they don't find it I will be responsible for wasting my customers' time.

In case the testers actually find my bug I am furthermore responsible for delaying the entire feature by introducing a need for a "bug fixing phase" where I will be debugging issues that should never have made it into the code.

If I introduce multiple bugs I will most likely also be responsible for wasting somebody else's time on prioritizing them.

I think most developers know that the total cost imposed by defects, rises exponentially over time. But what is really important, is that developers need to accept that they are the key to introducting less bugs, and managers need to accept that trying to push developers to deliver features faster is not going to lower the defect-introduction rate.

What do you think?

By Sune Gynthersen