Thinking for a Change xpday

Unfortunately, we arrived in time to attend the keynote. Before the keynote, some music boomed out of the loudspeakers. What with previous night s drinks and the loud noise, most people quickly darted out of the hall.

When the keynote started, the presenters started to rap, shout and generate feedback with their mikes, accompanied by more music and slides about modernists who thought they knew all the answers. We now know they didn t and created some monstrosities (just check out some of the on the outskirts of French or Belgian towns). The presenters held forth about post-modernism.

I must have missed the joke or the irony, but I found the presentation irritating and left. Nice try to be original. If there was a message there, it got drowned in the sound and fury of the presentation.

I had a chat with Gill, Mike and Sue about their t. I was going to present the theory of Lean in my Toyota Way session, after which they could talk about applying these ideas in the real world. They seemed a bit nervous about doing their presentation and they thought I wasn t nervous because I had done this presentation before.

If only they knew. The only difference between an experienced presenter and a new presenter is that the experienced presenter doesn t show his nervousness. An experienced presenter knows he s not going to die on stage, but he still feels like he s going to
The first session was led by Chris Matts.

He introduced us to Real Options as a way to manage uncertainty and risk. We hate uncertainty, therefore we want to take decisions as quickly as possible. A bad decision is better than no decision.

Real Options are all about taking decisions at the latest responsible moment, when we have the most information. Most of the time, we ll have to pay something upfront to be able to postpone that decision, just like with stock options. Most importantly, we aren t always able to decide as late as we d like.

It s up to us to create the situation where we can decide later. The best example is Lean or the Toyota Way. By making changeovers (for example from one paint color to another) really fast, Toyota can delay the decision about which color to spray the car very late, when they have the order from a customer.

Thus, they don t have to speculate what color the customers will want and risk being left behind with a lot of unsold cars in a color few people want.
All this led nicely to my own session on the Toyota Way, where deciding at the latest responsible moment is just one of the myriad techniques. Like at XP Day Benelux, the audience seemed very interested but also a little stunned.

There were only a few questions and a little discussion. This is in sharp contrast with the sessions I ran in Paris and Geneva. In those two cases it was hard to bring the discussion to a close after the session, because people kept on asking questions and discussing the Toyota Way.

In the afternoon, I went to the case studies track. The Lean Software Development case study went over well. The other case studies were interesting too.

We like to hear how real people have overcome real problems on real projects and see that the theory works in practice. Most of the presenters were first-time presenters in front of a large audience and they did very well. I d like to invite them to a session for a few tricks and pointers.

Especially Jamie Dobson. Jamie, stop putting bullets three levels deep, in unreadable 12 point font on your slides! Just tell us your story!

That s what Dave Nicolette did: no slides, no music, just him telling us a story about two different ways to adopt agile methods in two different organisations.
The last session was another goldfish bowl, this time about courage. Courage is not the absence of fear.

Courage is what you do, despite being afraid.
And then, back to Belgium. Alas, no time to spend an Extreme Tuesday at the pub.

Unfortunately we arrived too late to attend the keynote. The train was delayed. The tube on the Northern line was full.

The tube on the Central was halted because someone was ill. When we arrived in the , the keynote was already in full swing and the hall was packed. Instead of Joshua Kerievsky s keynote, some coffee to wake up and time to meet the conference-acquaintances and hear what they ve been up to since we last met.

I went to the Turning up the heat without getting burnt session by Joseph Pelrine and Ben Fuchs. I couldn t attend this session at XP Days Benelux because my session was scheduled at the same time. In the first half of the session, Joseph and Ben talked about conflicts, explored our attitude towards conflict with a small excercise and offered us a cooking metaphor for team pressure.

Too little heat and the team stagnates; too much heat and they burn. As a cook/coach/leader you need to keep the team at the right cooking temperature. Some conflict is good for you.

