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.

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

I’m looking forward to return to Geneva to take part in the second Swiss XP Day. Last year’s event was a lot of fun.

This year, I’ll co-present “Agile Project Management in practice” with Portia Tung and I’ll help Portia run the “Coaching with the Wizard of Oz” Agile Fairytale.

La gestion de projet agile en pratique

Est-ce qu’il y a des chefs de projet dans un projet agile ? Qu’est-ce qu’ils font ? Quelle est la différence avec un Scrum Master ? Quelle est la différence entre la gestion de projet « agile » et la gestion de projet « normale » ? A travers des présentations, jeux et exercices nous vous proposons un ensemble d’outils et techniques que vous pourrez appliquer dès demain pour améliorer le déroulement et les résultats de vos projets.

Apprenez les techniques de coaching avec le magicien d’Oz

Pour pouvoir aider les autres (et soi-même) avec du coaching il faut mettre en pratique quatre activités :

• Poser les bonnes questions
• Écouter ce qui est vraiment dit
• Observer ce qui se passe vraiment
• Donner le bon feedback au bon moment

Le coaching est simple, mais pas facile. Quelque soit votre rôle dans l’équipe, ces techniques seront utiles pour améliorer chaque jour. Apprenez quelques techniques de coaching et mettez-les en pratique. Les personnages du Magicien d’Oz vous aideront sur la longue route de brique jaune vers la cité d’Émeraude.

A bientôt les amis Suisses et Français!

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…)

At XP Days London I attended an Open Space session on “Estimating Business Value”. Ironically, it was hard to hear the other people in the working group because of the noise generated by the working group next to us discussing “Agile isn’t solving our customers problems because they’re not here“. Yup, we were discussing business value with not a customer in sight or any idea on how we could involve them in the discussion.

The topic of the session was

How do we estimate the Business Value of User Stories?

We didn’t get much result from the discussion. There’s no writeup on the open space wiki. I don’ t know if the organiser of the session got anything out of the session. I didn’t.

First of all, the session never defined what “Business Value” is. That’s the topic of a later blog post.

Secondly, I don’t think you can get a good answer to that question because it’s the wrong question.

Why is this the wrong question?

Because it presupposes that we first write User Stories and then estimate their value.

If we don’t know the value of the stories, we risk writing a lot of low (or zero) value stories. And many teams do. We write lots of User Stories in the hope of discovering the high value ones. We end up with a lot of stories that then have to be prioritised, valued, estimated and managed. Portia taught me a colourful description of this result: a Vomit of User Stories.

What are the consequences of a Vomit of User Stories?

We spend a lot of time on them:

• user story telling meetings
• user story cost estimation meetings
• user story value estimation meetings (that’s the meeting where we force our product owner to put a value number on the user story)
• user story planning meetings

Just to decide what gets done in the next iteration.

If we estimate and track tasks, not stories, we need to add

• task breakdown meetings
• task estimation meetings instead of story estimation meetings

Add to that

• an iteration retrospective
• a mid-iteration review
• a show and tell meeting
• daily standup meetings

Meanwhile, there’s “backlog grooming” going on. It’s a wonder anything gets done in an iteration!

Indeed, I’ve heard many managers and developers of companies that have started with Agile complain about the many meetings. They feel that they’re not getting much done.

So, what’s the correct question then?

How do we find the User Stories that deliver the Business Values?

That presupposes a different process: one where we first define what Business Values we intend to achieve and then generate those User Stories that contribute to the Business Values.

That should be a no-brainer, right?

• We first decide what values (or benefits) we want to achieve before lauching a project or product
• Then we find and improve the business processes that deliver that value
• Then we find and improve the supporting business processes that make the value-delivering processes possible
• When the team needs user stories, we take the highest value processes and break them down into user stories at the right level of granularity for the team’s needs. The team pulls the stories, so we only generate a minimal set of user stories.

The User Stories that implement those business processes clearly contribute to the business values, otherwise we wouldn’t even have considered them.

