agile « Thinking for a Change

Things I didn’t learn pt.1

The incredible shrinking program

A classic experiment

Years ago, during a course on software engineering, the professor described a classic experiment: several programmers were given the same application to write. Each was asked to optimize one non-functional requirement: speed of implementation, speed of application, size of application, readability of the code, run-time memory use… Each developer was able to optimize what was asked of them, at the expense of one or more of the other qualities. No surprise there. TANSTAAFL.

I decided to perform this experiment on myself.

At the time, I was writing a hypertext help compiler and viewer, so that I could always pop up the programming reference documentation I needed while programming. The first useable version of the executable was about 20K (yes 20480 bytes) long. It might be fun to see how long I could keep the application at that size. As this was a resident application, the smaller the program was, the more memory was available for the IDE, compiler, debugger and the application I was developing.

A simple game with the expected results

Atari520ST
So, I played a game with the following simple rules:

Get the most important feature from the feature list and implement it, until it works
If the application is larger than 20K, rework it until it’s smaller than 20K. All the features must still work!
Again…

The results were as expected: I managed to keep the application under 20K. This came at the cost of implementation time: sometimes it took a lot of ingenuity and work to squeeze the code back into that 20K. I had to find duplicated stuff, places where I could simplify the code, error handling I could remove because I had made it impossible for common user mistakes to happen…

And some unexpected results

I expected code readability to suffer: I might have to abandon my object-based C writing style, replace C code with more efficient assembler or use complicated tricks to keep the application small. I never needed to do that. If anything the code became more readable…

There were some unexpected side effects. In my experience, the longer you worked on a program, the more features you added, the more difficult it was to add (and debug!) new features. This program was really weird: it kept getting easier to add new features. Wow! That hadn’t happened to me until then and wouldn’t happen again for a long time after that.

This was the first program where I and my users (the application was released as shareware by then) ran out of ideas before my programming ran out of steam.

And what have we learned from this?

I stopped playing with limited home computers and started to work on real men’s computers: Unix workstations. I stopped making my programs small. There was no need: there was plenty of memory (megabytes!) in those machines. I was taught that it was cheaper to upgrade memory than to spend expensive programmer time.

And things were back to normal: with each new feature, it became more difficult to add another one. That’s how it’s supposed to be, isn’t it?

Things I didn’t learn

When I give a talk on Agile or Extreme Programming, there are two stereotypical answers I get from the participants:

That won’t work (where I work).
That’s just common sense. I’ve been doing that for years.

The first reaction is an ideal opening to ask the question: “You’re right. But… what’s the worst thing that’s holding you back?” That way you might discover their constraint.The second answer is a bit more tricky to deal with. Often, the answer indicates a lack of understanding of Agile software development: “I’ve been working without specs all my life. I was XP when you were still in diapers, son!“. If not, get their stories out and learn about their successes and failures.

I was like that, until a few years ago. Since then I’ve learned two things:

It has worked everywhere I worked for the past 5 years. In fact, it’s the only thing I’ve seen work in that time.
If it’s common sense, I must not have much common sense. Or any sense at all. I did things consistently as I had been taught them and was consistently unhappy with the results. Not that this made me change the way I worked; I just tried harder. Someday, it will work…

It’s not that I haven’t had many opportunities to learn. I just missed them all. I was probably trying too hard to notice the obvious solutions staring me right in the face.

So, let me tell you about some of these learning opportunities I missed…

I’m not a Bottleneck! at XP Days London

TOCatXPDayLondon2005_1 Rob Westgeest and I ran the I’m not a Bottleneck! I’m a Free Man! session on the “Theory of Constraint’s 5 focusing steps” at XP Day London.

We had rather a large group, so instead of the usual 7, we played the session simulation with 14 people or 7 pairs.

You can see the first run of the simulation on the left. Notice how

some people are very busy, most notably the two people in the middle who have to fold the boats. Half finished work starts to pile up in front of them.
some people are idle and look a bit bored, like the people at the end of the production line. They only receive some work once in a while, most of the time they’re waiting for input.

As per the simulation’s design, the ‘programmers’ in the middle of the team are the bottlenecks. Our first round programmers didn’t seem to be very happy about that.

TOCatXPDayLondon2005_2 Rob and I then introduced the “5 focusing steps” to optimize the system. We chose one of the optimization steps and ran the simulation again with 14 other people. This let everybody experience the simulation and avoided the “elevation by experience” effect.

This time, the team produced one more boat/hat pair (their primary goal) and consumed a lot less paper (their secondary goal). As expected.

But we also saw some unexpected stuff happening. This time round, all of the player roles were idle some of the time. In a system with a bottleneck, we expect the bottleneck never to be idle, because every bit of work wasted at the bottleneck is wasted work for the whole system. Why did this happen? Maybe the players in front of the new bottleneck (design, just in front the programmers), over-optimized the second goal (don’t waste paper) at the expense of the primary goal (fold more paper boats and hats). By doing this they “starved” the bottleneck.