In the second half, I was asked to take part in a Scrum from hell game. In this excercise, a Scrum Master is faced at the daily standup with a team whose members may or may not have a secret goal (like talking as much as possible, helping the Scrum master, not doing anything and hiding this fact ).
I ve played this game before.

I was a bit nervous when Joseph asked me to participate. I thought this was because I had to act in front of an audience and not use my native language, so I overcame my hesitation. It was only after the session, after I had some time to think about it, that I understood why I was hesitant: the excercise throws the scrum master into an impossible situation.

They have to suffer the diabolical antics of the hidden agenda players. And then the exercise is over. We don t get any advice on how to handle such a situation.

We are not shown any techniques we could use. We don t re-run the simulation to see if the techniques work. In the end, what do we have?

We ve had a jolly good laugh at the expense of the sweating scrum master. And then we move on. It wasn t clear to me how this excercise related to the rest of the session.

What would I have done as a scrum master in this situation? I would stop the standup. The only way to win this game is not to participate in it.

I would repeat the rules of the standup and ask for a check in (one of the protocols of ). I would check in first: I m willing to work with this team, following these rules. I m mad.

I m in. . Those who are willing to work in the team, follow the rules and be held accountable for the results, can check in too.

Those who don t, can leave now. That would create a conflict, but one which would clarify what everyone stood for. Hey, a conflict!

Wasn t this what this session was about?

Listen to my body. It s a lot smarter and faster than my brain.

It took my brain half a day to understand what my body had understood immediately after Joseph asked me to participate: I find the Scrum from Hell a useless and hurtful game.

Are we nearly there yet?
I had been asking myself the very same question as we traveled from Belgium to the Ironmongers Hall.

Clearly, we had not planned our journey well enough to arrive in time. I went to the session because of the promise of interaction and discussion and because tracking is useless unless we can tell when something is done. Ivan Moore was a bit flustered because of the large turnout.

Because of the large group, there wasn t a lot of interactivity, but there were many questions and remarks. The session confirmed me in my preference to estimate using story points , not ideal days or real time.
The day ended with a goldfish bowl discussion on simplicity.

As a severe treppenwitz sufferer, such a fast-moving discussion is not the ideal format for me
It was enjoyable to watch the dicussion go in several directions, but there wasn t anything memorable that I remembered from the session. Maybe that has to do with the last activity of the evening: trying to make a dent in Google s finances at their sponsored drink in a pub in Little Britain : free drink, food, t-shirts and gadgets. We had a long discussion with Joseph Pelrine and Ben Fuchs.

Robert Chatley and Giovanni Asproni (XP Day organizers) looked more relaxed than this morning.
I didn t stay too long. Next day was another full conference day and I had a session to present.

What happened on friday?
A few people less on Friday than on Thursday. The majority of those who only participated in one day of the conference chose to attend only thursday.

I don t know why this is. Maybe it has to do with the fact that we scheduled more introductory sessions on Thursday. One day at XP Day is a great way to get a taste for the different agile methods and meet other interested people.

At the opening, we again have official one minute presentations (OOMPs) to briefly try and convince participants to come to our session. Today I have two sessions.
Immediately after the opening, I presented .

This zen presentation explains the 14 management principles of the that readers of this blog are familiar with. For each of the principles I try to give the equivalent practice, principle or value in agile methods. Many of the process ideas are very similar.

This is no coincidence: many of the founders of agile methods have read the Lean material. I also include some anecdotes and stories, to bring the story more to life.
Participants in this session seemed interested, but also a bit overwhelmed by the pace of the presentation.

I go through some 125 slides in 50 minutes, condensing a 300-page book and my experience. I hope the participants got the overall ideas. I gave them a separate handout ( ), with a summary of the principles and a list of references where they can find out more.

Those who are interested can look deeper into the Toyota Way. I just hope I stimulated some people s curiosity. There were a few question during and after the presentation.

