|
|
 I’m again organizing XP Day Benelux with Vera, Marc and Rob. This year we’re back in the Netherlands, in Rotterdam.
It’s the third time we organize this event and it keeps getting bigger. This year is the first time we have two conference days. This brings with it some extra work (e.g. people need to stay overnight), but the growth and extra work is still manageable with the help of Marko, Willem, Nynke, Erik and Peter. We already have experience with two day events, because the Agile Open conference started out as a two day conference.
The conference will be held on November 17th and 18th, only a month from now. Still a lot of work to do, but things seem to go smoothly (for now…). I’m currently mostly working on handling the registrations, invoicing, payments. We have a little application to help us with that and I’ll tell a bit more about it later.
I’m also co-presenting two sessions at the conference:
And that’s not all… November is “conference month” for me:
 I’ll be going to the German XP Days on November 21st in Karlsruhe. My boss (me 🙂 won’t let me go to such conferences unless I present a session, so that’s what I’ll be doing. I’ll be hosting a session on The Toyota Way, similar to the session I hosted at the XP2005 conference in Sheffield this year.
 And I’m also going to XP Day London on November 28th and 29th. The London XP Day inspired us to do something like that ourselves. I will be hosting the I’m not a bottleneck! I’m a free man! with Rob Westgeest.
There’s a lot of cooperation and exchange of ideas between the different XP Days. And soon we’ll have XP Day France!
See you at one of these fine events!
Final project burn up/down chart
 I’ve posted some pictures of our project’s burn up/down chart before. Reminder:
The green line represents the percentage of planned value implemented. By the end of the project we expect this to reach 100%
The red line represents the percentage of planned effort todo. By the end of the project we expect this ro reach 0%
Updates are performed every week by counting the cost and value estimates of each implemented story. The crosses indicate where we want to get.Did we get to our goal? As you can see on the picture we got a little more done than expected:
- We delivered 132% of planned value
- We performed 116% of planned effort
In normal people’s words: our users got a bit more than planned. Notice how with 16% more effort we were able to generate 32% more value. That’s because the customer (when we notified them that we could do a bit more than planned) was able to add stories that:
- had relatively low cost estimates. If they hadn’t we wouldn’t have added them late in the project.
- had relatively high value estimates. If they weren’t so valuable, the customer wouldn’t have risked adding more work and change to the project.
There are more interesting bits of information that can be gotten from this graph:
- in the middle of the project, we had two weeks with flat lines, where no stories were finished. None. This indicates that our stories were probably a bit too big.
- the work graph drops quickly near the end of the project. Several stories were waiting to be finished and they got finished just in time. This could mean we had “too much inventory” (in Lean terms): we had started too many stories at once.
- the final week or so is flat. That’s when we did formal acceptance testing, preparing to put the application in production. So, it’s normal that we don’t add more features then.
Looks good… Our velocity has gone up, again. We can promise a bit more for next release. Or can we?
This release had a lot less user involvement and testing than any recent release. Time pressure, holidays and lots of work on the user’s side took away a lot of time that could have been spent on the application.
- We can expect more problems than usual with this release. That will take some time away from new development.
- We need to spend more time with the users, to explain the release, set up more effective test sessions. That will take some time away from new development.
- The users are nearing the point where new features are implemented too fast for them, as predicted earlier. They can’t specify and test the features as quickly as they can be developed.
All of these reasons indicate that instead of going faster, the team should go slower. The bottleneck is shifting from IT to users. It’s time for IT to subordinate to the users and help them elevate the constraint, in Theory of Constraints terms.
But that’s no longer my job. This was my last release for this company. I’m off on holiday, so that I again have the time to blog and to organize and participate in the XP Day conferences all around Europe
Thanks to Nathalie, David, Nico and Thomas. It’s been fun. Keep up the good work!
Picture courtesy of Nico Mommaerts
I’m reading the downloaded Thinking Forth PDF by Leo Brodie.
The preface to the 2004 edition starts off a bit strange:
- in the 1984 preface he disses object oriented programming
- in the 1994 preface he apologizes for that, after having worked a bit with an OO Forth
- in the 2004 preface he partially retracts his apology and notes that he by no means has sold out in favor of full-blown OO languages, because “there was no need for garbage collection etc” in the OO forth
- and then he disses Extreme Programming. Some people have noted parallels between Thinking Forth and XP: iterative development, incrementally enhancing code that works, not over-solving the problem. But XP does no conceptual design, from what he’s read about it. He concludes the preface with: “But the irony in comparing Thinking Forth with Extreme Programming is that some developers of the XP stripe (and who of course have never heard about this book) don’t even see the value of a spec! Ah well.“.
Ah well.
But there’s a lot of stuff that resonates (again) with thoughts about DSLs:
“An important result of this approach is that the entire application employs a single syntax, which makes it easy to learn and maintain.
In fact, you shouldn’t write any serious application in Forth; as a language it’s simply not powerful enough. What you should do is write your own language in Forth (lexicons) to model your understanding of the problem, in which you can elegantly describe its solution.“
And on design:
Forth is a design language… In Forth you can write abstract, design-level code and still be able to test it at any time by taking advantage of decomposition into lexicons… Using this philosophy you can write a simple but testable version of your application, then successively change and refine it until you reach your goal.
How very much unlike design in XP!
And on planning:
Forth programmers spend less time planning than their classical counterparts, who feel righteous about planning. To them, not planning seems reckless and irresponsible. Traditional environments force programmers to plan because traditional programming languages do not readily accommodate change.
The book mixes Brodie’s views with interviews of people using Forth and of Forth’s creator Chuck Moore. The advice they give is often contradictory (plan more, plan less), as each gives the advice that is applicable in their situation. I remember that at the time I first read this book, one of my colleagues (who liked Forth) said he hated the book: “Can’t they make their minds up? They constantly contradict what they said a few pages before!” 🙂
I especially like Moore’s bits. One of the tips is: Don’t write your own interpreter/compiler when you can use Forth’s
Moore explains it thus:
If you write your own interpreter, the interpreter is almost certainly the most complex, elaborate part of your entire application. You have switched from solving a problem to writing an interpreter.
I think that programmers like to write interpreters. They like to do these elaborate diffcult things. But there comes a time when the world is going to have to quit programming keypads and converting numbers to binary, and start solving problems.
Take that you evil purveyors of badly designed programming languages disguised as configuration files or (the horror!) XML files!
Today was a book day
What did I find on my doorstep today? A big box full of books from Dorset House Publishing.
 |
Inexplicably, most of Gerald Weinberg‘s books are very hard to come by. He has written excellent books about Systems Thinking, the psychology of programming, congruent action, requirements, consulting… His books are required reading. So, I sent off an order directly to the publisher for myself, Laurent, Marko, Vera and Nico.The stack of books sitting now on my desk covers a lot of subjects: productivity, walkthroughs, requirements, systems thinking, measurement, psychology and organisational maturity. The two most ordered books are “The Secrets of Consulting” and “More Secrets of Consulting”.More on a few of those books later. |
 |
And on top of that box was another book: the paper copy of the Ruby on Rails book I’ve been reading in PDF pre-release form over the past month.We’ve started up development of an application to manage the registrations, payments and communications around the XP Day Benelux 2005 conference. This application uses Rails. We hope to see through the hype and learn if RoR is really so “Agile” as it claims. |
 |
And then a question about Domain Specific languages made me look up some more information about the Forth language. Forth was (a long long time ago) the first language I used that encouraged the programmer to build domain specific languages. Forth itself is a very primitive and simple language. But it allows you to create slightly higher level language elements or “words”. There is no (visible) distinction between those new words and the built-in words. And then you use those words to build slighly higher level words… Until you end up with a language that makes it easy to develop your application.So I went to look for Leo Brodie, whose books “Starting Forth” and “Thinking Forth” really made me understand this weird language and its even weirder way of programming. I wanted to buy these books for a long time, but they were out of print. And now I discover that “Thinking Forth” can be downloaded from Leo Brodie‘s site and has been re-published. I sent my order off to Amazon. Can’t wait ’till it gets here. Until then I’ve got some other books to keep me busy. |
A potential new bottleneck
Last week we noticed that some of our users didn’t know some features were available or were unsure how to use the new features in the previous release. So, we spent some time explaining some of the features.
This is a timely warning: our ability to effectively transition the software into production use could become a bottleneck. This is both a good and a bad thing:
- It means that our bottleneck, the development team, has been elevated to a level that’s nearer the capacity of the users to accept new features. This is good: our efforts to elevate the constraint are starting to work.
- Our capacity to train users and the user’s capacity to accept new features might become the new bottleneck. This is bad news: we don’t want the bottleneck to get out of our control.
This is a typical pattern for agile processes: the development team is elevated and after a while the customer, who subordinates to the development team (as the XP customer does), becomes the bottleneck. Suddenly, the customer can’t write stories fast enough to keep the team occupied; releases are implemented so quickly that the users can’t keep up with the flood of new features.
What to do?
Before the users become the new bottleneck, we need to take measures to elevate them so that the bottleneck doesn’t shift. What are we going to do?
- We have regular meetings with our key users who follow up new developments. We need to make these more “hands on”: show the users how new features work, let them experiment some more.
- Training and transition to a new release is handled by people in the users’ organisation. We can support them more during final acceptance testing and transition to the new release.
- We can hold an “end of sprint demo”, like Scrum prescribes to show the new features (and how they’re to be used) to a wider audience than the key users.
- Each release is focused on one group of users. For example, the current release contains mostly features for the commercial people. They will need some training to use the new release. Other groups will see only a few minor changes, so that for them the application doesn’t change too much.
Release less often?
Some have suggested that the problem is caused by us releasing too often. We release every two months. Should we release less often? I don’t think so: we used to release every 6 months and that caused big acceptance, transition and training problems. In comparison, today’s problems are insignificant.
I would suggest to release more often, establish a regular rhythm of changes. Have each release contain fewer changes, changes that appear shortly after the users ask for them and they’re fresh in their mind. Get a regular rhythm going on the “drum“, increase the “takt time”, level the load to reduce the waste due to unevenness.
Making change routine
People don’t like to change. They like routine and predictability. How can we make change easier? Regular “Kaizen” events, regular retrospectives to steer the process establish a rhythm of change. If you review and improve your process each month, every month, people become accustomed to the change.
If you want to change the routine, make change routine
|
