Mechelen, December 1st – 2nd 2011

XP Day Benelux is an international conference about Agile methods, intended for people from all walks of life who are involved with IT. It provides a good opportunity for exchanging ideas and sharing experiences and is suited for both experienced participants and beginners in Agile methods. The focus of this conference is on practical knowledge, real-world experience, and active participation of everyone.

XP Days Benelux 2011 will have something for everyone. Sessions for people who are new to Agile, sessions for experienced people, a good mix of technical, experience, management and process sessions. We’ll have sessions on Agile in real life, stories of success and horror, hands on workshops, and sessions that will completely surprise you!

You can be a contributor too

We’re looking for enthusiastic people who want to lead these sessions. People who work in any role, business or form. People who are willing to share, and are prepared to learn. Reflective practitioners who are not only interested in quality work but also want to know why things work as they do.

Are you new to presenting? Do you have a nice idea, but you don’t know how to shape it into a session? Don’t worry, we will offer lots of ways to help you:

• We have coaches who can help you create your session.
• Through our session proposal system you will get feedback that will help you shape your session
• We provide opportunities before the conference to try out your session.
• We have a set of personas to give you some idea of the type of participants you’ll meet at XP Days.

Have you presented sessions before? The extensive feedback will give you an opportunity to improve your session further. And you can use your experience to help other presenters to improve their session.

How to propose a session for XP Days

Becoming an XP Days presenter is simple (but not easy):

1. Submit a session idea (until July 9th, 2011)
2. You’ll receive a login to our session improvement tool
3. You complete your proposal and improve it with the feedback you receive (until August 27th, 2011)
4. You give feedback on other proposals to help their presenters to create the best proposal they can
5. Early September, the program committee selects the sessions for the program based on the following criteria:
   • Quality of the session
   • A balance of session subjects and formats
   • Participation of the presenter in the improvement process
   • Votes from everybody who proposed a session

Important dates

• Now to July 9th, 2011: submit session proposals
• Now to August 27th, 2011: improve session proposals
• September 12th, program committee meeting
• September 19th, program decided

Propose a session now to get as much time as possible to get feedback and improve your session.

See you at the conference!

Here are the slides for the “Agreeing on Business Value” session we ran at Mini XP Days Benelux 2011 and will run again at the SPA conference in June.

The exercise uses a case study that’s not published, so you can’t peek and prepare for the session

Portia Tung and I ran the “Agreeing on Business Value” session at the Mini XP Days Benelux 2011 conference. In the workshop participants have to create a “Business Value Model” for a case we provided. The Business Value Model shows the most important goals and measures of the company and the relationships between goals. We often run this workshop to let a team come up with a common definition of “Business Value”. As a result of the workshop, everybody’s has a clear and common understanding of the value the project or product is going to deliver.

We asked the teams to add what they learned at the workshop on the posters. Here’s a gallery of the outputs of different groups. Click on the images to get a larger picture.

Team 1

In the model different types of goals have different colors: financial goals are blue, organisation goals are green and people goals are yellow. At the top are the “lagging measures” (those that can only be measure late). At the bottom are the “leading measures” (that can be measured early) that will be used to predict the achievement of the desired lagging goals. Arrows indicate that one goal has an effect on another. You’ll see that most things are interrelated. The good news is that achieving one goal can help achieve other goals in reinforcing loops. The bad news is that you may have to achieve many subgoals to achieve your desired goals.

This team identified the following learnings:

• Makes a complex project more clear
• Business alignment. Today business cases are made individually
• Helps to give an overview of goals for all stakeholders
• Make decisions at goal level, not at feature level
• (You can use this for) portfolio management!
• Thinking about measures

Team 2

Here we se a simpler model, but still representing the financial, organisational and people goals with their relationships. Everything leads to “Make Profit”

What they learned:

• When we talk about business value, we need to think about how to measure leading and lagging indicators
• Adding the relationships generated new insights
• Plan-Do-Check-Act
• Eliminate “business value” that doesn’t really add value

Team 3

Another very clear model with positive (+) and negative (-) effects between different goals. In the end, it all results in “Cost Cutting”

