A blog.

That's not agile

I often hear “I do agile” and “That’s not agile” and I’m starting to put it into the same bucket as “That’s not an enterprise approach”. Such terms are often used to reassure those that have just heard that “Agile is good” or as a pre-emptive strike against those asking where the documentation is. I’m thinking of a few posts around items that are often labelled as “Not Agile” but perhaps really can be. First, though, I want to dig into the term “Agile” a little.

The approaches that were swirling around before Agile was something in which you could be certified included ideas such as rapid prototyping, iterative development, use cases and adaptive processes. It seemed that people were tiring of bloated projects that marched on like budget-destroying zombies. Central to many concerns appears to have been the issue of gathering requirements/needs and turning them into software. Do it as two very large blocks and the requirements phase isn’t based in the reality of implementation. Expecting that the users/stakeholders can describe all requirements/needs/goals completely and comprehensively up-front was to ignore the complexity of what is being built and our ability to grasp the context as a whole.

But let’s go back a little. In August 1970, Dr Winston W Royce started paper in Proceedings, IEEE WESCON with:

I am going to describe my personal views about managing large software developments. I have had various assignments during the past nine years, mostly concerned with the development of software packages for spacecraft mission planning, commanding and post-flight analysis. In these assignments I have experienced different degrees of success with respect to arriving at an operational state, on-time, and within costs. I have become prejudiced by my experiences and I am going to relate some of these prejudices in this presentation.

Royce goes on to describe what many refer to as “the waterfall method” of:

  1. System requirements
  2. Software requirements
  3. Analysis
  4. Program design
  5. Coding
  6. Testing
  7. Operations

Royce doesn’t call this approach “waterfall” in the paper and he points out that it “is risky and invites failure”. He also states that it is “important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.” It is here that the past tells us that we are building software for people and the best input into building software is people. People who can describe what they need and tell us how well we’re going by trying out our work - a collaborative feedback loop.

In The Sciences of the Artificial, Herbert Simon posits:

An artifact can be thought of as a meeting point an “interface” in today’s terms between an “inner” environment, the substance and organization of the artifact itself, and an ’’outer" environment, the surroundings in which it operates. If the inner environment is appropriate to the outer environment, or vice versa, the artifact will serve its intended purpose.

It’s a great book and really gets into the act of design in the construction of artificial artifacts (such as software). Simon’s use of terms such as “satisficing”, “problem space” and “search strategies” give vocabulary items to the act of a project as a journey. It is upon considering software development as an act of design and a project as a journey that I see the Agile approach offering more than the linear, segmented viewpoints.

Agile basics

In February 2001 a small group of software people met in Utah to see if they could coalesce their various thoughts and experiences. This wasn’t an ISO committee or a Government research body - it was some 17 guys with a body of experience in software development. Let’s go back to the values they came up with and re-read their manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

There are also 12 principles underlying these 4 deceptively simple ideas - go read them. Also, understand that these are the aspects that make up Agile according to those 17 people and, by extension, those that claim they “do Agile”. Now, you might be a Scrum shop, an XP team, Crystal, insane chaos, whatever - it’s important to sit back, reflect and think about how effective the team is in meeting the user’s goals. This is the area in which all four items come together: Is the manner in which we’re working (interacting) with the users (individuals), really ensuring that we all understand what needs to be done (collaboration) to build working software that helps them and are we responding to new ideas and clarifications from our users? The various agile methodologies provide projects/teams with lamposts and signs down the Agile street but I recommend that all teams are best served with checking against their approach/interpretation against the manifesto to make sure they haven’t processed the user out of sight or put processes and tools first.

In many senses I don’t actually see this as an Agile-specific area of thought. If I can boldly argue: most projects commence with the aim of delivering some benefit to some party that (hopefully) has a greater return than the cost of the project or the cost of business as usual. From that starting point we see projects leave dock and either arrive at the next port or go horribly off course (a small number may return to dock when they discover the sea can’t be crossed). It’s a this point I really turn to Alistair Cockburn’s **Oath of non-allegiance**:

I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation.

There is a huge spectrum of people that state that their projects are Agile. Some are almost clerical in following what they percieve as the one true methodology. Others are extremely sloppy in terms of process but their team knows their users really well and they just get s**t done. Several are really just running a prioritised task list and use “Agile” as a method to avoid documenting anything, committing to anything or being responsible for anything. These last group really dilute the validity of the ideal and, unfortunately, when their project fails it’s often blamed on the agile approach - next time we’ll really need to micro-manage the team.

It’s important that we sometimes sit back and make sure we’re really being Agile and not just process-gazing. Those that claim to be agile should be checked for that claim and helped where they fall short. Some of my projects aren’t agile and I’m honest when I say we use aspects of agile methodology but I don’t claim the approach meets the agile manifesto. I also try to encourage the movement of those projects back to the agile path. However, I’m often a little perplexed when I use something like a use case template to help guide thinking and get told “use cases aren’t agile”. In further posts I want to explore why I think they (and other tools) are and why people have constructed some sort of checklist of what isn’t agile.