The Value of Innovation

I've been reading up on the value of innovation, in preparation for the Value seminar by Tom Gilb in London this week. One question for Agile teams is how to innovate within the constant pressure of "Sprinting" and barely having time to draw breath.

Agile teams can be innovative of course, although from experience I suspect this is more from a sharing and aligning of the business and users needs than from some magical technique, and of course this can is not just from Agile, Agile merely improves collaboration and communication.

The strong Agile teams I have worked with are very much in touch with the business. The product leader proxy who works collaborative with the team to share understanding, who brings customers either onsite to validate the user experience or has novel approaches to doing in context testing can help channel the innovation and creativity within the team. The act of iterating and experimenting can also create interesting approaches as failure can be quick and success understood just as fast.

When at Yahoo! in the innovation group, there was constant discussion and debates to even articulate what innovation was. Is it the disruptive or small innovations we sought? The disruptive innovations of course made the press yet many small improvements appeared to be the ones that paid off. We were not only competing with our arch-nemesis of free lunch fame the next city over, but with the "two guys in a garage" syndrome. So it's not two people you are competing with, it's tens or hundreds of thousands spread across the globe so p

utting even a hundred people into an innovation think tank wasn't going to compete with that

.

Sun microsystems had a strategy when faced with the same dilemma to allow people who had great ideas internally to leave the company until they got them to a feasible stage and then acquire them. They understood that they were the greatest impediment to innovation and only by releasing people from their internal processes could the ideas flourish to the point they could be self-sustaining.

We saw this countless times at Yahoo!, by the time the bureacratic wheels had processed the idea, it was already out in the world via a competitor, or funding was not forthcoming as it was seen as risky so instead money would be reallocated to a safe bet so the idea never saw the light of day. One of my colleagues said his most creative time in joining the company was in the first three months, before he realised what he wasn't allowed to do. His blind ignorance meant he cut side-tracked the red tape that hindered his co-workers and could get something done and to market.

Is it better then to ask for forgiveness instead of permission? One of the most innovative people I met had an infamous quote "if you aren't constantly in danger of getting fired then you just aren't trying hard enough". The trouble is the context of corporate politics discourages risk taking and the idea of ever failing.

At Toyota the leadership team is taught to ask for "Bad news first". Rather than the Western idea of showcasing how good things are, if you can't see the bad things you can't improve.

Perhaps we should step back from the quagmire of companies having a process or system that even allowed innovation to occur and ask ourselves if innovation is even a worthy goal or simply a red herring. What is the value of innovation? How well does it really serve a company to succeed? According to studies, over 70% of R&D funding is wasted. The money if funnelled into chasing patents which can often be of questionable value (particularly if companies use patents as an industry measure of innovation be they worthwhile or not), instead of delivering solutions that add value to the business, users and society in general. Patents going up while profits slide down appears to be a visible symptom of many Silicon valley start-ups.

Instead of innovation being a goal unto itself I would suggest that setting up a culture and system that allows people to understand what value is for the customers and end-users will naturally allow innovation to flourish. In the book "Good to Great" the premise is that the most successful companies needed a greater purpose, simply saying you wanted a company to make money didn't inspire or motivate anyone, in fact the research being done on monetary reward systems should give the clue that this is never a good enough reason or at least a long term sustainable reason to run a great company. We know that many innovations are happy accidents (the teflon story), a means to an end (3M postit notes) or to meet some wonderful vision (men on the moon).

Instead of focusing on innovation companies should focus on their passion, and igniting that passion in their teams. When I met with Katiyama-San, the Toyota chief engineer who designed the Lexus and is working on the high-speed bullet train for Hitachi currently, he said the reason they built the Lexus is that an internal team wanted to work on it as they were excited by the idea of building a high quality vehicle even though it wasn't their core market. His reason for even being in the business in the first place was that he loved speed. His passion was racing cars so he wanted to work on high-end fast cars. He said the man who was the chief engineer who worked on the Sienna people-mover (minivan) worked on it not because he loved building minivans, but because he loved his family. The passion drove the innovations, if you don't care you won't do a good job.

