This will be two days of engaging discussions around Agile in General. Don’t expect polished presentations, it’s all about sharing ideas and interaction.

To learn more about the Open Spaces concept, check out the description.

This Agile-fest is kindly hosted again by IBBT.

In this edition, we would like to support learning/exploring ‘Agile’ by experience and call upon your imagination to come up with agile simulations, games. Of course plain old discussions are fine too!

Register now.

See you there

This year’s Agile Open Belgium will again be held in beautiful Gent, on May 21st and 22nd.

The Open Space format lets participants determine what’s on the program, how sessions are run and what they want out of the session. The conference location at IBBT provides several rooms, so that each session can run undisturbed by others while allowing participants to move easily from one session to another.

See you there!

We planned to start day two with a re-planning session: look at the plan we made yesterday and adapt where necessary, based on new information. Raphael then asked the question if we shouldn’t try to go more with the “open space” idea, instead of having planned sessions. We decided to have a planned session in one track (the XP Game) and an unplanned session in the other track.

That meant I got to play an XP Game for the first time, after having hosted so many runs. I discovered I’m crap at inflating and putting knots in balloons. Halfway through the game I had to leave for the next session. This gave my team the opportunity to learn what you do when 1/4 of your team leaves: you reduce your velocity to 3/4 of what you produced in previous releases.

Metrics and Thoughput Accounting

I proposed this session to get some input. Throughput Accounting has basically three important variables, expressed in monetary terms for convenience:

• Throughput = fresh money coming in from sales
• Operating Expense = money going out to keep the company going. Once spent, the money is gone (wages, energy, rent…)
• Investment = money that must be put in to be able to generate value. This is the most tricky category to explain.

Of course, time is also involved. The longer the time it takes to generate throughput, the higher the investment will be. To emphasize the fact, I keep time as a separate variable. All these variables are pretty easy to measure at the company level. We want to align the work we do with an improvement in these company metrics: increase throughput or decrease time, investment or operating expense.

The goal of the session was to find some metrics or indicators at an individual (IT) project level. We brainstormed some potential metrics for each of the 4 throughput accounting variables.

The throughput accounting variables and formulas are very simple. The only problem is that all the variables are interrelated. If you change one component of I, it’s going to have an effect on t, T and OE. And vice versa. You can’t really create a mathematical model of a project, but you can apply systems thinking. The advantage of methodologies with short iterations or releases is that you shorten the feedback loops, thus making it easier to see the result of your action and react in time.

We didn’t come to a conclusion. I’ll have to do some more thinking about it. Expect some throughput accounting posts in the near future…

What documentation do you wish for?

At the end of the session, someone asked the question “If you arrived on a project, what documentation would you wish to be there?”. The image contains the list of what we wanted.

We quite liked to have an installation manual and documentation about the development environment, to be able to see the application and get stuck in developing some new stuff. To understand the big picture, we like to see the “system on one page” and some explanation of all the (seemingly) weird decisions that have been taken during the project.

For people outside of the development team we recommend an operations/maintenance manual, which contains all the information you need to keep the application running. Some users might need a user manual or online help.

Acceptance testing documentation

What I’m currently struggling with is: “How can we test the quality of documentation? Can we write acceptance tests or fit criteria beforehand to drive the writing? TDD: Test Driven Documentation?”

Answers on a postcard…

First session in the afternoon, we did the “Presentation Zen” session. We looked at a few examples of modern presentation styles, starting from Garr Reynolds‘ Presentation Zen site. We formed 4 groups and asked each team to give a presentation about what they liked and disliked. The teams presented their findings, first in a rehearsal, then to the people who weren’t in the session. It was a fun session (an important part of “presentation zen”), with a lot of creativity. Let’s hope we can reduce the number of bullet points in the world. Stop reciting bullet points today; start telling stories; start answering people’s questions.

Presenting the zen way

Vera, Willem, Kristel and Lieven explaining that you have to structure your presentation with the audience and your goal in mind.

They started out with a distracting, dense bulleted page. Then they presented the same information in several slides, using humor, asking questions of the audience and keeping us awake with their quattro presentation technique.

They stressed the fact that slides and documentation (handouts) should be different.

Bernard, Stijn, Hans and Paul presented themselves and what they liked and disliked in the different presentation styles.

They didn’t like the frenetic pace and many slides of a Dick Hardt or Lessig presentation. They feel it’s too intense and too easy to lose the focus of what the presenter is trying to tell.

They did like funny presentations, creativity and keeping the attention of the audience by the use of repetition, something you’ll encounter a lot in “Lessig” style presentations.

Johan presented the idea that the slides should underline, strengthen or summarize what the presenter is saying. It’s not the slides that tell the story, it’s the presenter.

I liked the fact that this team didn’t explain the different techniques, they showed them. “Show, don’t tell” at work…

Klaas used a “Takahashi” style (a single word per slide, in big bold letters) throughout his presentation. He explained what the different styles were about.

This is very much a presentation style where all the attention is focused on the presenter and the story they’re telling. The slides are sparse and stark. Klaas did need more words and more time than the previous team to explain what the different styles were about. Sometimes, an image does say more than a thousand words.

