Les cinq premiers pas pour devenir vraiment agile

Les cinq premiers pas…

Aujourd’hui, Portia et moi présentons une nouvelle session, “Les cinq premiers pas pour devenir agile” au XP Day Suisse à Geneve. C’est une présentation courte et interactive (les participants jouent 5 jeux) qui introduit cinq “outils” que nous utilisons quand nous commencons à travailler avec une équipe.

Plus de nouvelles après le congrès.

Cinq outils… et plus

Si vous voulez apprendre ces cinq outils et plein d’autres pour aider votre équipe a réaliser plus de résultats, devenir plus agile et s’amuser plus, la formation “Agile en Pratique” de Zenika est toute faite pour vous.

Vous aimeriez appliquer les méthodes agiles. Comment les appliquer dans votre équipe, sur votre projet ? Comment faire la transition vers les méthodes agiles? Cette formation répond à toutes ces questions. A travers des exercices, des jeux et des simulations vous expérimenterez les techniques agiles. Vous saurez comment, pourquoi et quand les appliquer afin d’améliorer la qualité du résultat et du travail de votre équipe.

Rendez-vous les 21 et 22 Avril à Paris!

The five first steps to become really agile

Portia and I present the “Five first steps to become really agile” at the Swiss XP Day. This new session presents five simple “tools” that we use when we start to work with a new team.

This is the first session that we developed first in french. We’ll translate it in English and do a tryout soon. Then we’ll publish the session on our Agile Coach site with the other games we’ve made.

More about the session when it’s published.


Kaizen in Paris – another reaction

Another reaction to the Zenika Kaizen presentation

Last January I presented an overview of the Toyota Way at a Zenika seminar in Paris.

Claire has written a summary of the session (in French).


Relinquishing the illusion of control – one small step at a time

Bart the BA had just joined the large organisation where I was coaching. He asked me to help do the business and functional analysis of one of our largest projects. He had several years of experience analysing large systems. I tried to teach him how to do Agile analysis, convince him that he didn’t need every last detail before development started.

I failed.

The result was a thick document that described the processes and business rules in excruciating detail.

That won’t work!

There are a few ideas in Agile methods that are almost always met with incredulity and disbelief. The reaction ranges from a puzzled “Hmmm… That’s an interesting/unusual idea” to “Are you crazy? That’ll never work!”. What’s so hard to believe?

  • Project managers can’t believe their project will run more smoothly with less detailed planning upfront and detailed controls on what the team is working on.
  • Architects and designers can’t believe the application’s architecture will be more appropriate and easier to understand and change with less detailed design up front.
  • Analysts can’t believe the team will understand what the customer needs with less detailed analysis up front.

The Waterfall dies hard

Wasn’t the Waterfall dead and buried? Why do so many people still think that doing more work and more detailed work up front will improve our projects?

It’s only natural.

Projects are scary. There are so many variables. So much could go wrong. Our instinctive reaction to deal with these fears is to nail more down, research in more detail, take decisions as soon as possible and reduce the number of variables and options. Which is exactly what we don’t want to do.

We want our coachees to accept the paradox that to control our projects better, we need to relax our control. If we want to take better decisions, we should take them as late as possible, when we have the most information. Instead of closing down options early, we should instead keep our options open to deal with an uncertain future.

Techniques like “Real Options” replace premature commitments with decisions about the conditions under which we will need to commit. Meanwhile, we can gather information and find more options.

Techniques like “Critical Chain” allow us to deal with the uncertainty of dependencies and estimates by giving us the means to deal with the planning risks as they arise.

Techniques like “Dimensional Planning” allow us to maximise value/effort by giving us the means to take decisions about depth of implementation as we get feedback from the customer.

An investment in code and design quality, automated tests and team skill keeps the system malleable so that we can deal with unexpected requests economically.

Leap of Faith

We must always be aware that to change the way people have worked, mostly successfully, for years requires a huge leap of faith from our coachees. When they first start changing the way they work, their performance will go down, they will feel uncomfortable and they will feel lost. They will want to go back to their familiar way of working.

We need to support them with practical assistance and encouragement, help them through the difficult moments and show them new techniques. We need to acknowledge their fear and address the fear:

  • Yes, emerging design will rapidly degenerate unless we all have the discipline and skills to apply good design principles, practice test-driven design, continuously refactor and continuously improve teamwork. How can we strengthen the necessary practices and skills? How can we trust the team to do a good design job?
  • Yes, just-in-time requirements will fail unless we have close collaboration and communication with customer representatives. How can we ensure that we will get quality information from them? How can we trust the customer representatives to do a good job of describing and validating user’s needs?
  • Yes, “rolling wave” planning will fail unless we receive good credible and reliable information about estimates and status from the team. How can we ensure that the team has the necessary skills and transparency to provide the project manager with the right information at the right time? How can we ensure that the project manager communicates clearly about goals and constraints? How can project manager and team trust each other?