Victor Frankl, a Jewish-German psychologies and author of "Man's search for meaning" did a lot of research both in the prison camp he was interned in and managed to survive, then after the war in American working with teenage suicide patients. The reason people survived longer in the camps was if they had some meaning, some reason to live. People who didn't or lost hope died quickly under the harsh conditions. Many American teenagers who had never had to work for anything and had no purpose similarly would die quickly at their own hands, even in the most luxurious of conditions.

Bringing this back to product development, if the team doesn't understand the reason or purpose of what they are doing, and the product leader is unable to articulate or inspire them, the product will die. It either will lack the ability to delight the customers or it will suffer from a lack of nurturing once it's launched and never grow beyond it's early success. The longer a product takes to be built and delivered, the more diluted it's essence and message is. The monolithic traditional projects over multiple years not only risk missing the market and costing a lot of money that might completely miss it's targets, but it also wears down the teams working on them and the vision fades and what emerges is a pale shadow of the original idea.

So what should you do to keep teams focused and perhaps as a bi-product, innovate?

1. Choose an inspirational product leader to build the team. They won't have all the ideas themselves but they can inspire the whole team to understand the business drivers, the customers and users, and the purpose.

2. Let the team not only understand but actively participate in quantifying the measures of success, walking around in the users shoes to build empathy, and being involved in the user feedback loops to see how people respond to their creations. If it can't be measured it won't be valued.

3. Allow the team to take the steering wheel sometimes. Rather than have people feeling like their ideas aren't heard or not agreeing with the product priorities, let the team have a Sprint where they prioritise what they work on, they can suggest new ideas, lobby their team mates to join their venture, fix defects, build better automation etc. I call this a "Hack Sprint".

4. Get the company motivated in 24 hour hackathons where teams can form and work on their ideas and passions then showcase them to the whole company.

5. Get products out to market quickly and validate with real users in the real context. Get feedback early and often from the start of the new idea (rapid prototyping) through to beta launch (AB bucket testing) can save a lot of money and time.

6. Don't decide all the features at the beginning, allow time to get some feedback on which features provide the hook and delight users over pre-supposed ideas of what will succeed. Even market research can be flawed and give false positives so that can't be fully relied on. Apple apparently does little market research.

Some quotes on Management I like (thanks to Robert Morris, amazon reviewer)

What do leaders do? (John P. Kotter)
Comment: "Institutionalizing a leadership-centered culture is the ultimate act of leadership."

How do managers and leaders differ? (Abraham Zaleznik)
Comment: "Managers see themselves as conservators and regulators of an existing order of affairs with which they personally identify and from which they gain rewards [whereas] leaders tend to be twice-born personalities, people who feel separate from their environment."

How do "defining moments" help to develop character? (Joseph L. Badaracco, Jr.)
Comment: "Defining moments force us to find a balance between our hearts in all their idealism and our jobs in all their messy reality."

What are the ways in which CEOs lead? (Charles M. Farkas and Suzy Wetlaufer)
Comment: "No matter where a company is located or what it makes, its CEO must develop a guiding, overarching philosophy about how he or she can best add value.... A leadership approach is a coherent, explicit style of management, not a reflection of personal style. This is a critical distinction."

Why are there so few great managers? (Thomas Teal)
Comment: "Great management involves courage and tenacity. It closely resembles heroism."

How to lead others during adaptive change? (Ronald A. Heifetz and Donald L. Laurie)
Comment: "Solutions to adaptive challenges reside not in the executive suite but in the collective intelligence of employees at all levels."

"Whatever happened to the take-charge manager?" (Nitin Nohria and James D. Berkley)
Comment: "Pragmatists understand that it is unrealistic to try to avoid uncertainty. Attempts to deny or ignore it can blind managers to the real contexts in which they are working and prevent them from responding effectively."

Daydreamers solve problems faster

http://www.abc.net.au/science/articles/2009/05/13/2569013.htm

The submissions for the HICSS conference need to be in by June. It is in Kauai next January.

http://www.hicss.hawaii.edu/

