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.

Presenting on Agility in Second Life!

On Wed April 20th at 7pm PDT, I will be presenting in Second Life. The topic is "Developing Healthy Teams through Agility".

Second Life is a thriving Virtual Reality community on the internet. There is a group of Agilists who meet there regularly.

Follow this link to join us in Second Life for the presentation: http://maps.secondlife.com/secondlife/Agile%203D/60/123/25

Prezi of a collaborative presentation on Virtue and Agility Patterns

I gave a dynamic, collaborative presentation on Virtue and Agility Patterns. Rather than using a slide based presentation, I used a tablet to mark up documents on the screen. This gave more of a feeling of using a whiteboard/chalkboard and allowed me to interact more with the audience.

Afterward, I compiled the artifacts into a Prezi.

All in all a neat experiment in making various presentation technologies work for us, rather than the other way around.

Sex, Lies & Agility Patterns on Prezi

Be sure to view it in full screen (under the More menu which appears at the bottom right corner of the Prezi).

The Grammar of Agile Software Development

This is in response to David Hussman's Tweet : "+5 RT @jbrains: "Please please stop using 'agile' as a noun" - @pragdave (YES!!!!) #magicruby

Agile: (adjective)
Agilely: (adverb)
Agility: (noun)

Examples:

"We are striving to develop our software in a more agile manner." - (Agile describes the manner [noun: object of a preposition] in which they are trying to develop [verb] the software [direct object].)
"We are striving to develop our software more agilely" - (Agilely describes how they develop [verb])
"We seek greater agility in our software development" - (Agility is the object of their seeking - and is as such a noun/direct object)

I think that people have become lazy and started truncating the descriptive title "Agile Software Development" to just "Agile". I am as guilty of this as anyone. Unfortunately this has done more harm than good and has led to a lot of confusion. Particularly, it may have contributed to the misguided notion that Agility is a binary state - using "Agile" as a noun gives the impression that it either exists or does not exist ("Are you doing Agile?")whereas the term agility used in its common sense is well understood to be manifest in degrees.

"The young gymnast's agility was only enough to perform the most basic routine".
"All things which move of their own volition are agile, however they possess this agility to varying degrees. Hence a deer can move more agilely than a rhinoceros."

I hereafter shall endeavor to respect the proper terms of speech when discussing Agile Development.

Any other suggested corrections of the use of the term "Agile" and its variances?

Aristotelian Software Development = Agile Software Development?

I admit it. I am an Aristotelian. What I mean by that is that of the three predominant ethical theories, deontology, utilitarianism and virtue oriented ethics, the latter makes the most sense to me. It is the ethical theory which was promulgated by Aristotle. Jon Dahl gave an excellent introduction to ethical theory and comparison to software development. Initially, he alluded to the fact that determining what makes a good programmer has less to do with external signs, and more to do with the programmers habits. He briefly makes ethical comparisons of software development methodologies. In this sense, he starts to look at the human element of software development. The rest of the talk, however, makes comparisons between ethical theories and specific programming languages. Perhaps this is because he was at a Ruby conference. Ultimately, I think that a closer analogy can be drawn between specific programming languages and philosophical principles from Metaphysics or Ontology rather than Ethics. This is because languages are tools for expressing concepts. Ethics however, deals with humans and human society. The goal of Virtue Oriented Ethics is for the individual to achieve a state of Eudaemonia: human flourishing. Applied to software development we could say we wish the team or project to reach a state of flourishing, or Software Development Eudaimonia. As such, I think that comparison to ethical theories is more appropriate to things such as Software Development Methodologies or Project Management.

I am an Agilist (no surprise there). If you have ever had the good fortune (Eudaimonia is also sometimes translated as good fortune) to be on a highly Agile team, you probably have a sense of this flourishing. Notice how I used the comparative when describing the Agile team. Agility is not a binary state as much as it is a spectrum. Similarly, Eudaemonia can be achieved to varying degrees. The recognition of underlying rules or laws which help a society achieve such a state is codified as Natural Law. In so far that Agile methodologies work because of their recognition of humans at the core of software development, I think Agile comes close to describing a Natural Law of software development. Yet it is one thing to state a Law or set of Laws and another to develop a lawful society. Dahl brings this up when he talks about how the XP rules as they are promulgated are very deontological. Following the rules does not ensure that you will be a good programmer. This is interesting in that the people who came up with XP were good programmers. The generation of their rules probably was a long process of self reflection and attempts to make both their code and themselves better. So while the rules they promulgate may be used deontologically, the rules  themselves were likely developed via a more virtue oriented or utilitarian analysis. A common concern is how to get a team or company to 'become Agile'. Downloading lists of rules is easy, transforming a culture is not. Approaching Agility as attainable by degree seems to lead to better transformations. However these transformations are not simply replacing one deontological set of rules for another. People sense a real change in how they interact.