What’s the value of an iteration?

We keep talking about value and business value, but for our customers there’s no value delivered by iterations. They see real value when the product (and that’s not just software, despite “Working software over comprehensive documentation”!) gets released into the hands of users. Iterations (more correctly: timeboxes) are a useful project management tool, no more.

What’s the business value of a story?

I don’t think it matters much.

Why do you want to know the business value of a user story?

• It’s no longer needed to eliminate zero or low value user stories, because we don’t create or consider them at all.
• Another use could be to prioritise user stories by business value in a release or timebox. If we’ve already prioritised the business values and the processes that deliver them, we need to make sure the processes are implemented completely. So, I’d schedule user stories in such a way as to finish the high value processes as soon as possible and have as few processes in progress as possible. Other considerations, like dependencies, constraints, risks and real options, will weigh much more heavily when scheduling.

Why else would you want to know the business value of a user story?

I see no need to put a Business Value number on User Stories.

In the end, the customer doesn’t care about the allocation of user stories to timeboxes. They care that the selected business values are delivered in the release.

Asking the right question

Before we can find the right User Stories, we first need to ask our customers

What are the business values, the benefits, you need to achieve with this project or product? And how will you know you got them?

So, instead of inviting your customers to XP Days, why don’t you go to them and ask some questions? Asking questions is simple, but not easy.

Do you know what values your work is going to deliver? Do you know how your work delivers those values? If not, why are you doing this project? Why are you being paid?

You’d think that asking questions is easy. Most of us have been doing it since we’re small children. Why is it that most people (me included) are so bad at it?

Nowadays, we start many of our conference sessions and training courses with an interviewing exercise. The exercise is very simple:

• Participants work in triads and rotate through the three roles
  • Interviewer asks questions
  • Interviewee answers questions
  • Observer notes what is being done and said. The observer is also the referee who checks that the other two players follow the role.
• We set a topic that is known by the interviewee and not known by the interviewer. For example, the current or previous project of the interviewee. That actually makes the game easier. It’s harder to play the game if you know the interviewee or what they’re talking about.
• During a short timebox (a few minutes), the interviewer asks questions. Only three types of questions are allowed:
  • Open questions allow the interviewee to tell their story. Questions like “What does your company do?”, “What project are you working on?” or “What does your product do?” are good opening open questions. The best open question is “Can you give me an example?”
  • Control questions let the interviewee fill in the facts of the story. Questions like “How many people work on the project?”, “How long is the project expected to run?” or “Where do you work?” allow the interviewer to get to the data behind the story.
  • Confirmation questions let the interviewer check that they understood the interviewee. “If I’ve understood correctly, <restate what you heard in your own words>. Am I right?”. If you get a “Yes” answer, you can go on to the next part of the interview. If you get a “No” answer, you can ask the logical next Open question: “Can you tell me what I missed?”

It’s a fun game. You can download the instructions and a cheat sheet from the Agile Coach site. The game is based on the “Nine Boxes” technique from Solution Selling.

It’s too hard!

The feedback from the players and our observations show one thing: this is too hard! Interviewers have trouble following the rules and observers don’t have the courage to interrupt the interviewer when they don’t follow the rules.

In those few cases where we have someone who can actually ask questions in this format, the interviewees always remark how they feel that the interviewer really understood them. Usually, the interviewee gets some new insights.

It is hard, but it’s worth it.

How not to ask questions (a non-exhaustive list)

• Closed questions push the interviewee in a corner where they can only answer Yes or No. It’s really hard to get useful information using only boolean answers. Typical conversations go like “Is it X? No. Is it Y? No. Is it Z? No!!!” If you like to fish, go to a lake.
• Leading questions (or even better, Entrapment questions) lead the interviewee to give the answer the interviewer wants to get. “When have you stopped beating your wife?” is a classic example.
• Discourses disguised as questions allow the interviewer to speech on their favourite subject. Sometimes they even add a closed question at the end. By then nobody knows what the question is about. The goal is to let the interviewer talk more than the interviewee. I don’t know why, but I associate this type of question with university professors or inhouse gurus.
• Rethorical questions don’t really expect an answer, they have a point to make. “Are you going out wearing that?”. “Well… Maybe I’d better not. What do you recommend?”

