Wednesday, January 26, 2011

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 TrustTrust/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.

Tuesday, January 4, 2011

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.