19 February 2008

Disillusionment

Scott Ambler of IBM was here in Ottawa last week, and I had the opportunity to chat with him over dinner before he spoke to the Agile Ottawa group. Our conversation triggered a lot of thoughts on my part about the state of Agile Software Development, and certainly my place in it after over 7 years as a practitioner.

Perhaps it's owing to my work in the federal public sector, but over the past couple of years I find that I have become somewhat disillusioned with Agile Software Development, or more appropriately its widespread adoption.

Many of us have experienced tactical-level success with some form of Agile. That success may even have been quite significant, but I question whether it's sustainable. Is the success a function of the process or the people who implemented the process? If key people who drove the successful adoption move on, does the team still adhere to the agile method they had adopted? Even after a successful adoption of an agile method or methods, can that success be sustained within one group, let alone be propagated to the rest of an organization?

There will always be organizations that seem to get it with regards to being agile. That doesn't happen by accident, and you most likely will find that those organization have inspired leadership with people who, regardless of the software development process, can be considered agile.

The question remains, though, what about the other 95% of organizations in the world? Are they simply going to be left out in the cold? Will they jump on the latest buzzword bandwagon, only to abandon it when their results are less than expected? Will they spend thousands upon thousands of dollars to adopt this new way of building software, only to drop it when they discover that it requires at least as much effort and discipline as other more prescriptive processes?

In the conversation I had with Scott, and in his presentation later, there was a lot of discussion about the notion that Agile has to "grow up". We can't rely on the shock factor of calling something Extreme Programming. We can't rely on the marketing hype of Scrum and the Scrum Master certification. We have to look beyond the clashing egos of the Agile thought leaders. The principles and practices behind Agile are sound, but they do need to be more realistic about the world in order to be usable in a practical sense. We can't always have co-located teams with a single on-site customer working on greenfield projects, as nice a scenario as that is. The myths surrounding the agile perspective on documentation and software architecture exist for a reason - we need to be explicit about their place in the agile world.

For me, the bottom line here is that Agile Software Development as a whole is in danger of becoming the next RUP... or RAD... or (insert favourite acronym here), doomed to relegation to the scrap heap of software processes. OK, so that's a bit harsh, but while we may have crossed the chasm, we may not like what we find on the other side.

4 comments:

Jason Yip said...

This is sort of why I'm annoyed by the "people over process" phrase leading to an emphasis on heroics and heroes rather than permanent, systemic improvement.

It's also why I'm preferring the Lean, or more specifically, Toyota ecosystem since it emphasises the complete transformation of an organisation, not just one aspect of it.

Jason Yip said...

And yet Lean transformation is just as spotty over the last 20 years and I think this article by Bob Emiliani gives us the answer why both Lean and Agile transformations don't stick:

http://www.superfactory.com/articles/Emiliani_respect_people_0208.htm

A lot of times, we're ignoring Respect for People.

Dave Rooney said...

I agree that respect is a core tenet of anything resembling agile. However, you can have too much of a good thing! Sometimes people need their butts kicked. Somethings they need to be coddled. There is no hard & fast rule to that, and I think it's human nature to want to be spoon-fed a hard & fast rule!

The gravitation towards prescriptive, process-centric methods is probably owing to that part of human nature as well. Too bad they don't work very well! :)

Jack Jones said...

Having just come out of failed project (large erp product), I have been looking at other methodolgies for, having previously adopted a V model, Agile seemed to appeal.

A few things I question, on site customer (unlikely) and lack of upfront, even architectural, design (especially if you have good picture of what the end product will demand).

Like all good processes you need to adapt it to your own culture and not try to follow it blindely.