We had some more discussion of the 5 focusing steps. Usually we do this first part in one hour. At XP Day London we had 90 minutes. Instead of stopping when the material ran out, we continued, trying to fill the extra 30 minutes with some extra material on Throughput Accounting. That was a mistake, because the participants (and presenters) got very low on energy. We should have listened better to Tim Lister’s keynote where he wondered why projects never finish early…

In the second part, 4 volunteers played “customers” who wanted some help with their process. The other participants played newly graduated “Theory of Constraints consultants” who wanted to ~~make a lot of money~~ help their customer.

Some observations:

most “customers” felt that their “consultants” had really helped them to see their situation and options more clearly.
I thought most of the “consultants” really had trouble following the focusing steps “slowly”, but wanted to jump ahead to the solution before understanding the problem. I have this problem too. That’s why I use the 5 focusing steps: they force me to slow down and think carefully.
One customer said that the goal of his system was to “implement “. It’s not uncommon in “real life” that customers bring in a consultant to “just implement my solution”.

Programmers often complain that “customers don’t know what they want“. For consultants, a customer “who knows what they want” is the most dangerous kind. Whatever you do, never implement this solution, unless you’ve made sure that it really is a good solution for the worst problem the customer has. If someone asks you to implement a solution, ask them first “If that’s the solution, what’s the problem?”

Simon Baker has written a blog entry about the session

The Toyota Way at XP Days Germany

Marc Evers and I hosted a talk and workshop on the “Toyota Way” at XP Day Germany 2005.

The session contained two parts. In the first part we gave an overview of the 14 principles outlined in the book. In the second part, participants were asked to tell which principles they had experienced. For each principle, they had to tell a short story to the other participants in their working group. Their experience could be positive or negative, indicated by putting a green or red sticker on the card that represented the principle.

Here’s the tally of experiences that we collected:

Principle	Green	Red
Base your management decisions on a long-term philosophy, even at the expense of short-term financial goals		1
Create continuous process flow to bring problems to the surface	3
Use “Pull” systems to avoid overproduction
Level out the load (Heijunka)	1
Build a culture of stopping to fix problems, to get quality right the first time	2
Standardized tasks are the foundation for continuous improvement and employee empowerment	2
Use visual control so no problems are hidden	4
Use only reliable, thoroughly tested technology that serves your people and process		1
Grow leaders who thoroughly understand the work, live the philosophy and teach it to others
Develop exceptional people and teams who follow your company’s philosophy
Respect your extended network of partners and suppliers by challenging them and helping them improve	2
Go and see for yourself to thoroughly understand the situation (Genchi Genbutsu)	4
Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly	2
Become a learning organisation through relentless reflection (Hansei) and continuous improvement (Kaizen)	2

What can we learn from this very summary overview?

Many people recognized the principles. There are only three principles without examples. Interestingly, there’s no example of the “people” processes to develop exceptional leaders and teams.
Most of the stories got green stickers. Participants found these principles useful. Or maybe they prefer to tell positive stories.
Two principles got a red sticker: the “long term philosophy” and “use only reliable technology” principles. We didn’t have the time at the session to go into the stories, but I’d love to hear the story behind those. If the participants who told those two red stories would like to share them, let me know.

I enjoyed the session. We got lots of questions and debate during the presentation. Some people even called my implementation of some of these principles “extreme” 🙂

I’m particularly happy that the participants recognized these principles in their own work. We can all use management techniques, because we’re all managers, even if some of us only manage ourselves.

Update 11/12/2005: Andreas Zwinkau blogs about the session (in German).

I’m not a Bottleneck! at XP Days Benelux

BottleneckatXPDayBenelux Theory of Constraints @ XP Day Benelux

Rob Westgeest and I ran the I’m not a Bottleneck! I’m a free man! session at XP Days Benelux 2005. I ran this session with Marc Evers at the XP2005 conference before. You can read more about that session on my site.

The first part of the session is a simulation of a production line, where participants have to fold and decorate hats and boats. The picture on the left shows the participants re-running the simulation after “elevating the constraint” by adding another person (Nathalie on the left) to help Vincent, who was the bottleneck in the first round. This had the effect of increasing the team’s output. Some of that increase can also be attributed to the fact that by the second simulation, the participants have more practice.

Elevating the constraint also had the effect of shifting the bottleneck away from folding the boats and hats, towards the next step: decorating hats and boats. That’s quite likely if you perform a large intervention like elevating the constraint by doubling the manpower.

In the second part of the session the participants, newly graduated “Theory of Constraints consultants”, had to solve some real-world problems. Erik, Marko and Nathalie acted as customers. The others played consultants who tried to help their customers by discovering the system, the goal and the bottleneck and applying the “5 focusing steps“.

What amazes me is that each time we ran this session, participants were able to understand their customer’s situation and propose 3 possible optimizations. Within less than an hour! And after only one hour of schooling. If you want to optimize your process, hire these people!

That tells me that the 5 focusing steps are both easy to understand and apply. These steps might look trivial, but they give you focus. And these steps are not as easy as they sound. Just try to find out what the goal of your organisation is…

We’ll be hosting this session at the XP Days London 2005 conference, next Monday. If you want to improve your process, join us there.