Thinking for a Change

How do others do it?

We’re always looking for sessions that present case studies. People want to hear how other people like them have tried agile and have succeeded. Most companies don’t want to be the first kids on the block trying agile. But when they hear that other companies are doing it and succeeding, they will take action.

Presenters are sometimes reluctant to present a case study when “things haven’t gone perfectly”. We, and the audience, don’t expect perfect stories. They’re so boring! We won’t take home any lessons from it because we fear that we won’t be able to replicate that perfect situation. A story is much better if the plucky hero(ine) has had to struggle to overcome problems and if the result is not nirvana, just a better place to be than before.

We have 4 case studies in the XP Day Program, two per day:

• Test-driven development on a large scale project by Jan Van Reusel describes how Ardatis implemented test-driven development on a very large J2EE project. It’s very easy to start, but can you keep it up? Can you keep the test runs fast enough to give quick feedback? Can you keep the complexity of the codebase under control? Jan will tell about the issues his team faced and what they did about it. I like this session because it deals with the issues you’ll encounter in real life, once you go beyond the toy problems of typical TDD descriptions and demonstrations.
• Agile on the biggest J2EE project in the Benelux by Johan Lybaert presents how Ardatis used agile development techniques (SCRUM and XP) on what is probably the largest J2EE project in the Benelux. Scaling agile practices to such a large team and large application serving several customers is a challenge. Johan presents how his team did it, why they did it and how they overcame obstacles. I’ve seen this presentation twice. The presentation is very clear, humourous and explains very well how Ardatis did it, why they did it and what the results are. Ardatis and the people working there seem very happy with agile software development.
• Introducing unit tests to a large evolving application by Dirk Maegh and Olivier Costa presents the story of their team starting to add unit tests to a large, existing application. Not an easy task, as anyone who has tried it can tell you. It’s not just the technical problems. How do you convince a large team of developers to keep on spending time to write unit tests, even under pressure of deadlines? What skills do they need? How do you convince management to invest in improving the quality of the application? I like this session because, like the other unit testing case study, it deals with issues you’re likely to face when you want to retrofit unit tests to an existing application and organisation.
• Off-shore, fixed price and still agile by Marco Jansen describes how Thoughtworks India has used agile techniques on a fixed project that was run with two teams, one in the UK, the other in India. I think this session is interesting because we hear how agile was used in a setting where most people think agile is inapplicable: off-shore AND fixed-price. One of those is enough for most people to disqualify agile methods.

Do it yourself!

We have two sessions where you can apply all the agile techniques on some real code. Sometimes, the best way to learn is to just do it. A session like this creates a safe environment where you can experiment with different techniques, without endangering your real project.

I’m always a bit wary of including this type of session in the program. It can take a lot of effort to set up the environment. If the participants have to install stuff on their machines, we can waste a lot of time getting the session going. By necessity, these are quite long sessions, so you must dedicate half a day to one session.

In these cases, there’s less to worry about. Kathleen, Jan, Lasse and Markus have all run these sessions before. They know what they’re doing and the sessions will be well prepared and fun.

In the “Coding Tournament” session, Finnish agilists Lasse Koskela and Markus Hjort let participants write poker-playing bots, which then have to compete against each other. Lasse and Markus will bring the necessary libraries for java or ruby development. In this session you can experiment with different agile development techniques like test-driven design, automated test, refactoring, feedback from iterations and pair programming under time-pressure. The time-pressure and element of competition make this a fun game. In this session you will explore strategies for poker AND strategies for software development. Lasse and Markus have already played this game in their company Reaktor Innovations and at the XP2006 conference. Bring your laptop. May the games begin!

The “Agile Development Workshop” by Kathleen Cornelis and Jan Van Reusel is an intense session, where you can experience what it means to work in an agile team. The session features a scrum standup, programming in pairs, iterations, visualizing progress in a burndown chart and a retrospective. Kathleen and Jan have run this session before to let job applicants to Ardatis experience what it’s like to work for there. I like this use of a hands-on session during recruitment: it tells both parties a lot more than just an interview.

So, if you like to experience what agile development is and have fun, come to one of these sessions!

Introductions

On the first day of XP Day Benelux, we have a track with three consecutive introductory sessions. If you want to know what XP, SCRUM and agile software development are about, this is the place to be. We’ve put these sessions at the beginning of the conference, so that those who attend them can get more out of the other sessions.

I feel it’s important to ensure that there are enough sessions for people with little knowledge about agile. We need to attract new people; agile is still in the early phases. There are lots of people out there who are curious about agile. A local event like the XP Days is a great way to learn more and, especially, to meet people who are also interested.

The sessions

“The 3 XP Loops“ is presented by Vera Peeters and me. We’ve been giving this presentation for a few years now. The first few times we gave this talk, we were met with incredulity, lots of discussion and disbelief. Some of those incredulous people now give talks about agile topics themselves. Extreme Programming is less controversial these days, we’re met with less scepticism these days. We still start the presentation by asking the audience to “Pretend you believe us“. Suspend your disbelief for a while and hear us out. Afterwards you can decide if there’s anything in XP that is useful to you.

The presentation is structured around a drawing of the XP practices, which contains 3 connected loops: the developer/pair loop; the daily developer team loop; the whole team (including customer) iteration loop. Over the years, the presentation has become more “Zen“: fewer bullets, more pictures, more stories; less theory, more experience.

