La deuxième présentation à la Conférence Agile France 2011 proposait six bases essentielles pour mettre en place un environnement de travail Lean ou Agile. Comme toujours il y a de bonnes nouvelles et de mauvaises nouvelles:

• La bonne nouvelle: Lean et Agile ne sont pas de la magie, entre temps on sait pourquoi, où et comment ça marche
• La mauvaise nouvelle: ce n’est pas compliqué, mais c’est vraiment dur de mettre en place les prérequis nécessaires.

La présentation ne donne qu’un aperçu de chaque élément. Voici des ressources pour les 3 premiers élements, qui peuvent vous aider dans vos recherches. Les 3 autres éléments seront décrit dans un billet suivant.

1. La Théorie des Contraintes

Originalement décrite par Eli Goldratt dans le roman “Le But”, cette théorie se résume très facilement:

• Le résultat de chaque système est déterminé ou limité par un de ces élements, le goulot d’étranglement
• La seule façon d’améliorer les résultats est de travailler sur le goulot.
• Améliorer les autres élements du système n’apportera pas de bénéfices, cela aura souvent un effet négatif!

Comme mon grand-père savait déjà: “pour rendre une chaine plus forte, il faut renforcer le maillon le plus faible”.

Le “Jeu du Goulot d’étranglement” vous fait vivre les conséquences qui vont souvent contre le “bon sens”.

2. Les Real Options

Au lieu de prendre des décisions difficiles le plus tôt possible, comme nous encourage toute la littérature sur l’architecture informatique, il faut

• attendre jusqu’au “bon” moment pour prendre chaque décision. On peut calculer exactement quand c’est le bon moment: la date de livraison – le temps d’implémentation de l’option
• jusq’au moment de la décision on garde toutes les options ouvertes
• on utilise le temps gagné pour rechercher plus d’informations ou pour créer d’autres options
• on essaie de réduire le temps d’implémentation de chaque option afin de repousser vers l’arrière le moment de la decision

L’heuristique que j’utilise:

• Une décision difficile à défaire doit être prise tard. J’essaie de réduire le temps d’implémentation pour avoir plus de temps de reflexion et évaluation.
• Une décision facile à défaire peut être prise tôt. J’essaie de convertir des décisions difficiles à défaire en décisions faciles à défaire.

Exemples concrets:

• Les User Stories nous donnent l’option de prendre des décisions difficiles de planning et contenu du produit plus tard que d’habitude
• Du code clair, facile à comprendre, bien factorisé avec des tests automatiques nous permet de défaire des décisions de design et architecture à faible coût qu’on a fait auparavant pour implementer de nouveaux besoins
• Le tableau Kanban permet à l’équipe de voir les goulots en temps réel et de réagir en conséquent.

L’article “Real Options Underlie Agile Practices” par Chris Matts (en anglais) explique les Real Options et le lien avec Agile et lean. Il y a un résumé des Real Options sur le site Agile Coach.

3. Gérer par la valeur, pas par les coûts

Au départ de nos projets on se met d’abord d’accord sur notre définition commune de “valeur”. Don Reinertsen appelle cela un “Project Economic Framework” dans The Principles of Product Development Flow: Second Generation Lean Product Development. Nous appellons cela un “Business Value Model” ou “Modèle de la Valeur Métier”.

Bien définir la Valeur avec toute l’équipe apporte beaucoup de bénéfices:

• Toute l’équipe est alignée
• Comme nous comprenons mieux le vrai but, il est plus facile de trouver des vraies solutions
• Il est très facile de prioriser
• Les projets deviennent plus petits parce qu’on élimine ce qui n’ajoute pas ou pas assez de valeur

La présentation

La semaine passée j’ai présenté comment résoudre les conflits avec le “Diagramme de Résolution des Conflits” à la Conférence Agile Paris. La présentation est disponible ci-dessous. Plus d’informations sont disponibles sur le site Agile Coach.

A la fin de la présentation il y a deux questions pour voir si vous avez compris la leçon:

1. Est-ce qu’il est possible de former un gouvernement belge avec cet outil? Si oui, pourquoi? Si non, pourquoi pas?
2. Est-ce que vous pouvez résoudre ce conflit récurrent entre Product Manager et Développeurs:
   • Le Product Manager a besoin d’estimations et de planning très détaillé et fiable pour publier une roadmap qui dit quand quel fonctionnalité sera livrée quand ET livrer ces fonctionnalités comme promis
   • Les clients, qui souvent sont des grandes entreprises avec plusieures filiales dans les monde et beaucoup d’utilisateurs, ont besoin de cette roadmap pour planifier quand ils vont implémenter une nouvelle version
   • Les Développeurs sont “passés au Kanban”: ils ont arrêté de faire des estimations ou des plans. Cela prenait beaucoup de temps et ce n’était jamais correct.
   • Les Développeurs “éliminent le gachis” parce qu’ils doivent aller de plus en plus vite pour satisfaire les requêtes d’un nombre de clients qui toujours croissant.
   • Tout le monde veut livrer les fonctionnalités au client au moment où les clients attendent ces fonctionnalités.

Vos réponses et questions dans les commentaires…

D’abord essayez de clarifier le conflit.

Puis, découvrez les suppositions derrière chaque étape du raisonnement.

Translation

I presented an interactive tutorial on how to apply the “Conflict Resolution Diagram” at the French Agile conference in Paris. You can see the English version of the presentation at the Agile Coach site.

At the end of the French version of the presentation there are two tests to see if participants understood the tool:

1. Can you use this tool to form a Belgian Governement. If yes, why? If not, why not?
2. Can you resolve this common conflict between Product Manager and Developers:
   • The Product Manager needs detailed estimates and accurate planning because she has to create a long-term roadmap which spells out which features will be delivered when AND deliver those features when promised to keep customers’ trust
   • Customers, who are typically large multi-site companies with many users of the product, need the roadmap because they need to plan when they will roll out which version throughout the enterprise
   • Developers have “gone Kanban” and have stopped estimating and planning because the estimates took too much time and were incorrect anyway
   • Developers stopped estimating and planning to decrease waste so that they can keep up with the increased demand for features from the increasing user base
   • The whole company wants to deliver the features customers ask for when customers expect them.

Answers on a postcard or a comment…

First, try to clarify the conflict.

Then try to find the assumptions behind each step of the reasoning.

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

The “Bottleneck Game” is a simple game that illustrates many Agile, Lean and Theory of Constraints topics. It’s available for free with a Creative Commons license so that everybody can play it. And people do play it all over the world. For example:

• Thierry Cros played the game in Morocco.
• Kevin Rutherford played the game in Manchester.

Great productivity improvements for both teams! But we all know software development isn’t manufacturing, right?

Try the game. Try some of the ideas. Just like in the game, your team can create more value with less effort and a lot less stress.

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 this interactive tutorial you’ll be able to apply “Business Value Modelling” on a case study, to decide on the goals and definition of value for an improvement project.

Come and play with us!

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.

Last Thursday and Friday I participated in the Lean and Kanban Belgium 2010 conference. I was scheduled to present a session on Friday morning, so I could go to many sessions on Thursday.

Every session that I attended on Thursday said many things I wanted to say:

• Sandrine Olivencia talked about challenging the team for continuous improvement
• Dave Nicolette talked about the dysfunctions around budgeting and the need for IT to integrate, not align, with the value stream
• Anthony Marcano and Andy Palmer explained how analysis can be implemented as a pull system
• Ryan Shriver essentially said all I wanted to say about finding the real goals of our users and quantifying their needs
• John Seddon told tales about really understanding value demand and taking a systems thinking approach to the design of work in his usual, inimitable style

What was left to say? At the end of the day I could scrap about 3/4 of my talk. The good news is that many people are independently reporting that these techniques and approaches work. And they can show results.

In the end, there was more than enough to fill an hour. After the presentation several people asked questions and discussed what I presented.

p.s. I followed Dave Nicolette‘s advice to grow a profitable consultancy: coin a new acronym. I give you “IDD”. You’ll have to watch the presentation to know what it means. And you’ll have to pay me big bucks to come implement it in your organisation

And yet they can’t manage to deliver simple IT projects taking a few months and requiring the coordination of only a few tens of people.

What am I missing?