Unfortunately, we didn t have much time for questions and discussion, because the session was in a 60 minute timeslot. When I ve given this presentation before, there were always a lot of questions and a lot of discussion afterwards.
I will give this presentation again on Tuesday at .

Again in a 60 minute timeslot, unfortunately. But the session is followed by a .
Next, I went to Sven and Vera s session.

This was an introductory session. I liked the anecdotes that were told to illustrate some point. I had the feeling that most participants didn t expect an introductory session but wanted to get to the bit with the difficult issues in implementing CI and how to solve them.

We got there in the end and had some lively discussion about a huge legacy system with extremely long build times. I could see some resistance growing between presenter and participant. Luckily, there was a session about dealing with resistance later on.

After lunch, a session I had been looking forward to: Lasse Koskela s workshop. In this session, we examined a situation where someone resisted something we proposed. The workshop was structured as a little game that allowed only four moves:

Put yourself in the place of the resistor, assume that they are honest, intelligent and well-meaning.

Describe why such a person would honestly resist the way they did.

Understanding the reason why the person resisted, how would you respond?

I especially like the third step, put yourself in the place of the resistor, try to imagine why they would oppose the change.

As the goes:
Walk a mile in my shoes.
Before you abuse, criticize and accuse,
I see (and take part in) the escalating resistance pattern a lot. We propose a great change and encounter resistance.

We think What a #{@^! idiot! and try to sell our idea even harder, generating even stronger resistance.

Stopping and putting yourself in the other person s shoes helps. Explore the reasons for the resistance to come to a mutually satisfying solution. The Toyota Way practice of Nemawashi (taking decisions by consensus) is exactly about that.

Decide only when the proposal satisfies all stakeholders. If you rush or force the decision, you risk a lot of unspoken, undercover resistance.
The session started quite well.

The four simple rules gave us a useful framework to focus on the subject at hand. After two rounds, the discussion drifted more aimlessly. The see it from the resistor s eyes part was lost, as we all focused on ways to overcome the resistance, without really knowing its source.

Part of the problem was caused by moving the groups around: we ended up with a problem that none of the participants was familiar with. Therefore, most of our discussion was theoretical and not grounded in the reality of the situation.
The last session of the day was , hosted by Vera and myself.

We showed a few clips of presenters with different presentation and delivery styles. The participants discussed what they liked in each style. Then it was up to the participants to make their own Zen presentation, using the techniques they just saw.

The topic of the presentation had to be A funny thing happened to me at XP Days Benelux .
Each group gave a presentation tryout and got feedback from the other participants. They could then update their presentation and delivery.

The presentations and, especially, the way they were delivered improved a lot between the two runs. Tip for would-be presenters: do a tryout and get some constructive feedback!
By accident , this session was scheduled in the room where the plenary closing would take place.

By accident , we didn t have enough time in the session to let the teams present their final presentation. As a workaround, the participants gave their presentation during the plenary closing. During each day s closing the participants can tell us what they thought of a session, User Official One Minute Presentations (UOOMPS) .

During Tuesday s closing, participants were somewhat hesistant to jump on stage . Part of this was stagefright, part of it was that the room layout made it quite difficult to get to the front.
By tricking the participants of the session to give their presentations during the closing (with their permission), we tried to lower the barrier for other participants to also get on the stage.

We laid out the room differently, so that people could get to the front without having to climb over the furniture.
The other hidden goal of the Presentation Zen session was to show the participants that being a session presenter is not that hard IF you have an interesting story to tell. Hopefully some of this year s participants will be next year s session organizers!

Lots of smiling faces at the closing drink. Unfortunately, many people had to leave before the drink to catch trains, planes or avoid traffic jams. The organizers first cleaned up the conference and then sat down for a well-deserved drink and chat.

A few of us went out to a local restaurant to discover what crocodile and kangaroo taste like. Belgians eat the weirdest things!
And then off to bed.

