Roots of Lean 2010 is taking place next week. This week we are in Tokyo to prepare the trip, get over the jetlag and inhale a little japanese culture. Yesterday we went to a Sumo Stable to see the wrestlers train in the morning. My respect for Sumo Wrestling is now in a completely different place than it was before. To see the combination of strength, speed, tactics and flexibility in these big guys was impressive.





The serious stuff:

Every year we spend plenty of time to create a tour where we will se many different companies and get new angles to what lean really is about. The two last years, it was part of the program to meet with managers from Toyota, besides seeing the plant,  in order to  ask questions and dive deeper into what we had seen. Last year we were  lucky to meet Mr. Ishii - General Project Manager for Toyotas Software Division.  We had two very intense hours with him, where he openly shared how Toyota develops software, and what challenges they have. Recently Henrik Kniberg, from Crisp wrote this interesting account of that meeting.

This year we are not going to talk to managers from Toyota. They are too busy with other stuff - Instead we are going to meet a truckload of other fascinating companies and people. Starting Monday wíth a visit to the Leading manufacturer of Industrial Robots - Fanuc at the foot of Mount Fujii.

Stay tuned on this channel next week to read more.

By Bent Jensen

If results are not the point - then what is?



March 10. we've arranged a talk by Lean Software pioneer Mary Poppendieck at IT-Universitetet in Copenhagen. Check your calendar and sign up - It's free! Check details here (in danish)

As you may now Mary and Tom Poppendieck has recently published their third book 'Leading Lean Software Development: Results are not the point'. Check it out at Amazon.



Mary and Tom is also doing a 2-day workshop i Copenhagen March 11 and 12. Check details here.

We hope to meet you there.
By Sune Gynthersen

Having worked with database applications for many years, I have come across a number of different object-relational mapping strategies and tools. However, most of them has had built-in design issues that caused me to dislike them after a short while. One of the latest was Castle ActiveRecord.

Fortunately - in the software industry - if you dislike something, you can code your own solution. After a talk with my colleague Lars Thorup and some inspiration by Christian Liensberger I decided it was time to create something that was simpler, more flexible, more testable and promoting better design. Frog.NET was born, and is now an open source project hosted on Google Code.

We have been using Frog.NET on an internal project for a couple of months now, and it has been great to get rid of some of the problems we experienced with Castle ActiveRecord.

Check it out here: http://frogdotnet.googlecode.com/

By Sune Gynthersen

Games is a big topic at Agile 2009. Not computer games, but participatory, experential learning games where the players learn about the dynamics of organizations and Agile software development. I've been to several great sessions where games played main role, e.g. The Bottleneck Game and Applying Systems Thinking for Organizations through Play.

My take on the popularity of experential learning games at the conference is that we've tried for some time with all the hard-hitting, rational arguments for why Agile is a better way of developing software but those arguments fall short with people that are deeply rooted in other ways of seeing the world. To be able to reach out to those people the Agile community needs ways to provide those people with experiences that will convince both intellectually and emotionally. Experiental learning games is a great way of doing that. And fun too.

By Thomas Blomseth

On day 3 we had not scheduled any visits, so I took of the day off buying some presents in Akihabara part of Tokyo (a.k.a. Electric City). In the afternoon I met with some of the participants at a Big Echo Karaoke-hotel. Who would have thought "We are the world" sung in a Tokyo basement could sound so beautiful?