The Sukiyaki was very different to the way I'd had it before. Instead of a large soup this was done with a small amount of intensely flavourful sauce of sake, brown sugar and soya sauce. Mary is happy with Sukiyaki.

Tom looking with dismay at his dish of octopus. I bailed at the snails, coward that I am but Martin polished them off.

Sukiyaki with (from left), Henrik, Mary, Me, Tom and Martin. It was a nice quiet dinner after the craziness of the last few days.

A "Nationalist" on the street below some guy on a microphone. Political lobbying which thankfully was in Japanese so it sounded more intelligent than I'm sure it really was.

Lunch at a little place on the way home. One of the staff has a little kip on the cushions. I thought I kept hearing a train go by but no, he was snoring. At least now I know why the cushions are there.

This is a student sumo. The experienced ones are driven around and don't take trains.

Painting of a sumo wrestler inside the train station. This is where the Sumo wrestlers live. We saw quite a few wandering around in their kimono's.

Day 3:
Uploading some quick pics of a trip to the Edo-Tokyo museum. I had to find Astro Boy (first of Japanese Manga) toys for my children. They happened to have an exhibition on which was excellent.

Mr.S.Ishi, Project General Manager for the software division at Toyota. He was very nice and gave us a lot of good information. He was extremely humble and likeable. It's now 1.30am so I will have to post some more on this tour later. A quick summary was that they were applying some Toyota Production System (TPS) thinking to their software cycle but otherwise it was mainly waterfall and some spiral process. In some ways the Plan Do Check Act (PDCA) seems to flow into a waterfall. One thing he said early was that "Key success = mutual understanding between a manager and an engineer". One of their struggles seemed to be with engaging management.

More Toyota Plant:

Stop here if you are already bored but someone might find this interesting. The Andon board for all the assembly lines has numbers indicating the Plan for right now, the actual state, The plan for the shift and the % production achieved to target. I think this is right anyway.

