|
|
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 “Toyota Way of Managing Projects“. 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 XP Day France and will be presented at XP Day London.
In “Haste makes waste! Oh no, it does not!“, Rob Westgeest, Tjakko Kleinhuis and Willem van den Ende 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.
Emmanuel Gaillot has written a brilliant blog post about getting out of vicious cycles. It’s easy (for an outsider and to most insiders) to see when a team is in trouble, spiralling down towards a crash. If you’ve got a bit of experience in agile methods, you can come up with several ways to get out of trouble. Most of these changes involve going slower to recover some of the debt you’ve accumulated. But, like the White Rabbit, time is something these troubled teams don’t have. What now?
Emmanuel shows how you can start by “borrowing” 5 minutes of your employer’s time. Don’t ask for permission. Don’t tell anyone. Just do it. Invest those 5 minutes in some improvement, preferably on a bottleneck. Watch how this improvement saves you time. Reinvest that time into another small improvement. Before you know it, you’re reversing the vicious spiral and turning it into a virtuous cycle.
Now, we’ve all seen (or been part of) these teams where there’s never enough time. That’s the surest sign of a team in trouble: when they start saying “We don’t have any time to…”. That’s when they most need to take the time, slow down to go faster. It sounds paradoxical, but it works. I once gave a team the advice to dedicate half of their iteration to “debt-paying” work: refactoring, bringing the disused unit tests back, automating deployment. This team’s velocity had been dropping faster and faster each iteration. Slowing down was hard for this team’s leader to sell, but they had the courage to do it and they got back to a reasonable velocity. Don’t let your team get this far behind. Invest a few minutes now to save half an iteration later.
This reminds me of something Jim McCarthy says in the first of his “23.5 rules of thumb ot ship software”: people come up to him and tell him: “Great talk, Jim. But you’re talking to the wrong guy. You should be talking to my boss.” Jim’s reply is “I’m talking to exactly the right guy!”. It is your job to improve things around here. You can’t wait for someone else to do it for you. Do something. Do it now. What’s five minutes?
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.
|
|