Get some rest to be ready for . See you there! The 2006 edition of the was a success: the conference was sold out, lots of people from all over Europe (Belgium, The Netherlands, France, Great Britain, Ireland, Italy, Finland, Switzerland and Poland), lots of people frowning when they had to decide which session to attend, lots of people smiling during and between the sessions.

We ll post session materials and results on the and you can read about XP Days Benelux, but it s not the same. You had to be there.
What happened on wednesday?

Philippe De Bruycker took , Uberto and me on a tour in Brussels. I ve lived and worked in Brussels for many years, but I discovered some things I didn t know. Thank you, Philippe!

We went out for a pre-conference dinner in Mechelen and introduced our guests to the excellent beer.
And on the first day of the conference?
I arrived a bit late due to traffic (and maybe the effects of Carolus ).

We set up the session materials and the WIFI internet connection. This didn t go very smoothly, we couldn t access the network. Later on, Hans Keppens managed to get us access by some unorthodox reconfiguring of the router
After the opening, and I presented the , an introduction to extreme programming.

The presentation is structured around a of XP with three nested loops: the release loop (where you decide what you will build and evaluate if it s ready), the team loop (where the team daily coordinates their work) and the coding loop (where pairs work on the code). I think the anecdotes and jokes went over ok, but the session could have been more energetic.
In the afternoon, I attended Vera s session.

This was a mixture of presentation and workshop, where we evaluated the unit testing framework one of us used to see which features we wanted from it and which were supported by the framework. The results were quite similar across teams: most of us used the basic features, didn t use the more advanced stuff and missed features related to reporting, history of test runs or coverage.
The last session was workshop.

Rachel had put the XP practices, two by two, on flipchart sheets. We had to add post-its to each practice, with questions and variations about the practice. We did this in several rounds, moving from group to group, from practice to practice.

In the end, all of the sheets were covered with post-its with questions. Upon which someone exclaimed And they told me XP was simple This is anything but simple! .

In the XP loops session, we did tell people that XP was simple. We also said that XP wasn t easy.

tailoring parameters for the practices: e.

g. if you do standups, how often? Who takes part?

Where? How long can it take? What are we expected to say?

These are the agile factors the session was about, the things you should agree on before the project starts and keep on updating as you progress.

what to do when things go wrong, when there are difficult situations: e.g.

what do you do when people don t turn up at the standup? What do you do when someone doesn t follow the rules? That s a whole different topic, that s where leadership, team dynamics and coaching come into play.

Luckily, we had several sessions about those subjects.

The day ended with drinks offered by Sabine from (no Carolus this time, but Westmalle) and dinner, with a lot of discussion and some weird beer mat folding. More about that later.

And now, we pass the baton to .
Last week, I attended the tryout at the meeting organized by .
have again (after the ) created a great simulation, where you learn something about yourself.

I won t tell everything, that would spoil your surprise when you attend this session. The session had two parts. In the first half we formed trios and had to try to convince another participant to do something.

Each in turn took the role of convincer, resister and observer. Most of us failed to complete the task. A few had spectacular results: they could convince their opponent in a very short time.

Ignace then explained the model that forms the basis of the session: the Rose of Axen . Yves and Ignace acted each of the different stances. We then had to replay the same game and try to take the stance that we had the most difficulty with, the way of dealing with conflict we would normally not use.

This was not easy, but it turned out to work in my case. This exercise taught me two things:

You don t have to accept self-imposed limitations. Even if I don t feel comfortable taking a certain stance, that doesn t mean I can t apply it effectively when I need it.

This reminds me of the way I feel about results: they tell me what my preferences are, the way I will act if I don t think about it. They are not my limitations.

What s the right way to deal with a situation?

It depends. There is no one right way to deal with conflict. The Rose has different stances, we have to choose the one that fits the situation and the people we deal with.

In the short exercise, I went through three stances in response to my opponent s response. This lesson also came out of the Leadership Game.

After the break, we had another simulation situation, this time with the whole group.