What they learned:

• It starts with a vision
• You involve everybody
• To build a model, iterate over the following steps until satisfied:
  • Identify goals
  • Define Lagging and Leading measurements
  • Identify relationships (“Diagram of Effects”)

Team 4

This model has exactly one leading and one lagging indicator per area. Together, the goals result in profit.

This team created a diagram of what they learned:

• Value is not just money
• Value must be measurable
• We have leading (“early”) and lagging (“late”) measures
• We need to identify the relationships between the measures

Team 5

This team considered more lagging (yellow) and leading (pink) goals. Many of the goals have more than one possible measurement. If you have multiple ways to measure a goal you can choose the cheapest measure to collect or find some data that’s already being collected.

The important points for this team:

• Identify
• Categorise
• Quantify
• Relationships

What the presenters learned

• Everybody got the same case, but there are differences in the models. There is no “right model”, the team has to find one that’s useful. Over the lifetime of a product or project the business value model will probably change, as different goals change in importance
• The case is not too simple, and there’s lots of information, just like a real project. Despite that complexity teams of six “strangers” came to a clear agreement on the goals of a project within 90 minutes. How long does it take in your project to come to agreement on goals and priorities. If your projects are like mine, probably the whole duration of the project
• Making our definition of business value clear, finding ways to measure and thinking about effects and relationships helps to come up with new insights
• Participants don’t ask many questions. We were available the whole time to answer questions about the technique or the case, but despite having real live “customers” in the room, participants concentrated on the written materials
• We started by describing and drawing the company vision on the whiteboard. Most teams quickly lost sight of the vision. Once they “rediscovered” the vision, they found that it answered some questions about value and priority. It would be good to remind people of the vision before every turn. Maybe we could do this in our work too? Why not start each project meeting with a reminder of the vision?

If you want to know more, head on over to the agilecoach.net site where you’ll find more about Business Value Modeling and some other useful tools.

If you applied any of these techniques, let us know how it went.

In his post he describes the following main points:

• Business Value is multi-dimensional and not always easy to express. The key lies in the measurability of things.
• The “Business Value Model” is a technique to set the context of the “big” why and communicate this across the organization (small or big).
• It is built around the concepts we are mostly familiar with (and borrowed from other techniques).
• The “Systems Thinking” part comes into play to discover relationships between goals, capabilities, stakeholders and measurements and risks. When you turn a knob here, something will happen on the other end… and vice versa.
• A business value model is not carved in stone. You must always evaluate if what is described (or better drawn) in the model actually reflects reality.
• This visualization is important for communication. Doing the value exercise can be an eye-opener for the people in the project and/or organization.
• The “Business Value Model” should be the origin for all user stories.

Yes. That’s it. Couldn’t have said it better myself

You can see the outputs of the workshop in a previous blog entry. Read more about it on the AgileCoach site.

Hope to see you at the conference!

See you on April 1st in Mechelen.

In the Business Value Modelling session at the XP users group 6 teams created a Business Value Model for a mobile phone company struggling to keep customers and regulators happy while reducing call center costs. In the final step, each team had to create a poster that they could use to guide their decisions and to explain the reason behind the project.

As you can see from the session feedback everybody wanted to know if they had built the ‘right’ model. Let’s take a stroll through the business value model gallery and see how the teams did. Click on the images to enlarge.

Team 1

This team spent a lot of time discussing and didn’t have much time actually making the diagram. The large yellow Post-its contain the major goals. Small green Post-its are measures of the goal. Are small blue Post-its leading indicators? It’s not very clear. Only two goals seem to be worked out. There are four more large yellow Post-its to the side. What’s their meaning?

To make it perfect:

• Add a legend to the diagram
• Fully work out at least one goal
• A Business Value Model doesn’t have to be “perfect”. Make something quickly and iterate.

Team 2

This team tells a story: we have unhappy customers and we have lots of measures that make that visible (left). We have several measures (both lagging at the top and leading at the bottom) that we can use to measure and drive improvement. Then we have several things on the right that we must comply with, either constraints or non-negotiable goals. All of this should lead to happy people (customers, employees, regulators).

