Deprecated: Function set_magic_quotes_runtime() is deprecated in /home/raedan/public_html/textpattern/lib/txplib_db.php on line 14
State of Flow: Agile Anti-Patterns - What's the Problem?::journal

Agile Anti-Patterns - What's the Problem?

Lance Walton - Monday January 23, 2006

This article, the first in a series, is about the submersion of analysis under a sea of user-stories when the team fails to separate problem from solution, as is apt to happen when a team first adopts an Agile Method.

This is the first article in an intended series on ‘failure modes in the implementation of Agile Methods’. It is about the submersion of analysis under a sea of user-stories when the team fails to separate problem from solution.

To fully understand the issue, it is necessary to make a sharp distinction between analysis and specification.

The concerns of analysis are all located in the problem domain. This has nothing to do with any solution that might be proposed. Instead it has to do with the essential work of the external actors. Additionally, as Jackson points out in Problem Frames: Analyzing and Structuring Software Development Problems (amazon.co.uk amazon.com), it may well extend beyond those who are eagerly waiting to work at the interface of the system to be incarnated. Analysis is often difficult since it involves people and tacit processes that may be so deeply internalised that those people are not able to easily elucidate what they do.

Specification, on the other hand, is concerned with prescribing a solution to the problem at a chosen level of detail. Specifications can be represented as numbered statements, each of which is testable, traceable and many other ’-ables’, as preferred by many advocates of the Waterfall Model. They can also be represented as user stories, or use-cases, at whatever level of detail seems appropriate, as preferred by advocates of XP or RUP, for example. Specification is often difficult since, amongst other things, it involves choices, delineation, trade-offs and some degree of precision.

This all seems clear but it is easy for discussions to start with the implicit or explicit intent to analyse but to rapidly move instead to specification. The result is no advance in the understanding of the problem. However, the seductive illusion of a concrete decision about something numbs everyone to that fact.

It seems that this is particularly apt to happen when a team first adopts an Agile Method. Being freshly liberated from the need to write a large requirements specification document, it is easy to forget that what was behind the requirements specification was an analysis of the problem. Because implementation can proceed almost immediately, analysis activities are replaced by creation and implementation of superficially conceived user-stories, or their equivalents.

I am not suggesting that months of analysis should occur before a single user-story or line of code is written. All that is needed is to remember that adding a new feature is all well and good but that feature exists in a context. Maybe if the context was better understood, the feature would be different or may not be needed at all. The mechanism for understanding the context is not to suggest or implement one possible solution after another but to ask the user ‘What’s the problem?’ and then take the time to listen.