Half of the participants acted out a situation, with cue cards provided by Yves and Ignace; the other half observed how the players dealt with the conflict. The simulation ran for two rounds, with a debrief and discussion after every round. The simulation was great fun, especially for the players who had to resist the leader.

They evidently relished playing the evil role and opposing the leader.
Some of my colleagues are still acting their evil role, up to this day. Or are they acting ?

Another fun session where I learned something about myself. It s not every day that happens.
Help!

My Team is at war!
As announced, the organizes a tryout of s session. In this session, participants experiment with different techniques of dealing with conflicts in teams in small role plays and simulations.

I m looking forward to this session. Last year, I participated in Yves and Ignace s , where we could experiment with different styles of leadership. It s fun and you learn something; you learn something about yourself.

Thanks to and for hosting and organising this evening. . As the Agile manifesto says: We have come to value individuals and interactions over process and tools .

No XP Day Benelux conference would be complete with a selection of people- and team-oriented (or fluffy bunny ) sessions. It s great that this subject gets more attention, even among those who would not call themselves managers . In an agile team, everyone is expected to participate fully and reflect on all aspects of good performance, including people issues .

We can all benefit of becoming more aware of how we and our teams (mal)function.
There is an aspect of this that sits uneasily with me. I don t know about you, but I trained as a Computer Scientist .

I m not a psychologist, nor do I play one on TV. I m certainly more aware of and better able to deal with people issues than I was before - which isn t saying much! But there are times when I ve told people in my team that I was neither their mother nor their psychologist, I was not the person to help them with the problem they brought to work.

Get some professional help if you can t deal with the problem yourself. You don t see psychologists give IT sessions at psychology conventions, do you? Well, I haven t been to any, so tell me it that happens or not
Dealing with difficult personal and team issues is hard and dangerous.

You don t want to make the situation worse than it was before. Luckily, we ve got some people who know what they re doing. Trust them.

(Help! My team is at war!) is a followup of and s very succesful session.

Yves and Ignace create a safe simulation environment where participants can experiment with different ways of dealing with conflicts within a team. The session is in Dutch, because its the organizers experience that it s a lot easier for people to concentrate on the content when they can express themselves in their mother tongue. Ignace is both an engineer and psychologist; Yves is an agile coach and trainer.

I ll attend this session at a pre-conference tryout. More about that later
and present issues and techniques at the team level in their session. In the session, Ben and Joseph present bits of theory, followed by practical exercises.

This will be a very interactive session. You re in safe hands with a trained psychologist and an experience Scrum master. I won t be able to attend this session, because my session is in the same timeslot, but I intend to be at the session at XP Days London.

Including by and in the program was a difficult decision. There is a danger that some conversations will become too difficult . However, this session is more an introductory presentation of a different way to understand and have conversations, not a workshop.

You may find the topic interesting, in which case the presenters can provide you with pointer to more in-depth information.
s is a more playful workshop, where we can explore where all the resistance against our brilliant ideas comes from. In the game, first , we bring up examples of resistance and then imagine why a sane, intelligent and well-meaning person would have those objections.

In doing so, we look at the situation from the point of view of the person we re discussing the issue. And maybe, this will lead to a better understanding of the situation and a better proposal from us. I m looking forward to this session: the format is very simple and it can give us valuable insights.

If this session works out, I ve got a lot of people with whom I want to play this game; people who encounter a lot of resistance. Have you ever encountered resistance when trying to introduce, say, agile principles or practices?
We always have some oddball sessions whose subject matter is not directly related to agility.

Or is it?
will teach us . Bernard will present the techniques from David Allen s book Getting Things Done , a pragmatic way of organizing life and work.

He will also show how you can use these techniques to improve working in an XP development team. I want to get more done; do you?
In the workshop, I introduce some techniques for presenting ideas.

The participants can then experiment with these techniques. The session is named in honor of , where he collects examples of great presentations and presentation techniques. Why would you attend this session?

