XP Days Benelux 2009 – Call for Sessions

XP Days Benelux 2009

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!


Heijunka – Humane work

The Tortoise and the Hare race

Operational Excellence AND Customer Intimacy, but not at once

In the previous blog entry, we saw how one company resolved the conflict between operational excellence and customer intimacy. They found a way to have both. But we didn’t implement both at the same time.

We first went for Operational Excellence. First we standardised, made things reliable, made work repeatable, not only in production but also in IT. The existing product definitions were inconsistent and complex. This made our code complex because we had to treat every product as a special case. Over a period of about one year all the product definitions and the code were refactored to new standardised forms. All of this happened while the system was in production and new features were released every two months. We got very good at refactoring and migrating without disrupting because we did it so often, in small steps.

A similar ‘refactoring’ happened on the production floor. Product line by product line was tackled: work cells clearly labeled, clear flow lines from input to output established, work in process limited… When I first went to see the production floor I nearly got lost between the piles of work in process and it was hard to see what was going on. After the changes, the area looked a lot more spacious and it was clear at a glance what was going on.

Once we had the production and development system under control, we started to think about customisation and getting more intimate with our customers.

Effectiveness AND Alignment, but not at once

This reminded of Alan Kelly’s blog entry about the “Alignment Trap“. In summary: we want our IT organisations to be effective (do things right) and aligned with business objectives (do the right things). Unfortunately, most organisations do neither.

If we want an organisation that does the right things and does them right, what strategy should we follow? Based on a study, Alan conjectures that it’s best to focus on effectiveness first, alignment second. First learn to do things right, then do the right things.

Managed and Agile, but not at once

I encounter a similar situation in many coaching and consulting engagements. Organisations want IT teams that are reliable, predictable and can be trusted to deliver as promised. And they also want them to be agile, deliver faster and respond to change. Lean and Agile can get you there.

What’s the first step? Usually, we need to bring things under control, clear away the clutter, reduce chaos, limit task switching, limit work in process and make things visible. This often involves “anti-agile” or “anti-lean” measures such as batching support, analysis and design work to avoid task switching and installing strict change management and issue prioritising to keep focus. I always get lots of complaints and get accused of “not being agile” from people who are used to the chaos and suddenly find that the team no longer asks “How High?” when they yell “JUMP!” Those who stop jumping find that they get a lot more done and that the results are better. They are less stressed.

Once we have the process under control, we can start improving the flow.We know how to do things, we can start to go a bit faster, in smaller steps; we can disrupt the stability to improve a bit. And then we find a new stability and so on.


Heijunka is one of the often forgotten Toyota Way principles. It means “levelling the load”, working at a steady, regular, sustained and sustainable pace. It means planning the work so that there’s a good balance between flow and the load on people and machines.

Large companies who impose just-in-time deliveries to their suppliers without levelling their orders abuse their suppliers. Teams who randomly request clarifications for stories burn out their Product Owner. Teams who push out releases faster than their customers and users can accept them throw away value.

Heijunka means making and keeping work humane.

Which small step can you take to make your work more humane?


Nemawashi – Decisions by consensus without compromise

Decisions by consensus


One of the Toyota Way principles is « Nemawashi », take decisions by consensus.

Building consensus is a slow process, but it’s necessary to get everybody on board before taking a decision. Otherwise, the implementation will be delayed and (unconsciously) sabotaged by those who didn’t agree or weren’t involved.

It’s not just about building support for your ideas. The consensus-building process solicits ideas and review from everyone involved so that the final idea is usually a lot stronger than the original.

But there’s one big misunderstanding about consensus.

Consensus doesn’t require Compromise

It’s tempting to dilute our idea to reach consensus, ensure that everyone gets a bit of what they want, so that they’ll agree to go along.