Day 4 we visited DaiNippon Printing Ltd. At the factory tour of DaiNippon we saw how millions of japanese anime cartoons were printed, but most remarkably we saw how widespread the culture of using visual management in factories are. We had barely entered the factory, when I counted 13 * 3 meters of visuals on a wall. What to look for during maintenance with big pictures of how well-maintained equipment should look, defect statistics, and a lot of stuff I japanese (whích I can't read) that looked important. All of which helped employees do a better job.

By Sune Gynthersen

As I'm beginning to feel a little stuck writing this blog-entry, I get a strong desire to check the news and see what happened in the world since I last checked 30 minutes ago. And I think I also need a fresh cup of coffee. I can imagine myself go down into the kitchen, boil water and add instant coffee to the mug, pour hot water over and add a little milk - heavenly! But instead of following my desires, I take a  look at the small ticking tomato-shaped timer in front of me, and I notice that I still have 15 minutes left to go. I put a mark on a piece of paper on my table, and turn my attention back to my blog-entry with a desire to keep going for the next fifteen minutes. I know very well that the desire to get a cup of coffee or check the news, are just a few of my procrastionation demons. They have haunted me for most of my life, but I now have found the ultimate weapon in the form of a small red tomato-shaped timer.

It was more accident than anything else, that led me to attend Staffan Nöteberg's talk about the pomodoro technique at this years agile conference in Toronto. This accident changed my life, and after that also the lives of my colleagues. Much would have been different had I known it 25 years ago.

The technique was invented by an, at that time, young italian student Francesco Cirillo, who was not too pleased with his own ability to study concentrated. As an experiment he borrowed his mothers kitchen timer, and tried to stay focused for 25 minutes. He did not succed immediately, but gradually developed the technicue to deal with internal and external interruptions. He developed a set of simple artefacts and  planning and improvement tools. As the technique matured, it was shaped to be used by others than just individuals. Also pair-workers and teams can have great benefit of the technique.

Curious? Check the links or attend my presentation in Copenhagen on Thursday  March 5th at 5pm - read more and register here.



By Bent Jensen

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

Have you ever heard the old joke about how many programmers it will take to change a light bulb? -- None, it's a hardware problem.

After the following experience, one might think the answer above is the logic of HP -- the worlds largest provider of printers.

The other day I found my self in need of scanning a document. A company was asking me to fax a signed non-disclosure agreement to them -- Who has a fax these days anyway??

So I thought to myself, aha, I'll just scan the document with my signature on the HP PSC 2110 combined printer and scanner I have next door. Though I had not used the printer with my current laptop, I thought to myself, How hard can it be to get a bit of HP hardware running these days? (man, was I wrong...) I had already used it on my old laptop, so I set out with confidence on what was to become a quest longer than expected.

First I eagerly put the document in the scanner, and connected to it via a USB cable. Windows came up with "Found New Hardware" dialog. I nodded - Sure BillG, please attempt to find the right driver for me. Then confidence started dropping. Another "Found New Hardware", and another, and another, and another. Damn, how many different devices exists in this printer/scanner that needs drivers installed seperately? Well.. the number of dialogs wasn't really what scared me the most. The fact that some of them completed successfully while others said the hardware could not be installed successfully, concerned me a bit more.

Hmm... okay, plug and play -- yeah right. I decided to do it the ol'fashioned way. Pick the right drivers directly from hp.com, and install it myself. At this point I was yet to discover that the road ahead was to be filled with trouble and despair.

I went to Google and typed "HP PSC 2110 driver download" - And as anyone would expect I found the correct site in a few seconds. I clicked "Windows XP" as operating system and got a list of downloadable files. I scrolled to the "Driver" section. ...And stopped. I need to download a 166 mb driver?? You got to be kidding me HP! Though I haven't written a lot of hardware drivers I just know, that no hardware driver will even come close to 166 megs!

You would think that engineers at HP had tried Windows Update from Microsoft, which - though not perfect - features to ability to download, only whats needed, in the user's particular context. But no, some product owner guy at HP probably convinced everyone around him that users would rather spend their precious time downloading 166 mb of bloated irrelevant software (with photo viewing capabilities!! - amazing!)

Though shocked I convinced myself that if I just downloaded the driver, everything would work out just fine.

..30 minutes later..

I started the installer and for a second I was thinking ... "Hey, maybe it will just work right away". After a few moments the installer asked me to plug in the scanner in the USB port. And so I did ...and waited.... and waited... I went to pick up lunch, and came back 10 minutes later. Now it said that the installation was unsuccessful, and asked me to look in the readme file (only way out was an "Okay" button). What in the world should I look for in the readme file? Why was it unsuccessful? Why doesn't it just work...? I was all of a sudden feeling very tired.

I could see that the installer had put two shortcuts on my desktop. "HP Director" which I had no clue what might be, and "HP Photo & Imaging"... I clicked the latter, found a Scan button and clicked it. The program asked me to select a source... unfortunately the list of available sources was empty, though my scanner was plugged in. Hmm... great, a partial install.

..an hour passed, I tried back and forth but still wasn't able to scan my document and I gave up. I thought to myself, maybe I should just buy another scanner?

Looking back, I wonder if it is possible to find a vendor that takes software, drivers and particularly user experience more seriously?

I admit, that if had I bought a just-released-to-market, highly complex, all-new-technology piece of hardware - I might run into problems like this. But dammit, this is a printer and scanner, using technology that is 20 years old, running on the most common operating system on the planet.

Well.. the PSC 2110 is a couple of years old. So maybe HP is so busy releasing new printers that they don't update and maintain drivers for their old stuff? While this could be true... I certainly doesn't hope it is the case. Dear HP... users don't need new printers, they need working printers!

If I put my software background aside, and step into the world of my favorite fictional user, nice old Mrs. Jensen, it all seems even more bizarre. How on earth did HP expect her to figure this stuff out?

So dear HP - I got to say, you got one sceptic customer, to say the least. And I can't believe I'm the only one who is experiencing this. Why not seize this opportunity to tap into one of the most valuable sources of information -- user feedback. The guys responsible for maintaining content at hp.com seemed to get that user feedback is important. I guess otherwise they wouldn't have implemented an online feedback system. I got to admit that I found it a bit strange that they asked me to give them feedback about the web experience in the "driver downloads" section of their website. See for yourself: "Thank you for taking the time to provide this information. This will help us to provide a better download experience in the future."

I did consider writing "I'll give you feedback on the experience in 30 minutes, once my printer driver download is completed", but maybe they wouldn't get the irony.

Who gives a damn about the download experience anyway? I'm not the kind of guy that comes about driver download pages without an underlying reason, like wanting to scan a document. So why not ask me for feedback in the context of the whole experience, instead of "Is this web page useful?". I mean -- dear HP, you do not earn money from having a nice structured website. You earn money, marketshare and respect by understanding and helping users users facing problems - like "I need to print a document". So if I were to give you some advice based on this experience - ask yourself: "How can we solve the problems our users face, faster and easier than anyone else?"

I could talk for days about this bizarre experience -- but I'll leave it here, for HP or anyone else to comment

Oh and by the way, yes - I did submit this experience through HP's online feedback system. Now the real question is whether those responsible for the drivers download pages, will actually forward it to the appropriate team inside HP...

---
What if there was just ONE file to download from the HP website, no matter which HP printer you had. A simple probing utility no larger than 500kb, which would probe your printer, download and install the right driver. And I bet it could be done with no more than a single click by the end-user. I wonder how that would affect the number of support incidents at HP.

By Sune Gynthersen

In a "Traditional"  approach to estimation a set of detailed requirements are analyzed, and from that analysis a solution is designed that will fullfill these requiments. We then estimate the time it will take for us to build that design.

If we do Agile development, we instead measure the relative size of each of a set of high-level requirements (e.g. in the form of User Stories). We then assign a conversion factor to the relative sizes of the User Stories, to be able to predict, when we can have what done. If we do not know how long time it takes, we can do a small iteration, and see how much we are able to complete in e.g. a week. We then use that knowledge to extrapolate from the whole set of requirements, to arrive at a delivery date.

If I am to choose from those two methods, I will greatly recommend the latter. simply because the detailed analysis and design, always misses something, and because it has an underlying assumption that nothing, or very little will be changed over the course of the project - thus the investment in the detailed analysis and design is justified. Anyone who has created software in the real world know that is never the case.

But both approaches treat estimation, as if the size of a piece of functionality or time it will take to complete it, is a real characteristic of the feature, and what we do in estimation is trying to find that hidden, true number.

I will call both these approaches Reactive estimation.


And off course there is something I will call  Proactive estimation. In this kind of estimation, the estimators acknowledge that creating a piece of software, is a creative process, where problems are solved on a daily basis, and that the level of teamwork, dedication, creativity and problem-solving skills are the factors that really determine the lenght of a software schedule. In this kind of thinking, a team will commit to deliver a product to a certain date, but they know, that what will be delivered, will depend on their ability to learn and solve problems along the way. The development process is then organized to accelerate learning, and plan  in a way that keeps decisions  open as long as possible. In that way the team will arrive at the best possible result at the given date.  Much the same way a play normally always will have premiere at the date that was planned months of even years earlier.

Does this sound to crazy to you? Maybe - but that is the way Toyota creates new cars, on time and with fewer resources than their competitors, and I am convinced that some kind of proactive estimation was used when the iPod and the iPhone was created.

By Bent Jensen

Back about a month ago we arranged a free lecture at the Copenhagen-based IT-University, with Lean Software pioneer Mary Poppendieck. Though a little late, we now have a copy of her slides available to all the participants. We very much hope you enjoyed the evening and got a chance to mingle with other agilists.

Download the slides here.





Some of the participants wrote blog entries about the experience. Check them out here: 100% Scrum is not 100% Agile and  Agile theses and mistakes


By Sune Gynthersen

We have just completed the list of workshops that will be held by BestBrains throughout the year. You will find new exciting workshops like "Agile Software Development for Managers" and "Lean Product Development for Software", as well as old popular ones like "Agile Planning and Estimation".

Download the PDF from here. (It's in danish!)

By Sune Gynthersen