You might be called upon to present your ideas to an audience; you might be asked to tell your colleagues who could come about XP Days; you might want to use more effective ways to get your ideas across. Have a look at some of the presentations linked from the and bring your laptop. Stop using boring bullet points.

Now. Here are three more technical sessions for programmers and testers.
and show, in the form of a Kata exercise, how you can apply Test Driven Design in a functional language in their .

We ve all seen TDD demos before, but this one is different in many ways. The particpants in the have developed several forms of programming exercises. In a Kata, the presenters solve a programming problem live, using TDD.

The aim of the session is to take small, clear steps so that everyone in the audience understands how and why the presenters take each step. In this session, Emmanuel and Christophe will use the Haskell functional programming language instead of the more familiar object-oriented languages. It s a great way to introduce an unfamiliar programming language.

The session also raises the question if the functional programming paradigm leads us to solve problems differently.
will present and discuss ways to . Agile methods have done much to emphasize testing and bring it to the attention of developers.

The gap between testers and developers has become smaller. Anko will tell us more about extending agility deeper into the testing profession.
asks a controversial question: .

Could it really be that a tool written by Mr Kent You Aren t Going to Need It! Beck contains some stuff you don t need? I m shocked!

How many of your unit testing framework features do you use? How much do you use of other frameworks features? What is the cost of frameworks, of reuse?

When is it more effective and economical to write than to reuse? Discuss these and other burning questions in this workshop. Starting off on the right foot.

.
The beginning is a very delicate time opens s . This is true of projects too.

The following sessions can help you get started.
In , and explain how planning is done in agile projects. This is a nice introduction to the subject with real life examples.

If you want to know how it s done, come to this session.
by and is a simulation where you get to experiment with different techniques to prioritise, estimate and plan non-functional requirements. Whereas the agile methods have a lot to say about functional requirements ( stories ), very little is said about more pervasive, application-wide quality requirements.

Some time ago I discussed with Johan about agile planning. He agreed that it could work for features, but not for security requirements. Johan argued that you couldn t plan security requirements in an agile manner.

I said you could. I just didn t know how. Now, Johan knows how.

It works. See? I told you so!

In , and lead a workshop where the participants look at the important things to agree on before you start a project. Agile methodologies leave lots of room for variations and tuning parameters and expect teams to tune regularly. How long will your iterations be?

When do you hold the standup meeting? Which one of those are important to agree upon before the start of the project? Which points do you really need to have consensus on before going further?

Bring your ideas to this workshop and explore them with the other participants. Next time you start a new project or a new iteration, you will have a better idea of the what you need to settle quickly.
Once you get going, you need to keep going, check where you are and adjust your course.

The following sessions will help you do just that.
In the session, and explain what continuous integration really is. Small increments, a system that s always working and rapid feedback are essential to keep going and to keep on the road.

This session explains how you do continous integration and what s in it for developers, testers, managers and customers. This is one of the base practices and principles. If you don t have continuous integration yet, come to this session to learn how and why.

If you integrate continuously, come to this session to contribute your experience.
and will teach us . is a wiki-based tool to write acceptance tests, conceived by .

Acceptance tests clarify communciation between customers and developers. This very interactive tutorial concentrates on the communication aspect of acceptance tests: it s all about creating a common language with the customer and within the whole team. If you really want to know what your customer wants, this session will help.

Are we there yet? Do you get that question often? Do you know the answer?

Does everyone on your project know where you are? by and lets participants explore different very simple techniques to make project status very clear. If you want to be agile, you have to change course.

You can t do that unless you know where you re going and where you are now. Warning: after this session you will have an urge to put flipcharts, whiteboards, index cards and post-its on your walls. Don t resist the urge.

Let everyone know where you are. Lean, not Mean
I m happy that there are two Lean sessions on Friday s program, as I believe Lean ideas are one of the main inspirations of Agile methods.
I present the .

