“How Agile Fails in Practice” and Other Foibles

Every one of the ideas behind Agile Makes darn good sense, but I have never seen things work the way one would like.

In the article ‘How Agile Fails in Practice’, Sam Redmond quite eloquently points out some of the failings of Agile. But I think the article itself fails toward the end where the author starts talking about how things should be better for developers than “the business”. That artificial divide between the techies and the rest of the organization is *exactly* why methodologies like Agile seem appealing.

I don’t believe there is any mention in Agile of ensuring connection to the strategy and metrics that matter to the organization. Too often great expense and effort is expended you build software which works counter to the true goals of the organization. This is most often the case due to things like office politics, misguided fiefdoms, badly allocated budgets, etc. No matter what the organization’s strategy and goals are, there are [almost] always people in the middle; messy people who are motivated by ambition, fear, altruism, greed, and many other things which work counter to the strategy and collective goals of the organization. (There are exceptions to everything, but in my 35+ years of working – many as a consultant who gets to go into organisations, help them accomplish something, and leave – this is the common state.)

At Sympraxis Consulting, we believe strongly in being agile – note the small “a”. With most “modern” software development, we don’t know exactly what the end result will look like when we start, and that IS A GOOD THING. Agile is one methodology which tries to acknowledge that truth, but in my experience, it rarely succeeds in addressing it.

I won’t rehash the specific points in Sam’s article, but one of the main ones is the internal inconsistencies within Agile’s basic tenets. When I’ve worked with people who pretend (yes, I chose that word intentionally) to follow the Agile methodology, I more often see an inflexible adherence to the methodology itself, and NOT adherence to the desired result, which is better software and happier end users.

End users won’t always be happy, anyway, though there is no reason for them not to be if we build good software for them.
 We can only own that part of the process, though to me a great developer is also great at customer service, listening, mentoring, and a lot of other “fuzzy” things that have nothing to do with software itself. Good software gets built by truly understanding why someone needs it, along with why they think they want it.

We live in an age where business processes are highly fluid and change all the time. Trying to document a fixed state of reality to build toward means we end up with a solution that may be ideal – for a time in the past.
 Every observed process is a changed process – again a good thing. As we work with end users to understand what will make them more successful in their daily work, we *always* end up changing how that work gets done. It may simply be new ideas we bring to the table as outside consultants, or it may be that the people doing the work have never really thought enough about how they might do things in a different way to reach more successful results.

I believe we should never follow any proscribed methodology blindly when we work on a project of any kind, not just software development. All methodologies have some good ideas and some less good ideas. We should cherry pick ideas from a wide range of disciplines to ensure success. 

When it comes right down to it, projects in the Information Age are all about people, not software. We aren’t usually building mission critical applications which get burned into chips and can’t be changed without huge expense. People change, processes change, technology changes; we have to look at every software development project as a part of organizational evolution which began before the project starts and continues after the project ends. Good software is never “done”. It keeps moving forward as the needs of the organization move forward.

If you’re an Agile shop, you should definitely read Sam’s article. Then think long and hard about whether the the way you are using Agile is actually making you better at what you do. Most importantly: are you better at what your organization needs you to do.