19 February 2008


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.

5 February 2008

Abandon Hope!

In a meeting at a client today, a developer was giving a status update. He mentioned that he hoped to have something completed by the end of this week.

He hoped.

I've joked with colleagues before that there is simply no place for hope in the software development industry. When I said it, I meant "hope" in the "abandon hope all ye who enter here" sense, but when I thought about it, though, there really should be no "hope" in software development.

Progress should be based on reality, i.e Yesterday's Weather, and not on some optimistic, rose-coloured glasses view of what could be if the planets all align correctly. Software developers, their management, their families, pets and minor acquaintances are all notoriously optimistic when estimating how long it will take to accomplish a task. Therefore, when estimating, we need to draw upon experience and a proven track record. Where there is uncertainty, use a Spike to gather enough information to be able to provide an estimate that's devoid of hope, and full of evidence!

The developer could have said, "At my current pace, I will be done by the end of the week", or, "Without any other distractions, I will be done by the end of the week". Even better, he could have said, "The last time I did something like this [or this size], it took me 3 days. So, I should be done by the end of the week."

Semantics? I think not.