I have four kids ranging from 15 to 3. For some reason, people with no kids really like to give my wife and I 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 the point? Well, I tend to get a lot of advice, or "words of wisdom" 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 challenge these ideas. Of course not in a confrontational way, but just in an inquisitive way. "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 is clearly someone providing advice on agile development that clearly has never worked in an agile environment, or has suffered a poor implementation. I couldn't resist responding. Below is my post.
"There is a very broad spectrum of agile methodologies out there that will 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 issues, while XP addresses development issues.
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).
- The ones leading the agile implementation have not been properly trained in agile.
So, agile breaks down when the organization is not ready to accept its principles. If the organization is not willing to change from command & control to servant leadership, empower the team, assign ONE product owner, and get the customer involved, then it will fail."
Hopefully I didn't come off as a jerk on this. I just couldn't resist.
If you feel that agile just won't work on _____, I encourage you to find out for yourself. There are plenty of cases where it has worked on huge, complex, mission critical projects.
3 comments:
Good post. There is no point hypothesizing whether agile will work or not in a given situation. The best thing to do is to actually implement it and see what happens. One thing I don't quite agree with:
"Everyone who tells me this has either a) ... b) worked with a poor implementation of agile."
Yes, I do agree partly, but IMHO thats not a valid reason.
It's easy to say it failed because of a poor implementation, because *by definition* a good implementation is the one that didn't fail.
The second question is what exactly is 'good' implementation of agile? If you don't do XYZ practice (TDD for example), some people will say that you aren't doing agile (or XP or Scrum) anymore. If you DO do XYZ practice and it doesn't work, then some people will say you aren't adapting the process to the situation. There is a convenient excuse either way - both of which get thrown around in the mailing lists as the situation demands :)
I can see where you are coming from though. There are projects out there that they don't do a retrospective at all ("we adapted the process") and unsurprisingly, many of them fail.
I'm reminded of this quote from Corey Ladas.
Very good point. I think I'd define a poor implementation as one where most of the team does not understand and/or accept agile (and lean) principles. And a good implementation is the opposite, they DO understand the values and principles. I've seen teams execute all the techniques, but without the values behind them, they were meaningless and a waste of time.
If the team understands and accepts the principles, then they will succeed (unless there are organizational impediments that just can be surmounted). They will need to do that retrospective so they can improve, they will be inspired to collaborate, they won't be able to resist finding and eliminating waste, etc. It will be like a virus (a good one).
I meant to say "unless there are organizational impediments that just can't be surmounted". Funny how just a couple of characters can change the meaning :-)
Post a Comment