What’s it all about?

What is that “Presentation Zen” thing all about and why host such a session at Agile Open? It’s not about powerpoint gimmicks and who has the most slides in his deck. It’s not about getting rid of bullet points. That’s just a symptom, not the root cause.

It’s about communicating our ideas effectively; getting the story across. It’s about storytelling and fun; engaging the audience. If you want to talk to people about agility (or any other subject that you feel strongly about), you first have to make sure that they don’t fall asleep, that they listen.

Marc Evers and I hosted a “Thinking for a Change” session. Not the whole session, just the “Current Reality Tree” to discover root causes of problems participants brought to the session.

Team 1: the build keeps failing

On the left, the first group. They analyzed a problem where a team had a failing build for days on end and didn’t do anything about it.

You have to wonder why they put the automated build and tests in place. What was their goal?

Team 2: balance between work and life

The second team, on the right analyzed the root causes of a situation where the balance between work and life wasn’t right. This was due, amongst other things, to long travel times between home and workplace. We had a similar situation during the session at SPA 2006.

You can use the thinking tools for other things than technical problems.

Team 3: getting two teams to work together

The third team analyzed a situation where development and operations teams didn’t work well together.

This situation was quite similar to the one I present to explain the technique, except that my example talks about one team and this situation was about the whole company. I managed to resolve the problem for one team. It will take a bit more thinking and effort to solve it for the whole company.

Finding the root of all evil

The teams found some potential root causes for their problem, but they needed a bit more time than the 90 minutes we spent today. I hope the three “customers” got a bit more insight in their situation. I find the Current Reality Tree a very useful tool to concentrate on a problem. All too often, we jump directly to a solution, before we really understand the problem. The CRT steps force me to go slowly and study the problem in depth, before I can start to think about solutions, with the Future Reality Tree.

I use the Thinking Processes every day, together with the other people who are involved in the situation. I don’t need to explain the technique, we just do it. All it takes is a piece of paper, a pen and a few people who want to solve a problem.

Planning a conference

First thing in the morning, everyone briefly presents the session ideas they put on the conference site. Some sessions got invented on the spot. Usually, these are of the type “I have a problem with X. Who can help me solve this problem?”.

After that, everybody votes for their favourite session by putting stickers on the session descriptions. Then, it’s a simple matter of scheduling the sessions in 6 slots in 2 tracks, taking into account the constraints:

• A session leader can’t do two sessions at the same time
• We have one large room and one smaller room.
• We have one beamer.

We made a definite schedule for today and a tentative one for tomorrow. Tomorrow we’ll revisit the schedule and may reschedule, based on the new information we’ve gained.

We will organize the second Agile Open conference on 27 and 28 April 2006 in Mechelen, Belgium.

Early registration for Agile Open 2006 ended on Friday. As usual when you set deadlines, a lot of registrations came in on the last day. Student Syndrome at work. Or is it the “Decide at the latest responsible moment” Lean principle at work?

We’ve now got 24 early registrations, that’s as many as the total number of participants last year. For the organizers, that means we’re in the “good scenario”.

Before every event, like the XP Days Benelux, we perform “scenario planning”. We explore different alternatives and decide what we would do in each scenario. We always have at least 3 different scenarios: “bad” , “normal” and “good”. As time goes by, we compare reality with our scenarios and see which one fits best. Of course, we adapt as new information emerges. We also keep a risk list, so that we know how to react when something bad happens. Both of these practices help us to organize an event without too much stress.

Why not try some scenario planning on your next project? Try to imagine a scenario where everything goes wrong; picture another scenario where everything goes well. How will you react when the different events happen? A scenario is not a prediction, a scenario helps you to recognize important events early and to be ready to react appropriately. Of course, you keep updating your scenarios and risk list as you get more information.

If you want to attend Agile Open, don’t wait too long to register, as there are only 16 places left.

p.s. What’s that “A princess arrives…” risk about? During the second XP Day, we heard the day before the conference that a Belgian princess would attend another event in the same location. Due to security reasons, we couldn’t have one of the rooms we had booked. Unfortunately, the replacement room we were offered, was quite far away from the other rooms. In the end things got resolved and we got all the rooms we had booked.Lesson learned: even if you do risk analysis beforehand, stuff will happen. From now on, the Princess is always on our risk list: both Belgium and The Netherlands have princesses. The Princess risk stands for any event where we can’t get the rooms we booked. We’re prepared for that. What new bad stuff will happen this year? Stay tuned…

Tags: agile, Agile Open, Open Space

We will organize the second Agile Open conference on 27 and 28 April 2006 in Mechelen, Belgium.

Agile Open is an open space conference about Agile topics. The idea is simple:

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

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

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

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

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

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

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

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

Some things I learned about metrics:

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

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

More useful info and books on the wiki.

We will organize the second Agile Open conference on 27 and 28 April 2006 in Mechelen, Belgium.

Agile Open is an open space conference about Agile topics. The idea is simple:

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

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