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.