Day one of the Lean Tour in Japan.

We went to Fujitsu and met with the CEO of their software subsidiary. They are applying the Toyota Production System (TPS) to their software development process. The interesting thing is that they were lean in parts, but not Agile, at least by most people's definition of it.

The CEO led the first part of the presentation and was not only committed to improving through Kaizen but also to sharing the knowledge. That he took an hour out of his day to meet with us was a amazing when I'm used to many CEOs being silent busy shadows behind closed doors.

It appeared they were creating a templatised solution for building web pages quickly by taking elements such as buttons, specific page layouts etc and creating modular elements that they can re-use/customise and build sites quickly. As the elements were standardised and helped them to create estimates that were fairly close with low variance. They do detailed tracking via via timesheets. It was a fairly linear phased approach in many ways but perhaps appropriate for the current situation. The phased development approach can work is known, sequential in nature and fairly simple and you then automate as much as possible. It took a little time to remove the filter I see the world in terms of Agile and lean in the way I've applied it but actually the whole talk was more interesting as it wasn't perfect.

They were actively measuring the changes they were making and had a statistician/mathematician on staff whose job it was to collect and analyse data from the teams and trending the data over time.

The first interesting point of the presentation that I forgot until Mary Poppendieck bought it up last night, was that they showed a transition from "people" to "process". This is an ongoing debate in the lean community and a slightly muddy area, does a good process help mediocre people, or do good people with a broken process make headway? Interesting that they were approaching it as a system problem. The reality looked like a flattening of hierarchies and people working on slices to build products. Due to the translation and depth of some of the questions it wasn't always clear so some assumptions might be incorrect.

The estimation and detail they went to was interesting. They had tried function points and moved to their own lighter weight version called a Function Scale. They break down elements from the UI and create a scale for estimating that is consistent across the development group. It is fast, being done in a couple of minutes over half an hour or more.

I was curious if they had run into problems with creating more complex applications, dealing with infrastructure and R&D/innovation work and from the response (more body language than verbal) there were some areas to improve, but it was hard to dig deeply into it in the time we had.

More posts on this soon, it's late here. Tomorrow is the Toyota plant and museum. Time to see the famous Toyoda loom.