|
|||||
|
We will organize the second Agile Open conference on 27 and 28 April 2006 in Mechelen, Belgium. Agile Open is an open space conference about Agile topics. The idea is simple:
To get an idea of the range of session, take a look at the output of last year’s sessions. Tags: agile, Agile Open,Open Space Running on empty. I just don’t seem to learn, do I? Artificial Intelligence
The software ran on Lisp Machines. We only had three of these machines on campus, two in the lab where I worked, another one in a lab on the other side of campus. Lots of people wanted to work on these machines. The machines were clearly a bottleneck. There was an “interesting” way to deal with the bottleneck: the staff could use them in the day, students could use them in the evenings. Natural stupidity I came in each evening to work a bit on the application. Load the application, which took a while. Check the changes that the TA developing the expert system, had made during the day. And then I could work on the part of the application I had planned to work on. Each evening the same scenario would repeat itself: I made a bit of progress and then got bogged down with a problem. No matter what I tried, I couldn’t solve the problem. I was stuck. Tarpitted. I went home. Next morning, I looked at the previous evening’s problem. The problem that seemed so difficult the night before, was actually very simple. You had to be really stupid to not be able to solve that problem! I finally managed to implement the system after struggling for many nights. It wasn’t a particularly great piece of software. Stop wasting my time with time management courses A few years later, my company sent me and my team on a three day off-site “Time management course”. That would teach us to use our work day more efficiently, they hoped. Unfortunately, the company also asked me to perform an important technology assessment that same week. So, I had to come to the office each evening after attending the course, to finish that assessment. This useless time management course forced me to do overtime that week! Stupid course, it didn’t teach me anything! Go home! Years later, I managed a team. Extreme Programming was all the rage then. It all sounded very plausible. I was determined to apply the “Sustainable Pace” (then called “40 Hour week”) practice. Each evening I would do the rounds of the office to see if people were working late. When someone worked lated, I gently reminded them to leave on time. If they were still working late the next day, I sent them home. If they still worked late the next day, I told them to see me the next day, so that we could discuss what problems they had. This allowed me to discover and fix several problems early. Code quality improved. As usual, I had made the rule and I thought it didn’t apply to me. I still worked long hours. I got stupider by the day. Unfortunately, there was noone to tell me to go home. I had sent them all home. And what have we learned from this? We don’t do stupid things like that anymore, us Extreme Programming experts, do we? At the previous Pair Programming Party we tried to implement a very simple story. We were all a bit tired after a full working day, but it was such a simple feature. Following the TDD canon, we wrote a failing unit test (several lines of code), implemented the code to make the test work (half a line of code) and expected the unit test to succeed. It failed. Whatever we tried, we couldn’t get this code and its test to work the way we wanted to. We finally gave up. Two days later, I looked at the code and the error jumped me in the face. You had to be really stupid to not be able to solve that problem! … That’s how it’s supposed to be, isn’t it? Lesson learned:
Well, at least the expert system learned from experience… Tags: agile
I will be presenting the Toyota Way session at the French XP Days in Paris, on 23 and 24 March.  This session will describe the 14 management principles and how they can be (and have been) applied to software development management. I’ll be using a new presentation style, following some tips I got from Presentation Zen (link by Nico). The slides contain a lot less information (well, almost none), but they are cues to underline the story of the presentation. It’s a combination of the “Takahashi method” (but not so sparse) and the “Lessig method” (but not so rapid-fire). I’ve already used this presentation technique once, together with Vera Peeters, to present “The Origins of Agile”. I thought it was fun, fast and contained some useful information. Come and see for yourself in Paris. Tags: agile, lean, Toyota Way, XP Day (Fr)Agile Software Development. Ha ha! Detractors of Agile Software Development sometimes use the term Fragile Software Development. It’s an easy pun, you don’t have to think too hard about it. And then you can dismiss the whole idea of agile software development without a further thought. This accusation is mostly aimed at Extreme Programming. XP has a set of interlocking practices that reinforce and balance each other. Take one away and the whole house of cards comes crumbling down. XP is fragile. And that’s how it’s supposed to be. Huh? Agile: good! Fragile: bad! Surely? What if that fragility contributes to XP’s agility? Let’s look at another fragile method and all the ways it can break: Lean. Let’s count the ways we can shut down a Lean plant:
And yet… every metric and statistic available clearly indicates that Lean plants are more efficient and production lines break down less often than “traditional” plants with lots of safety margin. Making the system more fragile: lowering the water level to expose the rocks In between cells or parts of the production line, there are small buffers of unfinished work (see the “Drum-buffer-rope” entry) that protect a consumer from variations in output of its producers. The Toyota Way describes how the size of these buffers is determined: by using the lower the water level to expose the rocks technique. Whenever a process runs smoothly, the size of the buffer is reduced. If the system keeps working smoothly, the buffer is reduced again. This continues until the system breaks down. The buffer is enlarged to the previous value and the root cause of the system breakdown is researched. When that problem has been solved, the buffer is reduced again.
Fragility keeps you on your toes How would you act if a mistake could shut the whole plant down? You would make damn sure that everything is in place to avoid mistakes or to fix them very quickly. You’d try to find and fix root causes of problems. You would constantly look to improve and refine your processes. You would actively search out problems. That is… IF you worked in an extraordinary, learning organisation. If you work in the average company, you would be scared to do anything for fear of being blamed (and fired). That’s one of the reasons that the Toyota Way says “Whatever the problem, it’s never a people problem, it’s always a process problem” A while ago, I had a discussion about how to handle a daily build failure. I advocated letting the whole team work on fixing the build problem, before they started to work on new features. Someone else proposed to let one developer fix the build, so that the others could get on with their work. He thought I was a bit excessive, extreme even. Now why would I want to waste good developer’s time? Maybe to make our process a little more fragile, to make the cost of a build break a bit higher, so that we would think that little bit harder about how to avoid the root causes of broken builds. XP is fragile. XP is Lean XP has even more ways to break down than a Lean plant. Let’s list a few:
What keeps XP projects alive?
And that’s just for starters. Who knows where you would end up if you kept doing that? Just imagine… How fragile can you make your process? Tags: agile, theory of constraints, lean, Toyota Way The one without a bug. I just don’t seem to learn, do I? Daddy, where do bugs come from?
Well, no. We make mistakes and introduce errors into our programs. We had a lot of errors. We had so many, we needed a database to keep track of them. Were some modules more error-prone than others? If so, why? That’s what the project manager wanted to know. He had written a script that counted the number of lines in each module and divided this by the number of bugs assigned to this module. He was going to make a graph of bug density. That would tell us where to concentrate our effort, because we couldn’t fix all the bugs. He asked me to help him debug his script, because something was going wrong. His script always threw a “division by zero” error when calculating #lines/#bugs. We discovered that there was one module with zero bugs! Clearly, a requirements error: nobody expects a zero-defect module! The perfect module Which module had no bugs? Who was the super-programmer who had implemented this perfect module? Turns out that this module was written by M., a programmer in my team. It was the first thing he ever wrote for the company, fresh out of school. His later work was riddled with errors, like everyone else’s. What had happened? As M. was new and this was his first programming job, I was asked to mentor him and help him find his way around our code, so I had a pretty good idea how this module was written. The recipe for a perfect module I divided the project into small pieces. Before starting on each piece, M. and I would discuss how we could implement it. M. would then go off to implement a bit, asking me questions whenever something was unclear. When M. had written a piece, we’d go over the code. M. would explain the code to me and I asked questions and gave feedback. Often, the fastest way to explain what I meant was to take over the keyboard and change a bit of code or write another bit. And then M. would change something. We would rework each bit of code until we were happy with it and it worked. And then on to the next small piece. And what have we learned from this? It took a lot of effort on my part, effort that wasn’t being put into productive work. But the goal was to teach M. how to code independently. After that first project, M. didn’t need any more handholding. He could now implement modules on his own. I could go back to my real work: writing and (most of all) debugging modules. Now, we could each work on our own modules. That’s a lot more efficient than two people working on one module. And things were back to normal: neither M. nor I ever wrote a (even remotely) defect-free module ever again… That’s how it’s supposed to be, isn’t it? |
|||||
| Copyright © 2025 Thinking for a Change - All Rights Reserved | |||||
Years ago, I wrote my Master’s thesis at the university’s 
The metaphor that gave this technique its name goes like this: imagine you’re sailing a boat. Below the water surface, there are rocks, but you don’t know where they are. If the water level is high enough, you’ll never hit any rocks. If you gradually lower the water level, you will hit the highest rock. Now you can remove that rock and you can sail freely again. To hit (and find) more rocks you lower the water level again.