“What is Agile Software Development?“ by Rob Westgeest and Willem van den Ende takes the opposite approach from the 3 Loops session: Rob and Willem start with the values of the Agile Manifesto, the ideas behind agility, and then zoom in on how the different methods implement the values and practices. If you want the big picture of agility, this is where you’ll get it.

“Intro to SCRUM“ by Joseph Pelrine explains how the Scrum method works and why it works that way. Joseph has been applying agile methods for years now and is one of the earliest and best known Scrum trainers. Besides a really great explanation of Scrum, expect lots of stories from Joseph’s considerable experience. Bring all your Scrum questions to this Scrum Master.

With these three sessions down your belt, you’ll know more about agile methods than most. Each of these sessions is presented by people who have applied these methods for the past years, so you’ll get more than theory.

The making of the XP Day Benelux program

The XP Day Benelux program has been published. The sessions were chosen (by the chosen few of the “Program Committee”) from the session proposals that were sent in. How does that work? As they say, if you want to enjoy eating sausages, you’d better not look in the factory where they’re made… With this warning, if you want to know how it’s done, read on. Let’s have a look behind the scene…

First step: perfect session proposals

First, session organizers give each other feedback to improve their proposals. We use the “Perfection Game” format. This helps to get positive, constructive feedback. All the work is done on a wiki, for all session organisers to see.

My impression is that all session descriptions, even from experienced organizers, are better after receiving this feedback. Mine certainly are. I prefer to go through a few iterations, rather that have a “one-shot” at sending in a perfect session proposal. Session proposals are like requirements: those who write and read them have dreams of how this session will look like. Usually, completely different dreams. Asking questions and talking about them, helps create a common understanding. It doesn’t always work, but most of the time it does.

Your mission: design an interesting and balanced program

We have several goals for the program:

• There should be a good balance in audience background: beginner, practitioner, experienced
• There should be a mix of different subjects: technical, management, foundations and limits of agile, soft-skills “fluffy bunny” sessions
• There should be a mix of different session formats: tutorials, games, simulations, workshops, discussions… Everyone has their favourite ways of learning about new things. Some people just want to hear how it’s done; others don’t “get it” unless they’ve experienced it.
• There should be a good mix between local presenters and “international jet-setting gurus” who travel from agile conference to agile conference, like a rock act. 🙂
• It must all fit in two days, with enough time for breaks, food and rest. Sustainable pace, you know.
• We should not break any physical constraints: a presenter can’t present two sessions at the same time. Presenters who have more than one session should have some breathing room between sessions, so that they can relax and go to other sessions.

It’s not easy to solve a system with so many constraints. How do we do it? As with any question you ask an agilist, the answer is…

Index cards!

We put each session on an index card and try to lay them out on a big sheet of paper that represents the program. We can encode a lot of dimensions on a single card:

• The name of the session is on the card, so that we know which session we’re talking about
• The name(s) of the presenter(s) is there, so that we can spot conflicts
• The size of the card indicates how long the session takes. The sheet of paper indicates how long the conference is. We can’t put in too many sessions.
• The color of the card indicates the type of subject matter. It’s easy to see if the subjects are balanced.
• Green dots on the card indicate how much experience with agile software development is expected of participants to the session. It’s easy to see if we cater to participants with different levels of experience.
• Red dots on the card indicate how much the participants are involved in the session. It’s easy to see that we cater to the different learning modalities.
• We have four tracks. Each track has a certain theme or subject, to help balance the program. For example, there is an “Introduction Track”, so that we know that about 1/4 sessions is geared to people new to agile.

From then on, it’s easy: we take the sessions in order. First the sessions that got the best feedback in the perfection game, the sessions that we think will appeal to a large audience, the sessions that we think will be the most interesting. We quickly put them on the schedule, just checking that we don’t create obvious conflicts. When the schedule is full, we resolve conflicts and imbalances by exchanging pairs of sessions, until we’re happy. The system is very similar to the one we used in the army to fill in duty rosters. Or as they say in “The Toyota Way“: Visual Control.

You can see the result. Do you think we succeeded? Or not? Let us know.

If you want to know more, I’ll describe the sessions in the program and explain why I like each of them.

Finally! The program of XP Days Benelux 2006 has been published.

As usual, the program contains a mix of session on technical, management, people and other topics. A large number of sessions are interactive. There are both introductory and advanced sessions, so that people with different experience levels and interests can find something interesting in one of the four tracks.

We’ve got session presenters from Belgium (14), The Netherlands (5), The United Kingdom (4), Finland (2), France (2) and Switzerland (2). A good mix of “usual suspects” and “local talent”.

Register now, while there are still places left.

XP Days Benelux 2006

16 & 17 November 2006

Mechelen, Belgium

http://www.xpday.net

Joseph Pelrine will be giving a SCRUM training course in Mechelen, Belgium on 4 and 5 October 2006.

If you want to know what SCRUM and agile are, there are few people better placed to answer all your questions… or, more likely, to raise a lot more questions, knowing Joseph :-).

Joseph practiced agile before it was called agile, a.o. working with Kent Beck on Smalltalk projects. Joseph’s involvement in Smalltalk and agile is no coincidence. Smalltalk and the smalltalk projects Kent Beck did (including C3) were a major influence on XP. With all this experience, Joseph is a master story-teller. If you not only want to know what SCRUM is, but also the why, how and the history behind it all, come to this course!

Joseph was one of the speakers at XP Day Benelux in 2003. Will he make another appearance at XP Days Benelux in 2006? Watch this space if you want to know.