To make it perfect:

• The diagram focuses heavily on the customer. Where are the company, the regulators and the project sponsor? How could you represent their views?
• Does the ordering of complaints have any meaning? If you could do only one thing, where would you focus?

Team 3

This is a very clear and near diagram with a business-like 4 quadrant format. Each of the quadrants represents the view of one stakeholder. I like the big, clear goals on the yellow Post-its. Each stakeholder has both constraints and measurements/tests.

To make it perfect:

• Explain the meaning of the arrows. Am I correct in interpreting it as customers and regulators have goals which drive internal goals of the Operations Manager and IT?
• The IT measurement “daily reporting” isn’t very actionable. What’s in the report?
• The Operations manager measurement “Send confirmation” message sounds more like an action or capability than an measure or test. How can you test that confirmations have been sent? Why will that reduce costs?

Team 4

This team used a concentric circles model: on the outer circle we have the viewpoints of the stakeholders. The pink Post-Its represent a stakeholder goal; the attached blue Post-its are the measures for the goal. I’m not clear what the yellow Post-Its in the center mean. This team added a new goal that wasn’t in the original assignment: “Increase Antenna Coverage”. Apparently lots of people call in to say they can’t call

To make it perfect:

• Show some relationships between the different items so that it clear what belongs where. For example who wants to “Bill correctly”? The customer or the organisation? Who wants to port numbers quickly? The customer or the regulator?
• Explain the meaning of the yellow Post-its in the center
• Instead of the “Atern” Post-its (some leftovers from the Agile Business Conference), draw the stakeholders

Team 5

Another diagram that uses the concentric circles (or maybe a Mandala) idea. At the outside (the small yellow Post-Its) we see the stakeholders. Big bold yellow Post-its show the goals with attached measures. The Blue arrows indicate that achieving some goals helps achieve other goals. Big red Post-its indicate constraints.

To make it perfect:

• Make the stakeholders stand out more by drawing them or having larger Post-Its. Everything we do starts with the stakeholder.
• Add a small legend: for example what are the green lines?
• You don’t have to reuse the Post-its. Why not just redraw the goals and measures neatly?

Team 6

The last team had a completely drawn business value model. The central metaphor of the scales can be very powerful: by working on one side we can influence the other. Here: by increasing usability of the service, we reduce the cost of the service (or “Quality is free“). On the right, we want to reduce the number of people who call in (presumably without reducing the number of customers?). This is done, on the left, by going from a situation with few computers and lots of employees to one where computers have taken over the work. Or, as the team put it succinctly: “the solution is to replace people by computers”.

To make it perfect:

• we have one measure for cost (“# of incoming calls” on the right). How would you measure usability on the left?
• The image on the left (“replace employees by computers”) focuses on the ‘solution’. Can you represent how stakeholders will benefit?
• Replacing employees by computers is (for most people) not a very rousing goal. Is this the first message you want to get across when you explain your project? How do you think those employees feel? You’ll probably have to talk to them to implement the project.

At the end of the tour

What have we learned? A Business Value Model serves several purposes:

• To make it clear why we do the project: which stakeholder goals do we want to achieve?
• To prioritise: which goals are more important than others?
• To have project/product acceptance criteria: how will we know we achieved the goals?
• To show how we will steer the project: what measures/subgoals can we use to go in the right direction?
• To understand what is out of our control: which constraints should we abide by?
• To create a shared model of the important aspects of value and how these aspects affect each other: what is our hypothesis of how we will generate value?

What I look for in a model is:

• It’s clear: legible writing, a legend, appropriate use of colour and size
• It tells a story: “we focus first on <this> and then on <that>”, “if we do <this> it’ll lead to <that>”
• It’s motivating: the goals indicate that we’re making life and work better for people, there’s more than making money
• It’s useful: it helps me ask the right questions like “how is this feature going to help us achieve our goals?”;  helps me to make the right decisions like  “we’ll focus on area A first, because that will help us achieve our primary goal”
• It’s temporary: this is the best model of our system for now; as soon as we learn, we’ll update our model
• It’s shared: the whole team contributes to making and changing the model.

When is the model “done”? Ask yourself:

• Do I want to have this displayed prominently in the team room?
• Do I want to use this as a decision aid?
• Do I want to use this to explain the project to my most important customer or user; to the CFO; to the CEO; to a new team member?
• Do I know how we can test and invalidate the model?
• Do I want to keep this up to date?

See you at the Business Value Modelling session at XP Days Benelux. I’m looking forward to seeing the models that come out of that session.

Yesterday, I did a tryout of the “Business Value by Systems Thinking” session for XP Days Benelux.

A “Business Value Model” is one of many models our teams build to get a better understanding of the problems we need to solve. Based on the goals of our stakeholders, it shows

• what “value drivers” (or dimensions like “income”, “customer satisfaction” or “employee retention”) are part of our shared definition of Business Value.
• how we can measure that we get closer to (and finally achieve) our goals during and after the project
• what constraints limit us in our search for solutions
• how all of these things are related in a systemic model. For example, what do you think happens with employee retention if customer satisfaction goes down? What effect, if any, does shorter employee retention have on customer satisfaction? These and other causal loops may point the way to “leverage points” where we get most effect with the least amount of effort.

By building the Business Value Model we create a shared vision and align the team members. By relating all our work to the value we add, we are more motivated.

Feedback

As usual, there was much too much content. Thanks to the feedback of the participants, there will be more time for exercises and explanation, we’ll go more in depth into the real subject of the session and there wil be more feedback for participants on their model.

You can download the  tryout retrospective feedback and see what the participants thought about it. I’ll publish the output of the session in the next blog entry.

Many thanks to the participants for playing along and giving useful feedback. Thanks to Cap Gemini for hosting the event.

Answering some puzzles

• How do you prioritise based on the Business Value Model? You start with the lagging (final) goal that you want to achieve/improve first. What would it take to “achieve the goal” or “improve enough” (first define what “enough” is)? How little can we do? Do we need to mitigate some risks? Do we have enough value to release? If yes, start implementing. If no, which other goal do we need to tackle too?
• Does “Business” Value mean only financial measures? No, we also include other measures like “customer satisfaction”, “employee retention” or “happiness” (we just built a Business Value Model with “Number of people who happily use our product to do their job” as the #1 measurement). Some of those “measures” can’t really be expressed as a number, you can only see if they improve or worsen. On the other hand, Don Reinertsen recommends “if you want to be able to make (quick) tradeoffs, you should express each measure in money” in his book “Flow”.
• Is our model right? What is the perfect model? What should the final model look like? I really can’t answer that question. Your model is “right” (or: useful) if it helps you to make good decisions, if it helps you to explain the reason(s) behind your project, if it allows everyone on the team to make decisions. In the end, you test your model(s) by building something according and seeing if your hypothesis was correct. And even if it isn’t, you’ve learned something. What we’re doing here is using the scientific method: we build a testable hypothesis, we perform the test and we improve our hypothesis based on the results.

XP Day session tryout: Agreeing on Business Value with Systems Thinking

Cap Gemini will host the next Agile/XP Belgium usergroup meeting. This session is a tryout for XP Days Benelux.

We talk a lot about “maximizing business value”. We ask business people and product managers to prioritise by estimating the business value of user stories. But what exactly do we mean by business value?

Over the past few years we’ve worked with many teams to define their “Business Value Model”, a clear definition of the value a project will bring to the organisation. The exercise hasn’t always been easy but it has always brought significant benefits:

• Measurable business value in units that impact the organization (such as revenue €€€, customer satisfaction, staff retention)
• Everybody involved was more motivated because there was a clear reason for the project and they finally understood what it was
• The whole team was aligned around one vision because we had clear criteria to define success
• We came up with more innovative solutions because everybody on the team, not only “the business” or “product managers/owners” could take product-related decisions based on the model
• We could deliver a lot faster than anybody expected because the Business Value Model allowed us to easily distinguish between value-adding and non-value-adding features
• We spent a lot less time writing and prioritising user stories because we were able to derive the user stories from the value definitions
• The Business Value Model guided us to explore new product ideas: the business value model was a hypothesis that we could test and refine each time we released or performed user testing.

In this interactive tutorial you’ll apply some Systems Thinking techniques, such as the Diagram of Effects and Intermediate Objectives Map) to define the business value model of an example project. We’ll show you the techniques we used and discuss how you can apply those techniques in you context so that you’ll be ready to start building a business value model with your team.

Agenda:

• 18:00 – 19:00 – Welcome with snacks and drinks
• 19:00 – 21:00 – Session

Address: Bessenveldstraat 19, B-1831 Diegem, Belgium

Register here for this free event

XP Days Benelux 2010 will be held in Kapellerput, Heeze (near Eindhoven), The Netherlands on 25-26 November

The program for XP Days Benelux has been published. This year we have more sessions than ever before: 41 sessions over 2 days. As always, it’s going to be hard to select only one session from the five parallel tracks.

I’ll be presenting “Agreeing on Business Value with Systems Thinking” with Portia Tung. I’ll be doing a tryout of this presentation, which has been updated after presenting it at Agile 2010. Come to the Agile/XP Belgium user group meeting on Tuesday 26th of October.

If you want to see a tryout of the “Database Change Management” session, join us in the Agile/XP Belgium user group meeting on Tuesday 5th of October.

IHC hosts the next Agile/XP Belgium usergroup meeting. There will be two sessions in parallel

Session 1: “A journey into Database Change Management” by Jochen Jonckheere and Pascal Mestdach. This is a tryout for XP Days Benelux.

Abstract:

We will bring you the story of our journey into database change management. We share our experiences with concrete examples/common situations and explain the different parts of Database Change Management along the way. During our journey we encountered several problems. We let participants reflect on how they would solve these problems, before we show the solution we picked. This is an interactive technical session where you will see 2 developers working together, writing some small sql scripts, breaking and fixing automated builds and even in the end a tool for handling Database Change Management in an automated way in the .NET environment.

Session 2: To be decided

Agenda:

• 18:00 – 19:00 – Welcome with snacks and drinks
• 19:00 – 21:00 – Parallel Sessions

Register here for this free meeting.

Address: Legeweg 157 E/02, 8020 Oostkamp, Belgium

Couldn’t come to XP Days Benelux 2009? You missed a lot of great sessions.

Even if you did go to XP Days Benelux 2009, you missed several great sessions, because the program committee stupidly scheduled great sessions at the same time in each of the five parallel tracks.

Or maybe you want to send your colleagues to those great sessions you attended.

Well now you can, because 8 of your favourite sessions are being presented again at Mini XP Day Benelux on April 26th, 2010.

What’s in it for me?

You could learn more about

• finding the right question to ask to intervene on an individual or a team with Pierluigi Pugliese
• writing executable acceptance tests for real-world applications using Fitnesse with Pascal Mestdach & Michel Grootjans
• creating and improving an Agile office with Ralph van Roosmalen
• managing your backlog with Peter Janssens
• becoming a peer-coach and finding new insights for old problems with Portia Tung and the cast of The Wizard of Oz
• organizing and refactoring code with Matteo Vaccari & Antonio Carpentieri
• using Lean and Kanban techniques to increase teamwork and delivery speed with Machiel Groeneveld
• becoming a more effective Product Owner with Serge Beaumont

Mini XP Days Benelux remains the place to exchange ideas and share experiences about Agile in an open and relaxed atmosphere.

Don’t wait too long

Register quickly because the event is limited to 60 participants and the event usually sells out.

See you on April 26th in Kappelerput, just to the south of Eindhoven, near the Dutch-Belgian border (which might have an effect on the availability of beers…)

Last week we organised XP Days Benelux and I’ve just about recovered from it. It was fun, as usual, and participants seemed generally happy with the event. You can see for yourself in the reports, participant retrospective and session feedback.

There are also a lot of things which could be better. The organisers are already busy setting up a retrospective and next year’s events.

A full report will follow later.

If you’ve written about XP Days Benelux, let us know. We gather all the reports on the conference website.

If you have any feedback or ideas for improvement, let us know. Even better, join the organising committee and realise your ideas.

Organising a conference is fun even if you’ve never done it before. There are enough experienced organisers to pair with. It does take some time and effort, so make sure that you’ll be able to invest in the conference. In return, you get the chance to take part in a non-IT Agile project.

When presenters propose sessions for XP Days Benelux, we always recommend they try out their session, as many times as possible. We should all know the power of iteration and feedback. You need some time to get it right. If you’re slow like me, you might need years to get it right.

The first tryout of the “Solve Conflicts without Compromise” session was run as a “Birds of a Feather” session several years ago at the SPA conference. The session (and the technique) worked, but only barely. Then, two breakthroughs happened at the same time:

• I attended Christoph Steindl and Christian Federspiel‘s Conflict Resolution session at Agile 2008 in Toronto
• I read Bill Dettmer’s “The Logical Thinking Process“

Suddenly, the technique became a lot clearer. Bill Dettmer’s explanation is very clear and practical; the session at Agile 2008 showed that it worked and could be fun.

Solve Conflicts without Compromise

So, after a few more iterations, an updated session was created. It’s now been run twice:

• At  Agile Tour Besançon, in French. The participants gave a lot of useful feedback at the retrospective.
• At the Scandinavian Agile open space, in English. The pictures show the three groups analysing a conflict for their “customers”. There was no time for a retrospective, because the conference was closing. I hope the three clients will blog or email me about their experience.

The next two runs will be at the Belgium Agile/XP User Group meeting on November 5th 2009 and at the XP Days Benelux conference on November 24th.

So, what are the 7 steps?

1. Create a blank Conflict Resolution Diagram (CRD) like in the image below. 5 boxes connected with arrows. Easy.
2. Articulate the conflict. State the problem in one of two forms, both impossible choices between conflicting prerequisites:
   • One chain of reasoning says “DO THIS”; another chain of reasoning says “DON’T DO THIS”. Now I have to choose: DO THIS OR DON’T DO THIS? I can’t have both.
   • I need two things, A and B, but they’re mutually exclusive. Now I have to choose: HAVE A OR HAVE B? I can’t have both.
3. Determine the goal and requirements on each side? Why do we need those two conflicting things? Because of two requirements. Why do we need those two requirements? Because we need them to reach a common goal.
4. Evaluate the reasoning. Throughout the whole exercise we must ensure we maintain clarity: is each step in the reasoning crystal clear and well-understood by everyone? Is the reasoning clear?
5. Develop underlying assumptions. If the CRD says “To achieve X we need Y”, ask “Why do we need Y to achieve X?”. All the answers are the underlying assumptions of the reasoning. Use “extreme wording” to make the assumptions stand out and almost beg to be invalidated. For example: “Why do we need to introduce Test Driven Development to achieve better quality?” Because…
   1. TDD is the only way to improve quality
   2. TDD is the most fun way to develop software
   3. TDD catches all errors
6. Evaluate the assumptions. Which assumptions are valid? Which assumptions are invalid? Which assumptions could be challenged. If there are no valid assumptions behind a step in the reasoning, the reasoning is invalid. At this point, the whole conflict may have “evaporated”.
7. Hard: Create injections. This is the creative bit where we find ideas to invalidate those assumptions that hold us back from creating a win-win situation, one where we achieve our goal in a way that satisfies everyone involved.

Why is this difficult?

When I see the participants in action, there are some difficulties that appear every time:

• It’s hard to maintain the consultant’s stance and only ask questions. That’s why we have strict rules about what the consultants can do: they can only ask a limited set of questions.
• We want to jump to the solution immediately without taking the time to understand the real problem. That’s why the session doesn’t allow talking about solutions, only about problems.
• We censor our assumptions. Instead of brainstorming all our assumptions, we only talk about those that seem reasonable. That’s why there’s a lot of pressure in the session: you have to come up with at least 25 assumptions in 5 minutes. That’s just not possible if you think about the assumptions.
• The most interesting assumptions are those that we no longer think about, the things that are “common sense”. That’s why we have people external to the problem questioning the client and why we bring in some “fresh blood” with a fresh perspective halfway through the session.
• It hurts when we really think about a problem. It’s easier to just settle for a compromise. That’s why we can’t accept any solution where one of the involved parties is not completely satisfied with the outcome.

What’s in it for me?

• The CRD provides a structured method to investigate a difficult conflict and channel our creativity.
• You don’t have to settle for compromise and mediocrity. You can get what you really need.
• It’s a lot easier to bring about changes if everyone affected benefits. As Machiavelli noted: “You will only get lukewarm support from those who will benefit from the change and strong resistance from those who stand to lose”. What if there were no losers?
• Your projects can deliver more business value per cost if you can find the breakthrough ideas that make those painful tradeoffs (or more correctly: horse trading) between stakeholder goals unnecessary?
• You can get more sales if your competitors offer “EITHER/OR” solutions and you can offer “AND” solutions. But first the customer has to regain hope that a solution is possible. Going through a CRD exercise with a customer and offering to invalidate all the assumptions that cause their conflict is an offer they can’t refuse.

What do I need?

• A bit of time. Most participants got several ideas to resolve their conflict within the 90 minutes of the session.
• Some simple materials: pen, paper and plenty of Post-Its
• The willingness to think hard
• The openness to share all assumptions
• The courage to challenge every assumption, even those that are “holy” or common sense. Especially those.

It’s simple, but not easy. The question is: do you want an easy life or a meaningful life? That’s the choice you have to make.

Oh! “Easy OR meaningful”? That sounds like a conflict! Why can’t I have both?

How would you evaporate this conflict?

Bring a conflict to the session and come out of the session with several ideas to turn this conflict into a win-win situation. If you don’t have any conflicts, you can learn how to help others solve their conflicts as a Systems Thinking consultant.

Come and learn how we’ve applied the Toyota Way management principles to introduce Lean and Agile methods in such a way that the companies can sustain the change.

The first version of the XP Days Benelux 2009 program has just been published. It looks great, with a good mix of subjects, formats and aimed at participants with different levels of experience.

Over the next few days we’ll make this program even stronger by adding a few more sessions. The only problem is that we still have more strong session proposals than available slots. More difficult choices ahead…

Register now to benefit from the early registration discount.

I enjoyed Toronto very much last year, when attending Agile 2008. It has all the attributes of a big, vibrant city but also quiet parks and lakeside where it’s easy to relax.

The most striking thing about the city is its people: they seem very relaxed and easy going, they take the time to enjoy life, they serve Belgian beer and they stop for red traffic lights. Toronto’s inhabitants come from all over the world. The city is one big melting pot where people from all sortsd of backgrounds live and work together. Of course, I’ve only seen the city in summer. I wonder what the city looks like in winter.

Agile in Toronto

This fall, on October 20th, the Toronto Agile community organises their first Agile Tour Toronto. An energetic group of organisers ensures that this will be a day of fun, learning and meeting other people interested in everything Agile. When Gino Marckx is involved you can be sure that it willl look good, be well tought-out and be enjoyable. Gino is also one of the organisers of XP Days Benelux. He’s clearly applying the lessons we learned organising the XP Days. It’s great to see ideas spread. I’m looking forward to the Agile Tour Toronto retrospective results, so that we can learn more.

Go to Toronto

I won’t be able to be there, unfortunately. But you can! Why not send in a proposal for a session? The deadline is September 10th, but if you send in your ideas now you will benefit from feedback to improve your proposal.

If your company wants to connect with the local Agile community, why not sponsor the event? You’ll reach the smartest IT people in the area.

Have fun in Toronto!

The next XP Days Benelux will take place on 23 and 24 November, in Mechelen, Belgium. As usual, this is a great opportunity for everybody’s who’s interested in Agile methods to share information and learn from each other.

Submit a proposal

Presenting a session is a great way to learn. Why don’t you submit a session proposal for XP Days Benelux?

• Do you work in interesting circumstances? If not, what are you doing there?
• Did you learn some new useful tool, technology or method? If not, you should definitely come to XP Days!
• Did you experience some failures? If not, are you taking enough risks? Are you still learning?
• Did you work together with some new and interesting people? If not, you should definitely come to XP Days because that’s filled with interesting people.

Even if you’ve never created and presented a session before, submit a proposal for XP Days. We practice the agile values, so there’s plenty of collaboration, communication and feedback to help you refine your session. It just requires a bit of courage. Or you could ask for a session on a certain subject. That might give someone the idea to create a session for you.

What are you waiting for?

I just submitted a proposal about solving conflicts without compromise together with Jef Cumps.

Did I mention that up to two presenters per session get a free pass to both days of the conference?

See you at the conference!

• Beating the traffic jams to arrive first at the conference center.
• The helpful staff at Elewijt Center going beyond the call of duty. E.g. the night watchman doubled as barman to offer us coffee and hot chocolate before the bar staff arrived.
• The organisers quickly self-organised and divided the work before and at the conference.
• Preparing the Business Value Game just-in-time.
• Organising the new version of the Business Value Game with Portia and Vera. We’ll publish this new version soon and explain the ideas in the closing retrospective more.
• Talking with participants between sessions and after the conference.
• Plenty of useful feedback about the conference and the sessions.
• The retrospective dinner in Mechelen with the organisers.
• The conference goodies organised by Vera and the traditional Belgian presenter gifts of Carolus beer and chocolate.

What Went Wrong

• We started the conference late because many participants were stuck in traffic. Throughout the day, sessions started late and/or overran so that there was less time for breaks, lunch and some sessions.
• Not enough time to talk to everybody during and (especially) after the conference.

Puzzles

• Why so few participants from The Netherlands?
• Many sessions got “Needs more time” as feedback. As these sessions were re-run, we’d expect that presenters would know how much material would fit. Or is this a case of “second-system syndrome“?

Lessons Re-Learnt

• Agile, communication, collaboration, feedback and trust work when you need to organise something like a conference.
• Interest in Agile methods remains high.
• Participants report that Agile methods have improved how they work. At the least, they make issues a lot more visible. The difficult bit is tackling those issues, especially when they touch upon “sacred cows” like how the company is organised, how people  are rewarded, how to collaborate over departments, local goals…

What I liked

• Running the conference as a non-residential conference in the heart of London. Staying in a hotel literally around the corner. Morning running along the Thames.
• Interactive sessions like “Pitching Agile” and “Pairing: Beyond Programming” which challenge us to put our ideas to the test. Both sessions gave good opportunities to work in teams and reflect on what we value. And, of course, lots of Post-its were used to brainstorm, plan and explain
• Meeting old and new acquaintances inside and outside of the conference.
• Running the Business Value Game including a workshop with Vera and Portia. The game was designed to help our customers think about how they prioritise the project. The game doesn’t give answers, it raises questions. More about the workshop and its results later.
• Preparing and running a tryout of “The First Five Steps to Become Really agile“. A big thank you for the 7 intrepid players who gave us plenty of feedback to improve the session.
• The conference closing with concrete actions to follow up on the conference. I’ll have to write about cost and value estimation and about incremental funding and real options.

To make it perfect, I would

• Like to have a bit more room in the sessions and during lunches and breaks. The size of the venue was ok for the number of participants, but only just.
• Put some shorter sessions into the program. Two sessions a day (+ a keynote or BoF) doesn’t give much variety.
• Let presenters and organisers work together to improve their proposals collaboratively, like we do it for XP Days Benelux. The quality of the sessions and proposals improve a lot, even those from experienced presenters.
• Give session (and BoF?) presenters some time to pitch their session to help us to select the session with the most (business) value.
• Improve the Business Value Game presentation, so that the game is clearer from the start.
• Ask more concrete questions, set more detailed goals for the follow up workshop.

Vera, Portia, Laurent and I will improve the Business Value Game with the feedback from the participants. Next games: Mini XP Day Benelux (in English) XP Days France (in French).