The XP Way

I have been definitively influenced by the book The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer when I decided to write this article. In addition, recent debates about XP have greatly contributed to these following humble thoughts.

It comes from this question Where does XP goes ?

In France, it seems that XP and in a broadly term, agility have really engaged the attention of software businesses. However, implementing XP is not so simple. And many of those businesses have knocked bad experience(s). For sure, it's a commonplace to say that making a XP project working requires a good approach and people who have a strong development experience. But it is really necessary ? Why firms do no succeed after reading Kent Beck's books ?

The Toyota Way approach to business is very similar to the one that should be done by firms who want to implement XP. There are several values, principles and pratices around XP. Anyway, implementing them from scratch is not the good way from my point of view. I honestly think that you should first understand deeply XP and its philosophy. That's the XP Way.

The XP Way allows to build auto-organised teams which can create hight quality sofware around unitary test, pair programming and communication value. To that aim, the success key is not to have great experienced designers, but to create rather a XP philosophy that matches the values of your firm.

This personalized XP philosophy is easier to develop when you have XP developers in your team, but I am pretty confident that it might be put in place when everybody follows the same strategy : the XP Way.

Make growing a common vision

Since two monthes, I'm coaching a team of 6 developers on a 5 years old project, which has became a standard in the firm.

I joined this project more than 3 years ago and the today-developers are mainly new in the project - the older one has started in July last year. Indeed, there were 2 others senior developpers in the team last year: Pascal who has left the firm in december and Jean-Christophe who is currently working on another project since the beginning of the year.

To sum-up, there is from now 6 new developpers and me, coach and owner of the knowledge of the project. What a terrifying responsability! Good enough, Jean-Christophe is not too far and I can have long talks with him. I must admit the situation is not simple, the sofware is wholesome but very complex. My wonderful challenge is to help the team to acquire the vision and values which were the fundament of the application.

As I was used to encourage communication within the team, we had each Monday very long meetings trying to define the way to work and the content of our 2-weeks-long iteration. It was in January. Now, in March, we finally start to have something you may call an agile team.

We were often forced to change our methods, old habits were broken and pridefulness was left aside.

What I am particulary proud of, is the behavior of the team. We succeed to talk without any aggressiveness or conflict. Quickly, each of us, included me of course, was ready to hear criticism and take into account remarks to improve our work. I really think it is only possible when the respect is present. This is the most important value if you want to share something with a group. Clamp your method and I'm almost sure you will fail.

People is fascinating.

Our current process is very closed to the one used by the team of the project 2 years ago. But this process belongs to the new team: they build it! And now, a common vision starts to grow.

Help other to capture the project, they will be motivated and have the feeling to create a huge and powerful team. That's a reality, I'm living it!

Agile patterns and Anti-patterns

A few weeks ago, I have assisted an Agile seminar at Valtech.

Indeed, it seems there is a wind of change in the business in France. Some compagnies, such Valtech, a consulting and training firm, have decided to focus on Agile Methodology. A good news?

Yes. It could be... I'm just a bit suspicious about the way it is propagated. Agile might become a magic word that will have no real mean for most of people. Nevertheless, as long as there will be agile defenders, I won't be afraid for the future.

Go back to the seminar. there was a presentation about Agile pattern and Anti-pattern from stories of Agile projects. This part was really interesting; others presentation were not unpleasant, but they do not catch my attention so much. Well, the main aim of the Agile pattern and Anti-pattern presentation was to present several case studies, and for each, identify agile patterns and anti-patterns. Fundamentaly, patterns identified were not suprising. There come from common sense. But, I really like these kinds of approaches that open our internal opened doors. It focuses our attention in a way that we would'nt have done. That's clearly one of my favorites game, sometimes, it doesn't work, sometimes it does. When it works, it's a Disney effect: a kind of magic. That's what happened with me this day.

Just to give you a taste of it, some agile patterns: read books by Kent Bek, Martin Fowler, learn through an XP game, use small teams and expert coaching, start with pilots projects with high business value, adapt of agile to your business, gain support from sponsors, make unit and functional tests, deliver incrementally, follow consistent process, make daily standup, work in an iteration backlog, de-scoped the release; some anti-patterns: senior management who dit not understand why there were spending good money to play games, no product owner, no longer the ability to predict project end dates, Quality Assurance department joins team late, team works weekends.

That's impressive. You can start by applying these patterns and not following the anti-patterns, and you have an idea about what is agility. It helps you to de-waste your organization. We may have an hight productive discussion about these patterns. I trust you to do it in your team, it will provide you the most benefits. Anyway, if you want to start a discussion about it, I will be very happy to join.

I just wish to focus your reading on one point: the importance of having slack. I slacked my work to assist to this seminar, and it helps me to have insight about the way I define agility. It changes my point of view, it kaizens my future working days.