Portia and I presented a tutorial on how to use the “Conflict Resolution Diagram” systems thinking tool at the Mini SPA conference in London on September 10th 2010.

The slides of the presentation and summaries of the systems thinking tools are available on the agilecoach site.

Let us know if these tools gave you ideas to resolve some conflicts in your life.

Portia and I have been invited to re-run the “Solve Conflicts without Compromise” session from SPA 2010 at Mini SPA 2010 on Friday September 10th. In the SPA session, participants used the Conflict Resolution Diagram to explore four real-world conflicts brought by the participants. I really liked doing the session, because the participants could really try out the tool and four participants got some ideas to solve some important conflict in their work and life.

Two features of the session were crucial to its success: we had plenty of time (3 hours) and a limited number of participants (20). Neither of those conditions will be true at Mini SPA. Therefore, we’ve had to apply some systems thinking tools to ensure that the session still delivers the benefits.

Check out the programme of Mini SPA: it features 6 of the most liked sessions of the SPA conference in two tracks. The conference is free, but you need to register. Don’t wait too long, places are limited.

See you in London!

The session will show how using business analysis and kanban techniques we can create a flow from business goals to implementable user stories with acceptance test, focus on value-delivering capabilities and involve the whole team in product development.

The “A3 report” is a standardized report format used within Toyota and other companies to make proposals and report. The standardized and constrained format helps the writer and readers to come to the point quickly, concentrate on the essentials and get the important information without wasting time.

However, when applying this technique we often only implement the superficial elements, the fact that the documents are limited in size and have a standardized format. Sometimes, the exact format of the Toyota reports is copied. And then we’re disappointed because this “cargo cult” application only delivers limited benefits.

In this session we’ll look at and let participants experiment with the social aspects of the A3 report:

• How we define the standardized format to support our goals
• How leaders and managers use A3 report writing by their team members are structured one-to-one coaching
• How to build in iteration and feedback from peers to improve the proposals
• How to use the review process as a consensus building tool
• How to present reports in such a way that they’re heard, understood and accepted

Come and play with us if you want to learn more about this powerful continuous improvement and learning tool.

If you want to know more…

• In “Pinocchio, On Becoming a Lean Leader” (Tuesday August 10, 13:30-15:00) Portia Tung and I help participants along the dangerous journey from toy boy to real boy. You’ll meet all your favourite characters from this Agile Fairytale and come away with some concrete actions to become a better leader.
• “Agreeing on Business Value using Systems Thinking” (Wednesday August 11, 09:00-10:30) is a workshop where Portia Tung and I help participants come up with a “Business Value Model” for their current project. You’ll be able to use the Business Value Model to identify the high value solutions that satisfy your customers. The number of places for this workshop will be strictly limited to 20.
• “Estimation Games” (Thursday August 12, 13:30-15:00) gives participants some rules of thumb to create reliable estimates with little effort. During the session we’ll play some small estimation games to put the lessons into practice. You need never be afraid again of estimating.

If you want to know more…

C’est la première édition de cette conférence et aussi la première conférence francophone sur l’agilité en Belgique.

“Les Boucles XP” est une introduction à la méthode Extreme Programming. Vera Peeters et moi avons créé cette présentation il y a longtemps pour donner un goût de la façon de travailler d’une équipe vraiment agile. A travers les pratiques et les exemples d’équipes avec qui nous avons travaillé depuis 1999, la présentation explique pourquoi cette méthode marche et comment procéder pour définir une méthode qui convient à votre équipe. Pour cela, il faut voir les choses comme un système où la valeur du tout est bien plus que la somme des valeurs des éléments.

“Agile + Business Analysis = Lean Projects” explique comment on peut combiner les techniques de Business Analysis avec ceux des méthodes Agiles pour “construire la bonne chose” et “construire de la bonne façon”. Le résultat: des projets vraiment “Lean”, de la demande du client jusqu’à la livraison. L’expérience nous a montré que cette combinaison nous a permis de livrer des projets en beaucoup moins de temps qu’auparavant et en même temps livrer un produit qui avait plus de valeur que prévu. Vous verrez quelques techniques que vous pourrez appliquer dès demain et des pistes pour en savoir plus.

A bientôt!