Agile Open Belgium 2013

22-23 March in Brussels, Belgium

Agile Open Belgium is an open space conference in the tradition of Agile Open conferences.

You determine the subjects on the program.

Join us on 22 and/or 23 March in Brussels.


Agile Open Belgium 2011

On Friday 20 and Saturday 21 of May Agile Open Benelux 2011 will be happening in Ghent, Belgium.

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


Agile Open Belgium 2010

Discuss all things Agile

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!


Agile Open: Day Two

Agile Open. Day Two.

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.

Throughput Accounting at project level

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…


Agile Open: Agile Documentation

The last session of the first day was about Agile Documentation. This wasn’t a session someone had prepared in advance. We discussed a bit about the topic. At first, there was a bit of confusion about what we were talking about. Part of the discussion was really about requirements. What information do you need to start the project or to determine the impact of new requirements upon the system. Another part was about what documents we need to write during and after the project.

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

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…