Pragmatic Agile Weblog

Agile software development in real life

The decline of agile or need of a pragmatic approach to agile?

Recently, a number of interesting posts has shaken the tranquil days of the agile movement. Two remarkable ones are:

Of the two the most interesting is the first one by James Shore co-author of “The art of agile development” and agile trainer and consultant.

I would summarize the post with this paragraph:

“Now many people who call me already have Agile in place (they say), but they’re struggling. They’re having trouble meeting their iteration commitments, they’re experiencing a lot of technical debt, and testing takes too long. So they hire me to help them with one of these things. When I go visit, I see a team that is nominally agile, but is suffering huge numbers of problems and is anything but the joyful, settled, smooth-running workplace I expect from an agile organization.”

I think the most interesting information in the article is that he is experiencing that many teams in the real world are failing in applying agile principles and practices. I find it interesting because I believe it is related with the essence of this blog. The author presents his frustration in seeing teams defining themself “agile” and then failing in applying the most basic practices. I must say I am not surprised. I am not surprised because I know what turning a team from a more traditional software development model to a more evolutive and incremental development model means.

But this is not the most important point, for what my opinion counts. I believe that what is happening is not the decline of agile, but that it is entering his maturity. More and more organizations are adopting or are willing to adopt agile practices and therefore those practices are now challenged by the variety of real world environments. Many thinks and tell you that once you learn the agile manifest you can go back to your office and change everything in a blink. In too many occasions I heard people telling me that in order for agile practices to work, you first need A+B+C… in other words, it is too easy to assume that you can start always from the optimal conditions (you have the best and skilled team, very agile-motivated, all co-located, all willing to develop in pair, etc, etc)… what does it happen then if some of these conditions are not met? Shouldn’t agile techniques be pragmatic by definition and therefore allowing to face changes? I believe they should! Why then this is not happening?

My explanation is that there is the tendency to make of the agile methodology an ideal model, that guarantees brilliant results, once all the preconditions are met. But it is very difficult to find such preconditions all met in real world teams. The risk I see is that we replace an ideal model, the waterfall, with another ideal model, the agile. The waterfall is not applicable as it is in real environments because in the majority of the cases you cannot snapshot at time 0 the requirements, the design, the code, and so on and then hope that nothing changes. What happens if we build a methodology that requires so many things to happen at the same time all depending by each other and then one or some of the prerequisites are not met. All the methodology falls apart exactly like waterfall.

This is why it is fundamental that agile keeps its pragmatic nature. And I believe agile does so if accepts to face the issues of real world teams, without necessarily asking them to change everything and in once. I believe agile does so if accepts to face the business aspects that real world teams face every day (a co-located team can be simply not an option from a business perspective!). I believe agile does so if accepts the challenge to scale in size and in time. But most of all, I believe agile does so if instead of being considered a goal to achieve, it becomes a tool to improve quality and efficiency.

There is a risk, though, that we should avoid as much as possible. Pragmatism can sometimes hide the forces that resist to changes. Be pragmatic must be a way to improve things in a controlled way, taking calculated risks and being honest with yourself about your team. It cannot be the escuse to always find a reason why things should not change.


November 23, 2008 - Posted by | Funambol, SCRUM, Software engineering

1 Comment »

  1. Pay attention you may be considered as heretic by those who say ‘You didn’t apply agile manifesto’s rules stricly and well so don’t complain about your bad results’ and dimishing your assumptions with the comparison: ‘We tried baseball and it didn’t work’.
    I strongly agree that whatever development process is adopted, it has to improve the development and its results. Knowledge and evaluation are the pillars in any choice you do. Learn any process principles and implement whatsoever fit with your needs. That’s my way, be pragmatic.

    Comment by Giancarlo Frison | November 25, 2008 | Reply

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: