We can’t do Agile.

Over the years, I’ve heard many variations of “we can’t do Agile”:

Agile doesn’t allow for proper thoughtful design.
Our project \ organization is too big to do Agile.
Agile is really just a dev thing.
Agile just isn’t reality.

I realize that behind every single “we can’t do Agile” statement, there’s a story. My intent here isn’t to delve into the stories of Agile woe… rather, I would like to open a small crack for the “we can’t do Agile” crowd.


1. Have you ever stopped yourself from sending an email, and instead decided to walk over and have a conversation with a team mate?

2. Have you ever argued to make the right fix on your project, even if it went against the requirements \ spec document?

3. Have you ever sought out feedback from your customer or end user in order validate your understanding of a project?

4. Have you ever adjusted your project plan in light of new feedback (user based or technological)?

If you answered yes to any of these questions, then you successfully “did Agile”! Consider the values of Agile below and review the questions above again respectively…

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Viewed in the light of Agile values, many teams are already adopting Agile methods… albeit implicitly. Embracing these values in a more explicit fashion opens a door of possibilities… among these possibilities would be to let go of the idea that “we can’t do Agile”.

In Defence of Waterfall…

I recently put together a whiteboard presentation that gives an overview of 6 different software development methodologies (Waterfall, XP, Scrum, Agile Manifesto, Lean and Kanban). I started with the grand-daddy of all the methods… Waterfall.

I’m glad that I did… because doing so reaffirmed for me that Waterfall, like most software methodologies, is often misunderstood.

I want to be clear. The whole document maintenance nightmare, lack of customer feedback, hard core linear process of Waterfall is indeed still part of Waterfall. But viewing it in the historical context of the 1970s, I came to realize some of the honourable goals behind the Waterfall process. As a developer, I had to imagine a time where writing and compiling code could be extremely time consuming and costly to do. Suddenly, trying to sort out as many details before writing a single line of code started to make sense.

So when you look at a particular software development methodology, it may be worth taking into account what motivated it’s creators within their historical context. Doing so can allow you to let go of the parts that don’t necessarily fit within your own context and perhaps extract what is still meaningful for you.

Coming back to Waterfall, I extracted a few things that I think are still relevant to me today. Software development requires discipline in order to be effective and (however tempting it may be to do so) we should be careful not to skip steps in order to speed ahead. That being said, which steps are meaningful to you… well… that all depends on your context.