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.