Readers of this blog know my fascination with the Toyota Way. In this session, we explore the 14 principles of the Toyota Way, their equivalents in agile methods (if they exist) and how I ve applied them in real life . If you think we have nothing to learn from manufacturing, come to this session so that we can have a heated debate.

If you want to explain to a manager where all these weird agile ideas come from, you could do worse than use Toyota, the most successful manufacturer, as an example. The similarities between the Toyota Way and agile are striking. Coincidence?

I think not. This session has already run at and will be presented at .
In , , Tjakko Kleinhuis and use a simulation game to explain the Lean concept of Flow (one of the 14 principles) and how this can be applied to software development.

What s not to like in this session? It s about a central concept of Lean; there s a fun simulation; participants are involved actively; the session introduces a new idea and shows how it applies to software development. That s the quintessential XP Day Benelux session.

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.

by describes how 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.

by presents how 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.

by and 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 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.

by describes how 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 session, Finnish agilists and let , 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 and at the . Bring your laptop. May the games begin!

The by and 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 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! On the first day of , we have a track with .

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.

is presented by 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 : fewer bullets, more pictures, more stories; less theory, more experience.
by and 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.

by 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 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, session organizers give each other feedback to improve their proposals. We use the 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.

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
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 .

Or as they say in : Visual Control.
You can . 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 of 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.
, while there are still places left.

will be giving a 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 . Will he make another appearance at XP Days Benelux in 2006? Watch if you want to know.

You can from today.
As you can see, the isn t filled in yet. The session organizers are still improving the session proposals until the end of the month.

After that, the conference program committee will have the difficult task of choosing twenty-odd sessions from the 33 proposals.
If you ve been to previous editions, you know what to expect. Based on the quality of the proposals, I think this year s program will be even better than .

Whatever your role, intrests, background or knowledge about agile methods, you ll find something interesting, something new, something you can use at work in this year s program.
Registering for a conference without seeing the program. Now that s trust!

This month, we re reviewing the many proposals we received for our for . How does that work, what happens during that mysterious review period ? Let s take a look behind the scenes
All the session proposals are added to our session review wiki.

Everybody who has proposed a session gets access to the wiki. They get one month to help each other to improve their sessions and session proposals, by using the rules of the Perfection Game .
The perfection game is a simple format to give positive feedback, which is not as simple as it sounds.

This protocol (and many others I use) was devised by in their book. Subscribe to the podcast to know more about these protocols. We had at last year s conference.

If you give feedback, you have to give 3 things:

A score out of 10. The number itself doesn t have a lot of meaning, we use the number to see if we get closer to perfection (10/10) in each iteration.

What the proposer did to earn those points.

It s important to let the proposer know this, so that they keep or reinforce their strong points.

What the proposer should do to earn 10/10. This has to be clear, actionable advice.

This is the difficult part. When they first start using the perfection game, people usually sugarcoat negative feedback to make it look like positive advice. E.

g. Your proposal would be perfect if it wasn t like this . What can I do with such feedback?

Nothing much.

We ask each session proposer to provide perfection game feedback to 3 proposals, so that we get 3 reviews per proposal. Everyone can choose which session they review, first come, first served.

We have (at least) 2 iterations of feedback-improvement-feedback.
We don t talk agile. We don t do agile.

We try to live it.
It s not enough to talk the talk, you have to walk the walk. A conference about agility has to be agile.

The session review process is open, all participants can see everything. That requires a lot of trust and cooperation. We arrange for early and regular feedback; and we act on it.

We also review and correct our process.
This review process didn t spring fully-formed from our brilliant minds. We review and improve our process every time we organize a conference.

Our first process was simple and classic: people send in proposals, we select the good ones and reject the bad ones. The problem with that is that people have only one shot at writing the perfect proposal. No iterations, no feedback.

We had to reject sessions which might have become a lot better with some feedback. Not very agile.
We then tried a process similar to the one we experienced at the .