It doesn’t have to be this way. In “Extreme Toyota” the authors show how Toyota embraces conflicts and doesn’t settle for compromises. They identify six contradictions that are central to Toyota’s way of working:

  • Moving gradually and taking big leaps
  • Cultivating frugality while spending huge sums
  • Operating efficiently as well as redundantly
  • Cultivating stability and a paranoid mindset
  • Respecting bureaucratic hierarchy and allowing freedom to dissent
  • Maintaining simplified and complex communication

“This AND that” sounds better than “This OVER that”… I want to have my cake and eat it too 😉

Enter the business consultants

A few years ago I worked on a project that automated the whole value stream of a business unit. The main challenge was that the different departments had conflicting needs. No surprise there.

One of the conflicts was between the production department that did the work on customer demand and the sales department that sold contracts for doing the work to the customer . The production department needed standardised products with little variation so that they could work efficiently, predictably and hit their Service Level Agreements; the sales team needed customised products so that they could tailor their offering precisely to what the customer needed.

This is a classical conflict. The business consultants on the project called this “Operational Excellence” versus “Customer Intimacy“. And the consultants said we had to choose. It’s one or the other, you can’t have both. It’s like Henry Ford’s saying: “You can have any color car, as long as that color is black.”

Examining the conflictThe Logical Thinking Processes

It’s clear, you can’t have both standardised and customised at the same time. There’s a clear conflict. But we have a tool to deal with conflicts: the Conflict Resolution Diagram. Let’s apply the tool:

Product Variability CRD
The diagram says:

  • To have a growing, profitable business unit (A) we need to sell what the customer needs (C) and deliver it reliably and cheaply (B).
  • To produce reliably, predictably at low cost and to hit the Service Level Agreements (B) we need products with little variety (D).
  • To create an offer that responds to the customer’s need and to grow our market (C) we need to vary our products per customer (D’).
  • Conflict: we can’t have little variation (D) and a lot of variation (D’) at the same time, but we need both.

Questioning assumptions

We deal with the conflict by questioning the underlying assumptions. Can we find fault with our logic? Bill Dettmer recommends to restate the relationships in “extreme wording”. For example:

  • There’s absolutely no way to have both low and high variability at the same time! Well, duh!
  • The only way to be profitable and reliable is to have low variability! Well, it was hard to fault this reasoning as this company operated on large volumes with low margins and tight competition.
  • Customers always need special cases! Not always, but customers were no longer satisfied with one-size-fits-all offers. If this company couldn’t offer customised products, the competitors would be more than willing to get a new customer.
  • We could have low variability and yet vary per customer if only we didn’t have so many customers! Going niche wasn’t an option for economical and legal reasons.

We looked at it every way possible and couldn’t find a fault with the reasoning until…

Finally, some clarity

The Logical Thinking Processes have a set of “Legitimate Reservations”, a set of critical questions we should ask. The first one is simply called “Clarity“: is the meaning of every word and sentence clear to everybody?

Now, we had already noticed that the different departments seemed to have different definitions for the same word. There were even differences in the way they described the different products to us. Were we talking about the same thing?

The breakthrough came when we asked “What do you mean by ‘Product’?” A product for the Production department wasn’t the same thing as a product for the Sales department. And the accounting & finance department had another definition of product. But… That’s not a bug; it’s a feature: if a Production-Product is different from a Sales-Product, can we have Production-Products with low variation and Sales-Products with high variation?

After a lot more work we came up with a way to standardise Production-Products on a small set of “building blocks” and let Sales create Sales-Products by mixing and matching the building blocks according to customer need. Then we mapped Production-Products onto Accounting-Products. And everybody got what they wanted: Operational Excellence AND Customer Intimacy.

Embrace conflict

We didn’t settle for a compromise, but spent the time to really think through our conflicts and come up with a solution that satisfied all needs. A conflict can be an opportunity to come up with an innovative solution.

You don’t have to settle for compromises if you think about it.

Picture of Bonsai by A. Marques. Thank you.


More about Business Value

Liz Keogh comments on the Business Value estimation blog entry.

Thanks for the model; I’ll remember it for when a team needs to actually come up with some numbers (so far we’ve managed to avoid this!).