My favourite most hated type of question (and one I use and hear too often) is the Pretend Open question. The typical form is like this: “Is it X or Y (and here the interviewer remembers they should ask open questions) OR…?” You can just hear the trailing dots. The question is long, unclear and weak. Advanced users will introduce many OR options, so as to maximize their airtime.

Help me get better

If you hear me ask any question that doesn’t fit the Open/Control/Confirm format, please correct me.

So, what did you think of this blog entry? Was it useful or just a reminder of something you already do or something you can’t use or….? Are you getting annoyed yet? Oops!

And it gets harder

Another observation from the game: hearing and seeing is also very hard. When we ask the observers to tell us what they heard and saw, we ask them to only answer with “I saw…” or “I heard…”. Most observers answer with “I think…” or “I feel…”.

When we teach people to interview and observe they “rediscover the lessons they learned as children but have since forgotten“. Maybe we should hire children as business analysts and consultants. For them all of this is natural.

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.

It’s time to start planning for the fall and winter conference season. As an organiser, the 7th XP Days Benelux is top of my list.

We’re finalising what looks like a great program with several sessions I want to go to in each time slot. With five tracks covering all things agile, there should be ample choice for you and our conference personas too.

We can’t show you the program yet, but you can register for the conference. Who would register for a conference without knowing what’s on the program? Lots of people it seems, as registrations are coming in steadily.

Now, that’s T-R-U-S-T, one of the essential Agile Values.

Bram goes to every XP Days Benelux

Innovation and constraints

How did we come up with the idea of registering before announcing the program? By accident.

• Participant: “Can I get a conference ticket now? I’ll be abroad the next few weeks and I want to be sure to get in.”
• Organisers: “But, don’t you want to see the program first, before deciding?”
• Participant: “No, I’ve been to last year’s conference. I trust you’ll have a great program this year too.”

There was nothing holding us back from selling tickets before announcing the program. We only had this self-imposed constraint: “participants want to see the program before deciding to participate”. It turns out that this isn’t a real constraint after all. Part of innovation is letting go of those self-imposed constraints. Another part is dealing with real constraints.

How many of those self-imposed constraints do you have in your work or your life? How many times have you said “I didn’t know we could do that!” ? How often do you ask yourself “What would happen if we tried this?”

That’s why I like organising XP Days Benelux: there are always people coming up with crazy ideas, trying something new and improving it. Sometimes it works, sometimes it doesn’t. We always try to learn. We always try to question. We don’t always succeed, but at least we try.

Try this at home

Note how often you hear this:

• That’ll never work!
• They won’t let us do that!
• That will never happen here!
• Yes, but…
• There’s no budget for that!
• That’s just silly!
• or any other Idea Killer

Now, take one of these instances and instead of  shooting the idea down, start looking at the hidden self-imposed constraints:

• It’ll never work? In what circumstances would it work?
• They won’t let us do that? Why? Have we asked?
• That will never happen here! Where would it work? What would it take to transform here into a place where it works?
• Yes, but…? Yes, and…!
• There’s no budget for that! What small part of this could we do for free? How much value could we create? Could we use that value to fund the next small step?
• That’s just silly! Less silly than what we do today

It just takes a bit of courage. Try something, one small step. Collaborate with people who can help you. Get regular feedback to improve. Instead of “doing agile” (or worse, trying to get others to “do agile”), be agile.

You are an innovator. You are creative. It’s as simple as that.

Come to XP Days Benelux to see what crazy stuff we’ve cooked up this year. If some people get their way, it might involve dancing, martial arts, art and philantropy. Now, that’s just plain silly! Don’t say I didn’t warn you!

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!