Technoetic

In a recent article I wrote about preferring Effective Software Development (ESD). I prefer being effective over being labeled as “agile” (whatever that might mean to you personally). This preference raises many questions for me. How do I define effectiveness? How do I know if I’m being effective or not? How can I become more effective? Is there any way I can help those around me be more effective? As you can imagine, these questions lead to many others.

I like the Wikipedia description of effectiveness. The description defines positive effectiveness in terms of efficacy and efficiency. Efficacy is the ability to produce a desired effect or achieve a goal. In a software development context, that might mean the ability to produce timely business value. Efficiency is the amount of effect that can be produced with a given amount of resources such as time or number of developers.

I think of efficacy as a primary component of effectiveness and efficiency as a secondary component. Continue Reading »

There’s been much discussion and debate in various forums about the evolving use of the word “agile” to describe software development. Some people involved in the discussion have suggested creating a new term to replace “agile”. In most cases, I don’t support replacing terminology. However, the term “agile” seems to have suffered so much semantic diffusion that it’s practically meaningless.

Speaking for myself, I am interested in the effectiveness of my software development activities, where “effective” must be evaluated in a specific context. In Effective Software Development (ESD), I want to have a wide range of resources (practices, tools, resources) available to me and I want to understand the tradeoffs associated with using these resources in various contexts. I’m not interested in labeling myself or my team as an “XP Team” or a “Scrum Team”. Who cares about the label if the team or organization is not effective.

I’ve seen several ESD teams who have used practices similar to the established named agile methodologies. However, they typically used a hybrid of those sets of practices. They couldn’t be labeled as Scrum or XP or Crystal or whatever. Their process was agile — but without a name. And they were effective.

I recommend not worrying about whether your team or organization deserves the fashionable “agile” label. The important question is “are you effective?”. Ask yourself what “effectiveness” means in your organization and then evaluate if your team meets that criteria. This isn’t an optimization problem. If you are effective enough, then focus on delivering value. If not, study the development options available to you and decide which ones will help you and your team be more effective. You might decide on a “ready-to-go” combination of practices like XP or you could experiment with a combination of techniques that are a custom fit for your team. Evaluate the results and adjust as necessary until you become an ESD team.

I’ve seen recent discussions in various forums about the meaning of XP values and principles. Here are my current working definitions.

Values. A description of preference between alternatives. Often the alternatives represent candidate courses of action and the value guides the selection among the alternatives. Sometimes values are basically axioms. They can be irrational in the sense that we might not be able to explain them intellectually or they might be primarily based on emotions.

Principles. Statements describing a model. A scientific principle is a statement describing an aspect of physical reality. Principles might also describe a model of social activity, for example. Principles can be fundamental or logically derived from fundamental principles. It’s commonly believed that principles are derived from values, but sometimes people have certain values because of specific principles. For example, the XP “value” of communication can be derived from the principle that communication improves cooperation and coordination effectiveness. This circularity between values and principles can be confusing at times.

Practices. A pattern of activity that can be repeated to achieve goals within a context. A person defining a practice is applying principles within a framework of their values (preferences). A related collection of practices might be called a process or methodology.

Continue Reading »

Why do some teams allow technical debt to accumulate and others are better at recognizing the debt and actively reducing it? One possibility is a skill difference. This skill difference could be the result of differing experience or differences in intelligence. In any case, the theory is that a more experienced, skilled team will generally be better at managing the quality of their software. This is certainly logical. However, I think there may be another aspect to consider. Continue Reading »

Kevin Brady claims they are in his recent blog article “AGILE /SCRUM Fails to get to grips with Human Psychology“. After reading his article, it seems it should have been named something like “Agile Methods Do Not Cure Dysfunctional Organizations”. I believe the latter is true. I think agilists understand this at some level and that why they focus so much on the “agile attitude”. My belief is that this “attitude” is a psychological prerequisite of a potentially agile team. Agile methods can’t reliably create this psychological state, but they definitely require it. Without an agile attitude (focus on business value over politics, people-centric, empowering, …), it’s not surprising that organizations would experience the Orwellian effects that Brady describes — no matter what software development process they chose to use.

However, it also appears that Brady has a limited understanding of the agile methods he criticises. Continue Reading »