Bart noticed that the developers didn’t really read the requirements document. The developers wanted User Stories, so I helped him to translate the requirements into stories. Whenever the developers had questions they came to Bart. Through his work on the analysis he knew pretty well what the system was supposed to do. When he didn’t know, he knew who to ask.

Gradually, Bart became this team’s product owner. Some expert users were added to the product owner team. For the next release, the product owner team started with stories and elaborated the detailed requirements just before the developers needed them. For the first time in years, users were happy to receive new releases of this application.

What’s common in all of these concerns?

  • Relinquishing control, or at least the illusion of control.
  • Mutual trust.

The best way to break out of the vicious cycle of distrust and increasing control is to inject some trust into the system. Increase trust by the project manager by helping the team to communicate transparently about progress, for example with a burndown chart. Increase trust in the team’s estimates by using historic velocity. Increase trust about requirements by involving users, analysts, testers and developers in the definition of user stories and acceptance tests. Increase trust by showing the working and growing system regularly.

We, as coaches, are sources of trust. We’ve done this before. We’ve done this successfully before. We’ve also failed; but we’ve learned from the failures. An investment in coaching is an investment in trust.

Small Steps

A small step is a lot less scary than a huge leap. Therefore, we try to help our coachees to change gradually. First try a little less upfront work on a small project. Gradually decrease the amount of control; gradually increase the number of projects where the techniques are used; gradually increase the number of people who change their way of working. Small successes increase trust.

But the idea that you can get to your goal in small, incremental steps is another idea that many find hard to swallow.

The alternative is to take the “just do it” route: the team decides they will apply these changes on the next project and see what happens. They trust that the coach will act as their safety net. They trust that the coach will catch them if they fall.


XP Days France 2009

Paris au printemps

I’ll be back in Paris for XP Days France on May 25th and 26th. The conference will be held in beautiful Bois de Vincennes.

Portia and I will present the “Blanche Neige et les Sept NainsAgile Fairytale and “The Business Value Game” simulation. By then we’ll translate both games into French and publish them with the same Creative Commons license as our other games.

Bonjour à nos amis francophones en France, Belgique, La Suisse et ailleurs. J’espère vous viendrez jouer avec nous au Conte de Fées Agile de Blanche Neige et les Sept Nains et “Le Jeu de la Business Value“. Ces deux jeux seront disponibles en version française avant la conférence. Comme tous nous jeux, ces deux sessions ont une license “Creative Commons”, donc vous pourrez les jouer chez vous.

A bientôt!


Craftsman or Professional?

A guide for craftsmen

Jason Gorman wants “…a guide book on Applied (or Interpreted) Software Craftsmanship“.

Could the “Software Engineering Code of Ethics and Professional Practice” be a place to start?

Are you a craftsman (or -woman, I suppose)?

Are you a professional?

Summary of the code

The short version of the code summarizes aspirations at a high level of the abstraction; the clauses that are included in the full version give examples and details of how these aspirations change the way we act as software engineering professionals. Without the aspirations, the details can become legalistic and tedious; without the details, the aspirations can become high sounding but empty; together, the aspirations and the details form a cohesive code.

Software engineers shall commit themselves to making the analysis, specification, design, development, testing and maintenance of software a beneficial and respected profession. In accordance with their commitment to the health, safety and welfare of the public, software engineers shall adhere to the following Eight Principles:

1. PUBLIC – Software engineers shall act consistently with the public interest.

2. CLIENT AND EMPLOYER – Software engineers shall act in a manner that is in the best interests of their client and employer consistent with the public interest.

3. PRODUCT – Software engineers shall ensure that their products and related modifications meet the highest professional standards possible.

4. JUDGMENT – Software engineers shall maintain integrity and independence in their professional judgment.

5. MANAGEMENT – Software engineering managers and leaders shall subscribe to and promote an ethical approach to the management of software development and maintenance.

6. PROFESSION – Software engineers shall advance the integrity and reputation of the profession consistent with the public interest.

7. COLLEAGUES – Software engineers shall be fair to and supportive of their colleagues.

8. SELF – Software engineers shall participate in lifelong learning regarding the practice of their profession and shall promote an ethical approach to the practice of the profession.

Copyright (c) 1999 by the Association for Computing Machinery, Inc. and the Institute for Electrical and Electronics Engineers, Inc.

Read the full version.