Back To The University

Octo Technology is pulling together a kick-ass event on July 2 & 3 - l'Université du Système d'Information.  It's a mix-conference targetting software makers and executive managers, designed to have them both share their respective experiences with IT systems.  Two days packed with top-notch sessions, prestigious speakers and experts from various horizons.  It's going to be fun, it's going to be French.

I'll be there, hosting a session "Percevoir plutôt qu'être perçu" (translation left as an exercise to the reader) with my famous fellow Bernard Notarianni and a Change Artistry Clinic with a gang of colleagues.

For you agilists - you'll recognize yourselves - my friend and colleague Christophe Thibaut organizes within the conference a special training track on Test-Driven Agile Development.

Working at Octo, it's a unique and exciting experience to see how the whole conference is shaping itself, from early concepts to final integration.  The great contents set aside, I'm impressed with the level of integration of the different sessions into a cohesive whole - something that I'm not accustomed to, as a regular attendant of conferences mostly organized in a distributed, decentralized manner.  As an insider, it's nice to see colleagues talking about and beta-testing others' sessions.  It's equally nice and refreshing seeing everyone focusing on the product as a whole, and not merely on their own session.

Face it - if you still needed a reason to learn French, here it is.

July 2-3, 2008, Paris, France - Be There or Be Square!

Dissociative (Agile) Identity Disorder

People are always asking me if I know Tyler Durden. 

No, they aren't really.

What they do ask me is, "what's the difference between Scrum and XP?"

What they do ask me is, "when should I do Scrum and when should I do XP?"

What they do ask me is, "what best practices of XP and Scrum should I combine?"

Strangely enough, very few ask me about DSDM or Crystal or Lean Software Development.  That's too bad because I can't wait for the moment someone will ask me for differences between crystal meth(od) and LSD.  DSDM doesn't bring the opportunity for interesting puns so I'm not in a hurry having to talk about it.

Seriously - I don't think there's much difference.  

Yes, terminology differs. Yes, books don't have the same covers, and granted, Scrum has its own church.  In essence however, the goal remains the same.  Find a way to make great software now, tomorrow, everyday, that delivers the best business value given the current context.  Various people have found various ways to tackle the question - or should I say, where to start.

I like to consider various agile methods as ways, as in martial arts.  The Way of the Tiger.  The Way of the Bare Hand.  The Way of Clean Code.  The Way of Team Alignement.  

Starting tackling with the question of making great software with improving the estimations is as valid as starting with improving the test coverage or improving communication flow.  We're talking here about complex, systemic dynamics.  Problems are interrelated. So eventually, what will prevent you from improving your estimations will be communication flow.  Or test coverage.  Or: what will eventually prevent you from improving your test coverage will be communication flow.  Or - you get the picture.

So eventually, by focusing on improving one bit and committing to it, you'll start improving the whole.

Wondering what's the difference between XP and Scrum is the same as wondering what's the difference between Aikido and Jiu-Jitsu.  It does matter, to a certain level, and it really doesn't if you want to become a practitionner.

So here's my advice.  Stop worrying if you've chosen the right method.  Start with what you have.  Or start with what looks the coolest to you.  Or start with has best support community around you.  Define what you're trying to improve and frequently check you're improving it.  When improvement stops, ponder and wonder.  And if you're out of ideas, get back to your favourite method books and see what they have to tell you on the subject.

And, oh, leave taxonomy to the dilettante and the scholar.

Upcoming events

I'll be at AYE at the beginning of November, in Phoenix, AZ. I'm thrilled to eventually be able to attend this conference, after several years of hearing about it.

I'll present with my friend and colleague Bernard Notarianni a workshop called "Frictions/Creations: What's at Stake With Incremental Design" on Thursday 11/15 at XP-Days Benelux in Mechelen (Belgium). If you haven't attended our workshop in Como earlier this year, here's another chance :) This workshop focuses on the dynamics of relationships between customers and coders during the making of a piece of software. It uses non-conventional tools, features dramatic twists and brings a new lighting to agile practices such as Onsite Client, Incremental Design, or Metaphor. I'll stay over for the rest of the conference.

On 11/19 and 11/20 I'll be at XP-Days London. Laurent Bossavit and I will run together "Project Status: Writing On The Walls" on Tuesday. This is a tutorial on how to write Big Visible Charts and where to start. I like it a lot because of its fast pace and its concrete hands-on aspect.

Last but not least, I'll be at the Smalltalk Party in Paris (France) on Saturday 1/12. It looks like we're going to run a dojo session. Yay. Thanks to Bernard Notarianni, the party will be hosted at Octo.

If you'd like to meet me at one of these events, feel free to let me know.

Beckett, Jimi's Guitar & Agile Practices