We wanted to attract local people as presenters. People who often didn t have any session writing and presenting experience. Therefore, the conference organizers acted as shepherds to help the session proposers to improve their sessions.

Afterwards, we were a bit uncomfortable with the shepherding bit. Did that mean we saw the session proposers as sheep? Session coaches is a better description of our job, but still there were two classes of presenters.

Next, we tried to involve the session proposers themselves in the review and selection process. Sessions were put on a wiki. Session proposers could review each other s work and update their proposals according to the feedback they received.

That worked a lot better. The only drawback was that our review process was a bit too heavy and that a review invites more criticism than constructive feedback.
So, this year, we simplified and replaced the review process with the perfection game.

Let s see how that works. Each year will be different, hopefully better.
Cooperation, open space, iterations, self-organizing doesn t mean there s no structure.

On the contrary, you need enough structure to make this happen. There are rules, simple rules, and participants have to abide by them. Setting up, guarding and updating the rules is the job of the organizers.

We own the process, the participants own the content and help us to improve the process. has invited and me to present our session at the . The conference is held on September 20th, 2006 at the University of Central Lancashire, Preston.

Are you local?
In his invitation, Kevin described the conference as a local conference, for local people . Accessibility is important.

We can t all afford the time and expense to go to international conferences in exotic places like Oulu or Minneapolis. Events like Agile North and the XP Days all around the world, bring agile conferences nearer to the people. These events are rooted in the local agile communities and feature local speakers as well as the usual suspects .

People tend to buy from people like them. Business people will listen to consultanty types explaining the wondrous advantages of agility, but they won t be convinced until their competitors start telling stories of their satisfied customers, increased cash flow and cost savings. Both types of speakers have their own type of credibility.

As the creepy shop owners in Royston Vasey say: Are you local? We re a local shop, for local people!
Talking of (what s with the ridiculous images that are totally beside the point?

) a certain industry thought leader is using some loaded questions in a questionnaire on his site to claim that 97% of all respondents indicated that the agile alliance needs to introduce new speakers at their conference instead of having the same speakers every single year .
As I explained above, real life is a bit more complicated than this black and white statement. As , we try everything we can to get new people to come and present their experiences.

Real people, real companies, real problems, real stories how they applied agile techniques. Do non-agile conferences (say, those organized by analysts or on enterprisey stuff ) have a better distribution between incrowd and fresh people ?
Do members of the Agile Alliance really believe in Agile?

he wonders, because some agile bloggers don t have trackbacks and/or comments. Subtle Hey James, spamming your way into people s blogs via trackbacks is not the way to start a great conversation. I allow trackbacks when they add something to the conversation.

p.s. was that answer the only useful one out of that whole survey?

What were the other results? The is coming to an end. Just a short time left to send in your proposals.

We ve already received a good set of interesting proposals from presenters from several countries. Send in one ore more proposals. We welcome pair presenters.

Your proposal doesn t have to be perfect: in true agile fashion, you will get feedback and you will be able to improve your proposal, before the decides on the program. Session leaders get free access to the conference.
The conference is in the lovely town of Mechelen, just north of Brussels and easy to reach by car and public transport.

It s quite likely that
See you there on 16 and 17 November 2006! Yes, it s call for session season again.
Hosting a session at a conference is a great way to learn something about your chosen topic, about presenting, about ways to make a topic understandable and about yourself.

I m one of the , so I d like to encourage you to propose a session for this conference.
We re looking for lots of different sessions, to cater to a diverse audience. Some people claim they ve been doing agile all their life; others have just heard about it and want to know more.

Some people are interested in hardcore technical topics, some are more into management, others want to explore more of the soft skills . Some people want to explore the fringe, new ideas, others want to learn practical techniques that they can apply the next day at work.
If you haven t organized a conference session before, there are plenty of friendly people who ll help you prepare and present.

And best of all: Belgian hospitality, great food and fantastic beer. See you there!