A business value model is useful without numbers, when prioritising by relative business value.

The most important thing we can do is to make the “value drivers”, the reasons we do this project, clear. Then we can evaluate any decision against these drivers.

“Increasing domain knowledge is one of the top value drivers for this project. Thus, I’d prefer to see feature A in this release, because it will give us more information than feature B, even though A is more expensive than B.”

“Feature C is going to give us a lot more visibility in the market than the other features and visibility is what this project is about.”

The reason I prefer “want” to “need” is for the same reason that we use “should” instead of “will” in BDD – it allows the goals to be questioned.

Yes, we need to question the goals — and everything else. How many questions are raised by “TO achieve this goal AS a stakeholder I NEED a capability”? A seemingly infinite number if I’m the analyst 🙂

  • Is that a valid stakeholder of our system? If we’ve built a context model, we already know which stakeholders we should consider. Or maybe we’ve discovered a new stakeholder we should include in our context model?
  • Is this a real stakeholder or are they representing a real stakeholder? For example, which is the most powerful user story: “TO sell more AS A salesperson I NEED <some differentiating capability>” or “TO improve my life or work in some meaningful way AS A user I NEED <some differentiating capability>”?
  • Is that a valid goal of our project?
  • How does this stakeholder goal get us closer to the project goal?
  • Is this goal there to support some other goal? If we derive stories from project goals, we will only create stories that achieve a goal or enable another story that brings us closer to the goal.
  • Do we really need that capability to reach that goal? Is there no other way?
  • Is that capability sufficient to reach that goal? Do we need something more?

The “Logical Thinking Processes” book taught me an interesting technique: use “strong” language to encourage questioning. For example:

  • “The only way we can ever reach that goal is to have that capability!” Well no, we could also…
  • “The only thing we need to satisfy that goal is this capability!” Well no, we also need…
  • “If that stakeholder’s goal is satisfied they’ll never want anything else again!”. Well no, they’ll also need…
  • “If we don’t satisfy that stakeholder, this project is doomed!” Well no, they could temporarily….

I like “need”. It’s strong and helps me to derive the minimum number of capabilities to achieve goals. I would ask “Do we need this differentiator? Why? What would happen if we didn’t have it? How will it change the lives of our stakeholders?”

“Want” or “Need”? It doesn’t make much difference. The process and the questions make a difference. People who ask questions make a difference.


Integrating the Toyota Way with Agile

Integrating Agile

I’m looking forward to next week’s Integrating Agile conference in Amsterdam. On the program, a nice mix of local and international speakers. A keynote by Henrik Kniberg is bound to be interesting. I heard Rob Thomsett at the London Agile Business Conference, so I expect to be challenged and entertained. Some other sessions look interesting too, but it’s hard to tell without further session descriptions on the site. Recommendation to the organisers: TO decide if I want to go to the conference and which sessions I’ll attend I NEED to know what each session will be about.

Toyota Way

The program also features a new version of the Toyota Way session, most recently presented in Paris. I’ve presented about this topic since 2005 and the presentation keeps changing as I learn more. This time it will change more than usual, as I’m co-presenting it for the first time with Portia. As usual when working with Portia, we have more new ideas than can fit in one session.

So, what is the session about?

We present the principles and practices of the Toyota Way and Lean Management. We explain how we apply them by giving examples from our experience. We show how each of the principles does not stand alone but forms a system that brings enduring improvements.

What’s in it for you?

  • See how the Lean Management principles of the Toyota Way have made Toyota a learning and improving organisation.
  • Understand how Lean and Agile relate to each other.
  • Learn how to apply this in your own organisation to make Agile and Lean transformations endure.

Lots of material

To give you an idea of what we talk about in 45 minutes.

Lean books

All of the wisdom in those books! Plus several years of experience applying these ideas in the real world.

It’s a bit harder to take a picture of experience. Although there are some wrinkles and gray hairs I could trace