(Note: this is the translation of a post I've written in French for Octo Talks! earlier this summer.)

Developers get perplexed over Amr's article: do agile practices such as TDD or incremental design make them program "good" software? Do such practices help them to get to elegant solutions that will force the respect of their peers?

If you get around musicians, you'll end up meeting the archetypal Dilettante Beginner. D-Beginners aspire to play like God, but they can't because they don't have the right Wah-Wah pedal, because their reed is too thin, because their keyboard doesn't have a good sound... They just can't -- yet. Here is the pattern: "I'll stay a beginner for now, but just wait for my being rich enough to buy a Fender Stratocaster (and then you'll see)." Twenty years later the chap has got his Fender, he's still a beginner and he can only play the two first bars of a Jimi Hendrix's solo in synch with his stereo -- the volume cranked up to Full Blast.

The instrument doesn't "make" the musicien. What does is their motivation, their relentless desire to improve in spite of regular failures and frustrations. Their continuous effort to train again and again, even when not understanding why they're doing so.

Let's not downlook dilettantes, though :^) One has a lot to discover being around them. Dilettantes have a touching, idealist, optimistic side. And they usually know by heart the complete discography of amazing artists. Dilettantes are encyclopedists, they're erudite and passionate -- in place of being practitioners. Nothing wrong here, as long as we don't confuse one for the other.

-- Which brings us back to the initial question. As much as the instrument doesn't "make" the musician, agile practices don't "make" the developer. What does make is their motivation to improve, to try again in spite of past mistakes.

Or as Samuel Beckett puts it:

"Ever Tried. Ever Failed. No Matter. Try Again. Fail Again. Fail Better."

Are agile practices of any value, then? Let's get back to the musician and their instrument. When the instrument presses the musician to produce mediocre music (because the instrument has a poor quality, it's inconsistent, it's difficult to handle, etc.) two risks arise.

1. The musician's motivation may fade before they've reached a gratifying level -- before they've mastered enough musical language and techniques to be able to express their emotions through performance.
2. The goal of the musician may switch from "produce great music" to "manage to play a poor instrument (regardless of the outcome)."
   

Agile practices won't produce the "good" design (whatever "good" may mean). On the other hand, agile practices will help the coder to focus their energy where it's needed: on experimentation, learning, reading books and code... instead of evaporating this energy in patching every new problem, in staying at work late, in lying (to themselves) about the quality of their work.

To paraphrase the Irish writer: agile practices won't help you to succeed, they'll help you to fail better.

Announcing PairCoaching Workshop: Retrospectives for Agile Teams

Rachel Davies and I are running a day-long workshop on September 17 in Brussels called "Retrospectives for Agile Teams." This is a great opportunity to learn from seasoned facilitators about retrospectives, how to fit them in your agile process -- or in your development process you wish would be more agile -- and how to facilitate them.

You may register online on the PairCoaching Network website.

Francophones friends -- the session will be run in English, which might feel daunting to you. Don't panic. As a native French speaker I'll be able to help you understand what's said. I'm also ready to translate your questions from French to English if you feel ok to listen but too shy to speak in English.

Shout Kata @ Agile 07

I'll be presenting a tutorial at the Agile 07 conference in Washington DC -- The Shout Kata: Programming a Client-Server Infrastructure in full TDD.

The tutorial is an extended version of a kata, as performed in a Coding Dojo. I'll code in public a full-fledged client-server structure in Ruby, in TDD, from scratch, in three hours -- with the sole help of the socket and test/unit Ruby libraries.

The kata itself is coming nicely; I'm to the point where I can do it in two hours and a half. I'm now making small adjutsments regarding naming and tests order. I've found it's important to have a clear story line so that people can easily follow what you're doing.

I will run the tutorial on Monday 8/13 at 2:00 PM. See you then!

Loving / Hating The Code

"The less lines of code I have, the easier I'll be able to modify them without breaking anything. Wouldn't it be even better if I had no line of code at all?"

A fellow coder asked the question above during a discussion about the virtues of simplicity. He was upset by others justifying the use of programming language X over programming language Y by how much it helps to write concise and simple code. (Lesson learned: don't put values on pedestals, don't argue in public on which language is best -- if you don't upset your interlocutor, chances are great that you and them will upset third parties.)

Despite the tongue-in-cheek aspect of the question above, I suspect it reveals some truth about the attitude we coders hold toward our code. We see the success of a software project both as a motivation (justification?) for our current work, and we project in that future success our own to come -- rewards, recognition, promotion, etc. In this relation of desire between us (the subject) and success (the object), the software code stands like a mediator, the thing that allows -- or prevent -- the subject to access the desired object. We personify the code we write and we make it endorse what should be our own responsibilities : "it's not my fault if it's not working... it's the bugs in the code / it's because it's C++ / it works fine on my computer / it was working fine yesterday / etc." Our feelings towards the code/mediator varies according to circumstances from veneration to blame, from fascination to fear.

Our code doesn't rule our lifes, our reactions to the frustrations we experience do. When we realize we don't master the code's behavior, these reactions we should tame first, not the code itself.

I'm hoping for a change in the attitude we hold toward our work. A new mindset in which we don't personify the code anymore, but objectify it instead as a vector of change -- an opportunity to create value, with all the risks of impredictibility and chaos attached to it. What's at stake then isn't so much the number of lines of code one "should" write, but the compromise to find between the value one hopes to generate and the risks of losing control one induces at the same time.