Therefore I posit that Agility is the Eudaimonia of Software Development. To follow the Aristotelian thought that virtue is taught by role models, perhaps a better use of the XP rules is as good models to others; sort of a goal state for developers working on their own virtue. Yet this presupposes that there are virtues inherent to achieving Agility. What are these virtues? Where would we look to find these virtues?

In his blog, Todd Hoff compares Agile as Aristotelian with Waterfall which he deems Machiavellian. In this, the core element which he recognizes is a scale between Trust and Fear. He presents the Waterfall world as being fear driven, whereas the Agile world requires teams built on trust. I think this a good place to start with analyzing Agile from a Virtue Oriented perspective. In many lists of Virtues, the concept of Trust is apparent. It is usually listed as Faith. In our modern minds, this word often is equated with a naive, unfounded belief. The way we use the word faith throughout our language indicates trust born from an observation of habitual behavior. We can say a dog is faithful, or I have faith in my friends, team members or boss. We say we are faithful to our spouses. This is language of Trust. In many of the classical virtue lists, Trust/Faith is a core virtue. This is similar to what we see in Agile transformations. The failure of many teams to transform to a higher state of Agility is often tracked back to embedded distrust within the culture.

In order to place the virtue of Trust in an Aristotelian context, it should be on a spectrum, with the virtue found at the mean of two extremes. So let us say that on one side we have distrust breeding fear. On the other side we have naive or blind trust, where we have no reason to really trust. The mean then is a Trustful state - where the team members both work to be Trustworthy/Faithful and based upon the actions of other team members they Trust or have Faith in them.

Naive Trust

Trust/Trustworthiness

Distrust/Fear

What then are some other Virtues embedded in Agile which help to promote Software Development Eudaemonia? The XP rules mentioned by Dahl have been noted as being somewhat limited in scope. So,while they may be a good guide for some of the team, they may not be the best model for general Agility. In their broad approach, the Agile Manifesto and Agile Principles are a better suited for guiding general virtuous development toward Agility. In my next posting(s) on this topic, I will go through these documents and highlight traditional virtues which are embedded in the behavior they are trying to model. I will then discuss how these behaviors and particular techniques from various Agile methodologies can help a team or individual increase specific virtues and achieve greater Agility.

What makes Agile work

In my career, I have seen team after team struggle to 'succeed' at implementing Agile. I asked a recent Product Owner who felt that the team had been partially successful, but still had a way to go, what he felt made Agile successful on his team. His answer was enlightening. He said 'the ability to change.' In essence, this is a tautology. Agility is the ability to change. It is why one would chose to implement Agile. It is not however, what makes Agile work. This is unfortunately typical. A team will focus on one practice or outcome of Agile as being the be-all of Agile. In so doing their focus creates false expectations and at the same time prevents them from focusing on making the changes necessary to harness Agile most effectively.

So what is it that make Agile work? Let us look at the Agile Manifesto and the Principles behind it. Over and over again, one concept is referred to: People develop software. (Humanitatem Progressio Progressus) In other words, Agile is successful when it recognizes that Human Beings are the core component of the development process; not tools, not methodologies, not practices, not languages. Once we recognize that Humans, and not just Humans in the broad sense, but specific individuals, we are faced with individuals who each bring specific strengths and weaknesses to the development effort. From here on out, everything else in Agile is simply about helping teams enhance the strengths and mitigate the weaknesses of individuals on them. The primary tool which Agile uses for this is tight feedback loops. Agile fosters communication so that the dangers of weaknesses can be exposed and avoided and strengths can be shared or leveraged quickly.

This brings me to the failure point for every team I have seen struggle with Agile. Something gets in the way of the communication. While I intend to post on technical issues as well, my primary focus for this Blog is to explore the ways communication breaks down on Agile teams and what tools Agile methodologies have to solve this. Where the methodologies do not propose a direct solution, I hope to bring you thoughts from practice and professionals on tactics used to bring Agile teams back on course, keeping the principles and the humanity of software development in mind.