|
|
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.
Draw me a process
Rob and I made a small, but useful change to the “I’m not a Bottleneck! I’m a free man!” session at Agile North. During the second half of the session, we ask the participants to draw their process. Many participants have difficulty doing this. Where do you begin? Where do you end? Where are the boundaries? What to include, what to exclude?
At least now we know where to start…
Start at the end
 We now tell the participants to start with the customer. Our work only generates “throughput” (value to the company) when the customer pays us in some way for something of value we give them. So, start by drawing the customer.
From the customer, work backwards. What does the customer receive, that they value? A piece of running software? Where does that come from? And so on, up the value stream. We noticed that the participants didn’t get stuck drawing their process. It did take some effort to get started. We are so used to thinking forward. It may take a while before you switch from “The customer gives requirements” to “The customer receives running, valuable features”.
The idea comes from the practice of Lean consultants to walk and map the value stream backwards, from the customer to the source materials. This helps you keep the customer perspective and see opportunities for “Pull” scheduling.
In Will Self’s novel “My idea of fun“, the main character and his evil guru (“The Fat Controller”) take a mental voyage from a cotton shirt they bought, all the way back to the cotton pickers near the Nile. Will Self invented the term “Retroscending” for this exercise. Next time, you think about your software process, try to retroscend.
In yesterday’s post, I told how Rachel Davies encouraged us to reflect and improve using “Retrospectives”.
 Great advice, but how do you convince people to hold a retrospective? How do you organize a Retrospective? How do you get useful information? What do you do with what you learned during the retrospective?
The classic book about retrospectives was written by Norm Kerth. It answers all of these questions, and then some more. There is a particular emphasis in the book on creating a “safe environment”, where everybody can contribute without fear. Especially when the project hasn’t gone too well (and you could well learn a lot of useful information), you need to do a lot of work to get rid of the “poisonous” atmosphere that may have built up in the team. I spoke with Norm at SPA2006 and attended his keynote. If I have a team that’s really in trouble, I’d want Norm to come in, because he has the experience and techniques and knows how to deal with difficult situations. And he can tell great stories.
 Ester Derby and Diana Larsen have published their “Agile Retrospectives” with the Pragmatic Programmers. As usual with the Pragmatic Duo’s books, it’s a thin (+/- 160 pages) book with large readable fonts and many illustrations. There’s less information (the first 40 pages or so) about how to lead retrospectives than in Norm’s book. This is more a book for people who know what retrospectives are and can get more information from other sources, like the “Retrospective Facilitator’s Gathering“.
As the book says at the end of chapter 3 “Leading Retrospectives”: “You are probably an expert at what you do now. Facilitation draws on different skills than most of us develop working in software. Facilitation also requires a different perspective. It takes time and practice to feel comfortable with new skills.” Effectively facilitating a retrospective (or any other event) takes a lot of skill. Having such a short introduction to the skill of facilitating retrospectives, this book is more aimed at people who already know what retrospectives are and have performed some. There’s not enough information for newbies, who are better served with Norm’s book.
Where the book shines, is in the second part. Here, we find a large list of activities we can perform during a retrospective. Each activity starts with a “Purpose” section, so you can select the right activities for the goal you want to reach. The activities are organized in several sections, for each phase in the retrospective:
- Setting the stage
- Gathering data
- Generate insights
- Decide what to do
- Close the retrospective
I found some interesting activities that I can apply and some ideas for new activities. The handy reference format is a useful tool when planning a retrospective. When you run regular retrospectives, participants can get bored with performing the same activities over and over. Having such a wide selection of activities to choose from, makes it easier to keep retrospectives “fresh” or selecting the appropriate activity for the group and situation.
This book is recommended for people with some experience with retrospectives. As with most things where humans are involved, a word of caution is in place: be careful, you’re dealing with people’s emotions and feelings. A retrospective after a succesful project is relatively easy. A retrospective for a challenged or failed project is hard and dangerous. Get a pro or some training before you embark on such a venture.
Retrospectives are absolutely essential to become and stay agile. But be careful out there. “Coach” or “facilitator” is not a term that should be taken lightly. It takes skill and experience.
 I spent a nice day at Agile North in Preston, on Sepember 20th. The Agile North group organized this one day Agile conference.
Rob Westgeest and I met at Manchester Airport with Kevin Rutherford, who drove us deftly to Preston, just before the approaching traffic jams.
The conference started with a keynote by Rachel Davies, current chair of the Agile Alliance. The talk told us how Rachel got into agile software development and her advice on moving to agile software development. Her theme was a common one among experienced agile practitioners: it’s about the values and principles. You’ll have to tailor the practices to your own situation. Start with a documented agile methodology, any methodology, the one that seems to fit your environment best. Start delivering and reflecting upon what you do. Adapt the method. And again. Use retrospectives for the reflection part (more about that later).
The first session was a goldfish bowl, organized by Charles Weir (on the left of the picture, seated on the table) about “Dealing with Customers”. Unlike most goldfish bowls I attended, this one was relaxed and featured some interesting discussion and tips on how to work effectively with customers. The audience had a nice mix of experienced people who could tell stories of success and failure, and people new to agile, looking for ways to improve their customer relationships.
The session was not about great ideas and breakthroughs. Most of it were small, simple ideas that everyone could apply, few of them specific to agile development. It does take sustained effort to create and maintain a great customer relationship. And again, the advice was to solve your worst problems (or bottlenecks) and to adapt to local circumstances.
I would have liked to attend the Rails session too, but you can’t be in two places at the same time…
 After lunch, Rob and I organized the “I’m not a bottleneck! I’m a free man!” session. In this two hour session, we first introduce the “5 focusing steps” in a simulation, where the participants are asked to implement a paper boat and hat folding company. The workers got paid in chocolates.
In the second hour, some people come forward with a process that they want to optimize. The other participants act as Theory of Constraints consultants, coached by Rob, Kevin and me.
In the picture, Kevin proudly displays the result of his team: at least one way each to “exploit”, “subordinate to” and “elevate” the bottleneck of the customer. This particular system has a loop in it: software is tested and if it is defective, it is fixed and tested again. If you’re going to map this process to find bottlenecks or make a “value stream map”, it’s easiest if all the loops are unrolled and you get a linear process. How do you unroll the loop? You could take the average situation (e.g. it takes one fix-retest cycle on average); you could take a specific examples (e.g. feature XYZ went through 3 fix-retest cycles); or you can put a fork with probabilities in the diagram (e.g. 80% of all cases do not need retesting, 15% need one fix-retest, 5% need two fix-retest cycles).
The last session of the day was about agile in large organisations. I was quite interested, as I currently work for a largish organisation myself. The presenter didn’t get to finish his story, because there was a rather large amount of push-back and questioning from the audience. I didn’t get the message of the session. I’m still interested in the subject, so I’d like to see the rest of the slides.
Finally, we had a panel, where the audience could ask the “experts” questions. Rob and I had to decide which one of us would be on the panel. Rob lost, so he had to answer all the difficult questions 🙂
Agile North ended with a quick pint at the pub (kindly sponsored by Kevin) and an even quicker drive back to Manchester to catch our flight back to Belgium. All in all, a good conference, nice turnout, well-organized, interesting sessions and discussions with other participants. Thanks to the organizers for inviting us. I’ve enjoyed the conference, hope you have too!
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
|
