Archives for 20 Apr,2015

I have four kids ranging in age from 21 to 10. For some reason, people without children really like to give my wife and me advice on how to raise kids. Usually they will provide analogies using their favorite pet. Or they will tell me about their second cousin twice removed who “just had a baby”, and here’s what they plan on doing. I just politely nod and say “thank you”.

So what’s my point? I also tend to get a lot of advice regarding agile development and how it won’t work on certain projects. I’ve heard it won’t work on complex projects, big projects, geographically disperse projects, mission critical projects, non-software projects – you name it. Everyone who tells me this has either a) never worked on an agile project or b) worked with a poor implementation of agile.

Instead of politely nodding and saying “thank you for your advice” as when I’m given child-rearing advice, I’ve recently decided to politely challenge these ideas with questions such as:

“What experiences have led you to that belief?”

“Why can’t an offshore project implement agile methodologies?”

Below is a post that I saw on LinkedIn:

“As with any project management tool, it is situational. If, like in many software development environments, there are one or two key people involved in each and every task, Agile tends to break down. In this case, there are better methodologies to employ. Like any concept, I think the rub is that no technique fits all situations.“

This was written by someone who has clearly either never worked in an agile environment, or has suffered a poor implementation.

I responded:

“There is a very broad spectrum of agile methodologies out there to cover any situation. Being agile also means adapting the process to fit your needs as it’s an empirical inspect & adapt approach to managing projects. For instance, typically Scrum & XP are implemented together. Scrum only addresses project management practices, while XP addresses development practices.

The failed agile implementations I have seen were caused by one or more of the following:

The team is not empowered and self-organizing.

Team members are working on too many projects, resulting in excessive context switching.

Management is committed to command and control (related to #1).

The customer or customer representative is not involved.

Processes are not allowed to evolve.

There is no dedicated product owner, i.e. someone responsible for the ROI that the team can go to (getting rid of the multiple boss syndrome).

Those leading the agile implementation have not been properly trained in agile.

Agile breaks down when the organization is not ready to accept its principles. If the organization is not willing to change from command and control to servant leadership, empower the team, assign one product owner, and get the customer involved, then it will fail.“

If you feel that agile just won’t work on _____, I encourage you to find out for yourself. There are plenty of cases where agile has worked on huge, complex, mission-critical projects.

Below are some examples of successful agile implementations where I’m sure many would have said “agile won’t work”: