Agile @ Ardatis

An afternoon off

agile_development_in_the_large

Yesterday afternoon I went to a seminar on “Agile Development in the large”, organised by Ardatis. Johan Lybaert (Program Manager) and Jan Van Reusel (Development Manager) of Ardatis presented how their company has been using Agile Software Development techniques. They use a combination of XP and Scrum, modified to their own circumstances. Three developers gave a hands-on demonstration of extremely fast test driven development, not only of business objects, but also of their user interface.

Ardatis was assisted in the transition to Agile by Jutta Eckstein. Jutta co-presented the event, often in dialogue with Jan. As the team consists of 60 people, Jutta’s experience in large agile projects came in handy.

Fun

The presentation was very clear, with plenty of metaphors, funny bits and practical advice. I particularly liked the “Rules of the Game” sections. There were only a few, simple rules but these lead to complex behaviour. One of the key requirements for successful agile development they pointed out, is a high level of discipline in following these rules.

The presentation was interspersed with short video fragments. At the end, Jan seemed reluctant to show the last fragment. I’m glad he did. In this short video we saw the teammembers smile and laugh. They were having fun at work.

Enthusiastic about a methodology

Have you ever heard people talk enthusiastically about a methodology? I have, yesterday.

It’s happened to me a few times before. Customers who got more than they expected, in record time. CEO’s who quickly saw the results of their IT spending. IT managers who felt they really managed their projects. Sceptical users who, after using the system, asked to use the system sooner than planned; and “when can we have the next version?”.

I’ve never seen anybody get excited about waterfall, RUP or any other method. This only happens with agile software development. With non-agile methods, people were sometimes pleased about the result, but never about the way we got there.

It don’t mean a thing, if it ain’t got that swing!

There’s a bit of discussion about the “watering down” of agile. Everyone is using “agile”. Agile is good. Agile is the new apple pie.

Isn’t there a danger that people will get confused? How can we make the difference clear between “real agile” and the pale copies?

It’s simple: look for fun, enthusiasm, happy people. You can’t fake that.

Agile Development doesn’t need any marketing budgets. Just make your customers, managers and teams happy and enthusiastic. And let them talk.

Who have you made enthusiastic today?


Tags: agile

Collecting Fieldstones

Collection fieldstones

Weinberg_on_Writing

As you read earlier, I’m reading “Weinberg on Writing: the Fieldstone Method“.

I’ve begun to consciously think about how I collect fieldstones.

Slippery fieldstones

I get most of the material for what I write by reading, by thinking about what I read and by writing about what I think. There are plenty of fieldstones. The problem is collecting them.

I don’t always have something to write ideas down, especially when I’m reading. I have an inhibition against “mutilating books” by cracking their spines, writing in them, folding down corners of interesting pages or putting sticky notes in them. In any case, I don’t have sticky notes on me when I’m reading. This means I must trust my memory to collect interesting fieldstones.

A few days ago, I was re-reading “The Toyota Way” to collect material for my presentation at XP Day France, when I came across this fantastic fieldstone: “Obeya”. This was a perfect fit for what I wanted to convey with the presentation. With this word, I could link two sections of the presentation. I tried to remember the word. And I did… for 5 minutes, or so. And then I forgot the word.

I don’t worry too much when I forget something: if it’s important it will come back. “Obeya” came back when I was getting something to drink from the fridge. This time I could keep the word in memory long enough to write it down on the back of an envelope. Whew! Later that day, I added “Obeya” to the presentation.

Leaving stones behind is not too bad. If the fieldstones are good, they’ll turn up again.

Playing with words

Weinberg describes many ways of playing with the text. There’s one I used to use long ago at school, when I didn’t have any “inspiration” to write an essay.

I opened the dictionary at random points and scanned the pages for “interesting” words. There are many ways a word can be interesting: the sound or the shape of the word, the meaning, an “exotic” origin… I usually collected between 10 and 15 random words like that.

Then I shuffled the words. Weinberg calls this “playing Solitaire” with the words. Slowly, the words would prompt a story. The only thing I had to do was write that story down, using at least 10 of my “chosen” words. Quick and easy.

I particularly enjoyed obscure or unusual words. I pictured the teacher looking up all those words in their dictionary. I thought they might learn something by grading my work. I think they mostly learned that I’m an obnoxious smart aleck…

There are many more “games” like that in the book. I’m going to try a few of them. I particularly like “Dani’s Decimation”, a game where you remove 1/Nth of words from every sentence, 1/Nth sentences from a paragraph. It’s bound to simplify my writing.

Playing with structure

There’s another writing game that I play, that’s not in the book. For the “Things I didn’t Learn” series, I imposed a certain structure on the stories, to see what would happen.

I started with three stories and tried to give them a common structure. You need at least three exemplars before you can generalize (like in framework writing). You need at least three before you can start to talk about “series”.

Once these three stories were composed in my head, using the common structure, I started to think about other stories that I could fit in the format. Working against the limitation of a fixed format, I found more stories that would fit. Each of them had to have a certain structure:

  • I encounter a problem that others have also encountered
  • I solve it using an Extreme Programming or Agile technique
  • But I go back to using the tried and true ways. The problem reappears.
  • Everyone (me included) says “that’s how it’s supposed to be”. Software projects are meant to go badly. If there were a way that projects could succeed, we would have to change our ways of working. There is no such way, so we can’t be blamed if things fail.