Little lights hang over each car assembly area station that are green, orange and red. You can guess what these mean and I explained the orange and red earlier (ha, I knew you weren't paying attention). I was surprised that they didn't stop the line every time they found an issue. I had some romantic notions that were dispelled during the tour. It was hard to figure out how Kaizen (continual improvement) really worked in practice as we saw orange and red lights go off but it wasn't some dramatic swarming event. They seemed to fix stuff as it all kept moving while we were there. Production was at 450 cars per day. It has been lowered due to the economy. Apparently they use some of the slack time to make improvements. We did hear that it was up to the workers to make improvements on their own time which was a little at odds with the other statement. We suspected that due to a 2007 ruling that Toyota had to pay for overtime that this might be the reason it was voluntary and out of hours. We hope to find out more about this on Friday when we talk to an ex chief-engineer from Toyota. We are told there are up to 20,000 Kaizen improvements per year by the guide. The shifts are 7.5 hours.

They have a little play area to try your hand at different skills. It's fun. They also have some little plagues around with workers medals displayed for various honours.

We see Poke Yoke (mistake proofing) in action. The robots have validation tests built in and will also set off the alarms automatically if there are any aberrations.

The Toyota Plant

We now leave the pictorial portion to go to Toyota. You can't take pictures so I made a lot of sketches instead. We have a guide who has the tour process down and leads us around to various stations and tells us about the plant. The first thing you notice is how clean everything is. The second is how visual and audio are used to help track, display and communicate. Large boards are everywhere explaining what parts of the plant are for, Andon boards to show status on production including incidents, cars on assembly lines and then some large random cartoon like billboards of children fishing, skiing etc. I asked what the latter were for and were told "oh, for fun!". Good enough.

The whole place is one large choreography. It's like going to "Toyota the musical" and I also feel like I've stepped into Ompa Loompa land (Willy Wonkas Chocolate factory). It's a little surreal and the music is fairly constant. By music I mean the small world (in this case slightly tinny sounding Fur Elise amongst other gems) soundtrack. Music is used for a couple of things. One is to sound if a machine/vehicle is backing up, others are unique to each assembly line to indicate if there are problems. If an issue is spotted or automatically found the sound will go off, and lights will flash and dashboards (Andon boards) will update. Yellow signifies a problem is found and if it is not resolved before the vehicle reaches the next station then the light will turn red. This can trigger the "stop the line" affect we have heard a lot about.

They have little carts moving all over the place. The factory is half man half machine in action and all seem to act in harmony. They use carts to carry all the supplies such as drills, screws etc and when these are emptied they go through a cleaning machine on the floor. They clean up as they go everywhere (refactoring anyone?).

They have cables running over the heads of the workers that can be pulled if issues are spotted, one on each side above the conveyor belts. Interestingly the size of each assembly line can be shortened which can create more or less buffer to even out the work flow.

On the hood/bonnet of a car is a Kanban card with all the car information. At the beginning when there is the shell and not much else an RFID box is fitted beneath the car. This contains and tracks all the specifications for what the car needs to have added and has already had done. This moves to the roof later on. It helps the robots figure out what to do. I hope they put in the Asimov mod as it is all way too smart to be left alone otherwise.

They have such cool little ways of moving things around. Little flat dollies scuttle under the main carts with supplies (doors etc) on rails if they aren't been used to take the carts further down. Apparently they are expensive to keep under the carts all the time so they shoot where needed as needed, just in time as it were.

Lots of little inspirational messages appear on the wall such as "Good thinking, Good product".

On the assembly lines a range of different cars flow through fairly seamlessly. One is a minivan, another a car thing (ok I'm not good with all the models but imagine other car things and you will be fine), and no two in the same model and colour appear yet. The workers attaching the doors fit them in different ways but do it so effortlessly and everything is coordinated so well. We have seen this from the way people in stores make food, package items etc. It seems to be a national sport. We spot what we think are A3's on the wall behind the workers but it could also be pictures of their Robot king for all we know.

One thing I start to see everywhere is themes appearing in the design of practical items. For example the Andon board (think a dashboard with information on the assembly line) is shaped like a car with a clock fitted where one wheel is and another blank wheel shape used to balance it up. Ok so you don't have to do this and can you imagine doing this in the US or somewhere just for the fun of it? I noticed on the way back to the hotel today that even the manhole on the street is designed with a Sumaria warrieor engraving. Bit elaborate for most public works departments.

Everything is colour coded and we will see this appear later when we speak to the Toyota software division. Colour and sound pervade and help signal without words or text what needs to happen. This is incredibly fast and part of their secret sauce (ok not so secret but I don't see many others doing this).

The trumpet playing robot. They had a few robots wandering around. When they turned off they would elegantly bow and looked like they were going to sleep.

The photo loom in action. Images are taken from a computer setup beside the loom. It's amazing to watch the photos being weaved real time.

This shows a little of the scale of the place.

Ok so I officially have a ridiculous amount of loom pictures. It made sense at the time I promise you. I selected the most interesting ones.

The little metal things at the top left are what drop down to stop the loom when a thread breaks or slackens. They still use them today. The second shot is Reza from Crisp playing with a loom. They let you do stuff to keep you interested.

The third picture is the stop the line (jidoka) loom.

See I told you we took bad tourist photos. This is the famous loom which is about to start. I have videos of it all which I will post when I can get to some serious bandwidth.

We have officially arrived at the Toyota Commemorative museum of Industry and Technology. People stand around taking tourista photos.

Huge billboard opposite the Nagoya train station. This is all video with clinky music. A lot of the music on the stations, construction vehicles etc sound like "it's a small world"

Day 2 of the Lean Tour:

On the train on the way to Nagoya with Tom and Henrik. We are working on our A3 thinking working for Agile 2009.

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.

Henrik pretending he doesn't love wearing a suit and tie. Release your inner corporate.

After walking around for what seemed like hours to find a restaurant (hard due to funky lack of street/number format) Martin (on right) called the restaurant who then sent someone to walk us over. Not sure you would get this service in NY.

Downtown Tokyo for Day one of the Lean Tour.

http://www.viddler.com/explore/oredev/videos/38/

Oredev panel, Renaissance of software