The Most Complex Thing That Could Possibly Work

When I read first eXtreme Programming explained of Kent Beck, it sounded to me like an evidence that we have to do the Simplest Thing That Could Possibly Work. Where is the trap? Don't we are all aware that making things simple is the best way to be understood? In every day life, it seems it is true. We seek first to understand then to be understood. Hum...

Later in the book, I began to catch what he really means:

It's hard to do simple things. It seems crazy, but sometimes it is easier to do something more complicated than to do something simple.

The irony of trying to make things simple is that it is often simple to make things complex and complex to make things simple.
I nearly experienced this, and it definitively convinced me that, in certain cases, it is a real waste of time to try to explain why something looks complex while an easier solution could work.

It happened with the agile process group in my firm, the group I talked about in a previous article. Let me present what shocked me.

Test-driven-development is one of the XP practice that helps making things simple and designing in small steps. As the agile group tried to define completly the agile process, they had finalize a schema, that I changed a little to be allowed to show you the result:



Waouh! Arraws everywhere, boxes, lot of texts! I immediatly felt bad about it. Who wants trying to do TDD when it makes you several minutes before understanding what it is? Maybe it's me who hadn't understood TDD? So, I went back to my books, I seeked for information on the web, and tried again to define what is TDD. My research conducts me to my first feeling: this schema is the Most Complex Thing That Could Possibly Work to explain TDD.

For those who discovers TDD, I made an other schema:


I think no other word is needed to explain TDD.

Unfortunatelly, my proposition has not been kept for several reason. First, because it cames from me. The person who mades the complex shema, someone I sincerely respect, do like being the owner of everything. Secondly, because this person had never really practiced XP (only a few monthes) and from my point of view, didn't caught what being agile means. Finally, because it was not complex enough. His value system says that he can only be impressed when things gets complicated. He is an engineer! His work is complex and consequently, what he has to show must be complex.

I tried to discuss... And I wasted my time. Now, I gave up the working group. The energy required to be heard costs too much and there is no gain. I prefer concentrate myself with my team, which will continue over any process to be agile.

Back to earth

Back from holidays.

I stayed in the south of France, near les Pyrénées, where a part of my family lived. And I re-discovered the nature. This country is purely beautiful. It helps me to take some distance with my work and with my thoughts about XP and agility.

In our society, it seems we have forgotten the real sense of life. What are we working for? For money? To pay this new car we have dreamed of? For our employer? To have this reward our co-worker had last year? For our family? To have its beloved recognition? For ourself? To feel proud and strong?

There is no hint of pretentiousness in this article about what is the real sense of life. Let me present my point of view.

De-waste ourselves.
It's a bit like we have reached the transition in the stone age between the Mesolithic, where human had a mobile lifestyle, and the Neolithic, with the settlement.

Nowadays, there is a new transition between those who stay quietly with their job, do what they have to do, sometimes do a little more, and those who have discovered jobs won't fall anymore from the sky. It's a big change about our approach in our work and consequently in our life. It has to come from ourselves. We are working to help others making products and money. We need to discover what they need, listenning to them with compassion, understanding what they want, and decide how we can offer them our knowledge.

I really like the metaphor with the prehistory, because it's a change of the way we see work and life. It reminds me my first coach, Régis Médina, who loves telling stories, with always this desire to share his new thoughts, wishing for this flash of inspiration that will profondly change human minds.


Have a look to this funny book, Who Moved My Cheese?. It aims to help you to see where you are in your life, with your family, your friends, your work. It doesn't tell you how you can change, but gives you ways to enjoy about change. Maybe It's right, our society his changing, we have reached this transition...

In which side will you be? Mesolithic? Neolithic?
In which side will I be?

Agile or not agile?

What does being agile mean?
Who am I to try answering such question?

Well, well... My firm is trying to standardize our software development process. In this context, a working group has been created to write documents definying agility.

My first feelings were disappointment and anger. It smells the end of eXtreme Programming in this firm! Agility should not be defined, it is a way of thinking, of being. The Manifesto for Agile Software Development talks about values, no way about definition.

Anyway, I joined the working group, with an other member of my team, Pascal Pratmarty, an enthusiast XP defender. The first meeting was unfortunately conformed with my fears. They really want to define a box for agile processes.

So, why not? Pascal and I may have the opportunity through this group to promote XP and its values. We even know that these documents may touch our directors directly and consequently give an extraordinary impact in sofware development processes in this firm. Haw... Let's go this way! But our way, and out-of-the-box!

Since few days, I'm trying to define in one sentence how I see an agile team. I reached this:

The ability to change quickly a plan to add a new feature developped with an high quality, respecting customers requirements, and delivered in-time.

It pleases me.

Of course, it's probably not perfect and may be incomplete. But I'm seeking for improvements... Therefore, I'm waiting for your comments and delight to share with you agile experiences.