An outline’s not for me

Weinberg warns that writing from an outline usually doesn’t work very well for him. It doesn’t work for me either. I prefer the collecting-shuffling-writing-rearranging method.

Sometimes I have to follow an outline. For example, the “Toyota Way” book contains 14 principles, which are part of 4 categories. I’ve kept this structure for my presentation. I use the 14 principles and 4 categories as a “backbone”. For the rest, I’ve collected fieldstones and put them where they made most sense. And then I rearranged them, and rearranged them again. I’m still rearranging and will probably continue to do so until the day before the presentation. But still, the 14 principles are there.

The 4 categories are still there, but I reordered them. The book presents the philosophy first. I prefer to keep it at the end. That way, the presentation ends on a strong note, building up from the Process practices like Flow, Pull, Heijunka… Then we have the People principles, then Problemsolving and finally Philosophy.


P.S. If you’re curious about the meaning of “Obeya” and you haven’t looked it up yet, “Obeya” is the Japanese for “Big Room”. It’s the name given to the practice of putting all people involved in the design of a car in one big room, so as to facilitate communication. This word is useful for two purposes:

  • “Obeya” is a practice that is the same in the Toyota Way and in Agile Development. It reinforces the idea that Agile and the Toyota Way share some practices. In the presentation, I want to show that they also share most of the principles, even if the practices are different.
  • “Obeya” links two sections, the one on “Learning” and the one on “People and Partners”. Letting people work together lets them learn from each other, encourages frequent integrations and speeds up “Nemawashi”, seeking consensus. Engineers from partner companies also work in the “Obeya”, so that their designs are perfectly integrated with the rest of the design. Working in the Obeya, these engineers experience The Toyota Way firsthand. They can become ambassadors and sensei of the Toyota Way in their own companies.

p.p.s. As you may have noticed, these days I like to write stories around obscure Japanese terms 🙂


Tags: agile, Toyota Way,XP Day

Running on Empty (2)

Setting the record straight

Vera has been reading my blog. She’s not happy with what I wrote in the “Running on Empty” entry. Vera was there, she knows that it didn’t happen like I described in the “Go Home!” section.

I wrote “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.

That’s not completely true… There was someone who told me to go home. Vera told me to go home, many, many times.

That’s me: blind, deaf and stupid

When you’re overloaded, you get stupid and your eyesight and your hearing goes. You no longer see the solutions, you don’t hear the advice people give you. Especially good advice like going home on time or doing important work in pairs.

One of the reasons I was overloaded, was that I had to take over a project from someone else. He had left because he was completely burned out trying to make this project work. I thought he was really stupid getting burned out, when everyone knew that working at a sustainable pace worked better. Yeah, that was really stupid…

Advice to anyone who works with Vera: just do as she says.


Tags: Agile, XP, Heijunka

Agile Open: Registration Open

agileopen_logo

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:

  • participants can submit ideas for sessions
  • at the start fo each day, we perform a quick planning game to select the sessions that will run in the two tracks

To get an idea of the range of session, take a look at the output of last year’s sessions.

Registration is now open! Don’t wait too long to register, as there are only 40 places.


Tags: agile, Agile Open,Open Space

Do you get what you measure?

FirstOrderMeasurement

At the XP.BE user group meeting hosted by ERG Transit Systems, we ran a workshop on “Management metrics”.

The people at ERG wanted to introduce some metrics to get feedback on their process improvement efforts. However, metrics can be dangerous. “You get what you measure”, but what you measure may not be what you intended.

We used a workshop format designed by Jason Gorman and Duncan Pierce to design, break and improve metrics. The session went like this:

  • we formed 4 teams
  • 3 people from ERG presented 4 requirements for metrics, one for each team. For the rest of the session, they acted as “onsite customer”
  • each team designed and presented a metric to satisfy the requirement
  • each team received another team’s metric and tried to “game it”, to subvert it to reach the opposite of the desired effect, or to score as high as possible with the least amount of effort. This was the fun part.
  • each team then improved their metric, taking into account the possible “misuse”
  • our customers performed the acceptance test. Each metric had to pass two tests:
    1. Would our customers be able and willing to implement this metric tomorrow?
    2. Would the developers want to work in a team that used this metric?

3 out of the 4 metrics passed the user acceptance tests. The fourth might too, with a bit of work. Not bad for 90 minutes of work!

ThroughputAccounting

Some things I learned about metrics:

  • No metric is fraud or misuse-proof, therefore people have to want to use the metric correctly. If people want to game the system, they can be very creative.
  • Metrics that take a noticeable amount of time and work to collect will not last long
  • It’s better to aggregate data, because errors in the individual items tend to cancel each other out. E.g. it’s easier to track the estimates of a whole release, rather than the estimates of each individual feature
  • It’s better to look at team results, rather than individuals, because of the aggregating and because that motivates people to work as a team. This is related to the “Reward one level up” rule I first heard from Mary Poppendieck.

I ‘d like to align metrics with the “Throughput Accounting” measures. I’ve added an “Idea for Session” about this topic on the Agile Open site. How about you?

More useful info and books on the wiki.


Jason and Duncan will host this session at SPA2006. Highly recommended!


Update 20/02/2006 Nico Mommaerts has blogged about this event too.


Tags: SPA 2006, Agile Open 2006, metrics, XP