Agile - O, be some other name!

Agile methodologies have been around for quite a while now. The Agile Manifesto was created way back in 2001. As such Agile - as a term - has gone from a curious status quo disruptor to a buzz-word to an entrenched term. It is similarly used and abused in the same fashion as most business terms. It also carries some significant baggage - not least of all the perception that it can only be applied to software development.

Shakespeare's Romeo & Juliet

Once one grows past the phase where one is simply trying to teach the practices of a particular flavor of Agile Methodologies, one is often faced with the decision of whether to drop using the moniker 'Agile'. If one sees the raw potential within the practices and principles to transform organizational culture to be healthier, happier and more efficient, how do you sell it beyond the IT department? Some leverage broader terms such as Organizational Development, others reframe the term to something like "Agility".

I see the appeal of these approaches and use them myself when appropriate. However, I am often struck that we are just superficially engaging in word play. We are left with Juliet's quandary (Act 2 Scene 2 Line 43): What's in a name? That which we call an Agile Team, by any other name would be as healthy.

Which brings us to the true focus of the more advanced Agile Coach - to transform the team's or organization's health so that they can be, among other things, agile. For this reason I like to embrace the baggage of the term Agile. It is a handle we can use to enter into a transformative conversation. This sort of conversation is usually had at the start of a relationship with a client or potential client. It might not even be had by an Agile Coach, but rather by a Salesperson. I am a firm believer that successful transformations begin at the very first engagement. Why not utilize the power of this handle to begin the transformation?

Rather than telling the person what Agile is, ask what they know about Agile; what they think it is. This can get into all manner of discussion quickly. Even misconceptions can be used as transformative opportunities. You can get quickly past lengthy and potentially boring or confusing explanations and start delving into where they are struggling and suggesting how you can assist them. If you use another name, you have to spend too much valuable conversation time just setting the stage.

... its like eating an apple

I was communicating with the owner of a client company where I am doing an Agile Transformation today when she said basically that to her Agile was all about reviewing, organizing and prioritizing things in bites... a bite at a time... I wanted to clarify to make sure that she understood much of the key is using the tight feedback loops available in iterative development; not just simply iterating. In response I continued the analogy - of eating an apple:

A bite at a time that gives you more info about the rest of the apple, is it juicy and sweet? Tart? Have worms? Rotten? But it is also taking that info and making decisions around the further eating of the apple... Should it be cut unto slices? Cooked in a pie? Can we cut out the bad part and keep the rest?

Or should we leave the apple at good enough and toss the rest in the compost pile while we go back to the fruit bowl for another piece of fruit?

Shortcuts don't always get you where you set out for

I have lived in a lot of places over the years. I have learned with each new place to get out and drive (or better - bike or walk) to start to get a feel for the place. Assess the lay of the land if you will. A number of years ago I was enrolled in a three year program at St. Louis University. So, I got myself a map which I kept posted near the door to my then apartment. Every weekend I would pick a place or a route to explore. I would mark it on the map either upon my departure or return. One day I had decided to check out some places downtown. On my way out, I asked one of my friends who was a native if they could tell me the best way to get to the first building. I thanked him and started on my drive. About three-quarters of the way there, battling down-town traffic I caught a glimpse of the building I was trying to get to down a quiet side street. This is nuts I thought. Why am I dealing with all this traffic when the building is RIGHT there! Needless to say, I promptly turned down the almost empty side street and headed merrily towards my intended destination. I remember congratulating myself that I had found a faster way than my native friend and making plans to tell him about the route when I got back. Then I made it over the first hill. While I could clearly see the building I had set out for from the initial route, what I had not seen was that this street ended with a very solid structure between my car and the streets beyond which would actually take me there. Of course, it then took even longer to go back, re-merge with traffic and get to my final destination. It turns out that St. Louis has a lot of these deceitful "shortcuts". My friend had a good laugh when I got back. I realized that I had momentarily put the real goal at risk by prioritizing speed to the goal. In the end it took a lot longer.

Let me tell you another story. One of my passions for many years is the traditional martial art of fencing. After a while, I wound up teaching it myself and running a salle. Now, most people who start fencing have at best, romantic ideas about what they are getting into. Few have any other martial arts background when they come to the salle. Fewer still, if any, have trained their bodies in the way that is necessary to move in our art. Our job is to train them how not to be hit by someone intent on hitting them. One of the first lessons a student learns with sword in hand is their guards and their parries. Inevitably, their first parries are all really wide (a natural reaction when someone is coming at you with a sword!). We calmly explain that while they may have avoided that attack, what if it had been a feint? Their large motion has left them wide open in all the other lines of attack. We work with them over and over through drills to parry a precise way and precise distance. We also repeat over and over that the goal is not to be hit and that part of that is to be efficient enough to be able to deal with multiple changing attacks.

Now one of the unique parts of our salle is that we believe in having all levels train together. There is value for the novices to work with fencers who already have the basics down. Additionally, the advanced students never stop drilling the basics. Eventually, therefore, we will get the question: why do you make us parry that way when the more advanced fencers parry differently when they fence?
Of course when starting out, focusing on form is important because it is really teaching you something deeper: how to be efficient so as not to get hit. More advanced students know more ways to do this by manipulating time, distance, blade engagement, etc. A novice does not. But all the novice sees is that the advanced fencer is using a smaller parry or a larger parry than what they have been taught. The thing is, it takes a minimum of two years of training and constantly being told the mantras about not being hit, and fencing is about trained, logical, efficiency rather than reactive reflexes before it sinks in.

So what does all of this have to do with Agile Development?

A friend and fellow Agilist, Chris Bartling, tweeted about a post he saw the other day: http://t.co/jq531Il

The blogger, Jay Fields, makes an interesting point. The goal of paired programming seems to address this principle of the Agile Manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." It also hits some of the other principles such as attention to technical excellence and of course the primary one of continually delivering valuable software (by quality checks and reduction of truck numbers). The thing is, no-where in the manifesto does it say that to achieve these goals you have to pair. Rather it trusts motivated, self reflective and self organizing teams to come up with good ways to meet these goals themselves. All of this I agree with. yet something still troubled me about the post.

Jay is like the native St. Louis resident, or the advanced fencer. He understands the deeper goals and has enough experience to be able to draw upon a myriad of techniques to achieve them. The thing is, it takes a minimum of two years of fencing training and constantly being told the mantras about not being hit, and fencing is about trained, logical, efficiency rather than reactive reflexes before it sinks in. Even after living years in a city, my knowledge of the most efficient routes will pale in comparison with someone who has spent their life there. Similarly, the principles of Agile development look great on paper... a team reads it and there is much head nodding and affirmative mumbling. Yet, they don't really sink in until you practice them. Jay mentions that he has been pairing for years before this recent project/position. Advanced fencers fence, novices practice techniques. Advanced Agilists are agile, teams new to Agility practice techniques to become more agile.

My concern with the post is that like so many novice fencers, teams new to Agility will just see Jay not doing a technique which they may not agree with or find particularly painful initially. They will ask, why should we do it if he isn't... can't we just ask each other questions when stuff comes up? Unfortunately, too often, new 'Agile' teams will fail to ask those questions. The rigor of stand-ups, TDD, pairing, even collocation, gets the team members into the habit of asking the right questions. It helps create a culture of communication and collaboration where it may not have existed before. Of course, simply doing these practices is not enough, and should never be dogmatically considered the 'only way to Agility' - a good coach will work with the team as individuals to nurture the new culture in subtle ways relevant to the team and individuals... but discarding a new practice without understanding the underlying goal or reason can wind up being as wasteful as my 'shortcut' in St. Louis - and probably a lot more costly.