Agile wont “fix” a project that’s already doomed


In talking to a prospective client a few days ago, we discussed 2 projects:
1. A project that was in the ‘ideation’ phase and was looking to inject some Agility into the execution.
2. A project that was already ‘in flight’ and looked like it was doomed for failure. The project sponsor for both projects wanted to see what opportunities there were to increase the performance of the team. The first project was a no brainer, and there was time to come in and coach the prospective Scrum Masters and Solution Owners.

The other project, on the other hand, sounded like a death march in play. The team and project manager were saying that ‘Under no circumstances do we have the time to take away from our current project plan and go toward a whole new way of execution.’ The project sponsor was thinking of putting her foot down and saying ‘THIS IS HOW WE ARE GOING TO DO THINGS, BECAUSE AGILE WILL MAKE US GO FASTER.”

I gave my project sponsor my opinion:

1.  Going faster is not the object of the team understanding how to become more Agile. Learning is the object.

When the team learns, then they will learn how to remove impediments and habits that are limiting their velocity. But attempting to steamroll ‘Agile’ down the throats of a team who is already under a critical deadline (that they most likely will not meet) won’t add any value to your situation.

2.  If the team feels like they have too much to do and not enough time to do it, then we need to have a conversation.

This is completely independent of Agile vs Waterfall vs Iterative vs Predictive vs Adaptive planning. Attempting to add Scrum to the mix will only highlight that the project manager/ultimate wringable neck for the project has short changed the team’s ability to execute based on capacity, but you already know that, so I don’t see the value add. Moreover, forcing them to change something at this stage will only serve to turn the ‘change’ into a scapegoat.

I tried to make a metaphor:

3.  The team is very good at walking, and for short periods of time, running.

I show up with a new tool called a ‘bike’ that will allow you to go further, faster, longer than you have before. Unfortunately, this tool requires learning in order for you to get the full benefit out of it. If you are in the middle of a race, where you are asked to go 500 miles in 5 days on foot, I already know that that distance in that time on foot is unrealistic, and that distance on a bike is unrealistic if you have never ridden a bike before. Even for the most advanced cyclists it would be a stretch. However, the team manager has insisted that the team needs to travel 500 miles in 5 days on foot. The team owner *knows* this is unrealistic, and is looking for a tool to help the team complete this race faster.

So me, the lowly bike trainer, is asked my opinion. Bike trainer says, “If the team is in the middle of the race that they are going to lose anyway, introducing a new tool that they don’t have the time to invest to learn how to use will only make the situation worse.” The team owner says, “but I thought bikes were supposed to make you go faster!?” I say, “yes, but only when you know how to ride it. It would not be a good idea to stop in the middle of a foot race and ask them to learn how to ride a bike, because they will blame the bike. A better option would be after the race do a lessons learned and understand what led them down the path. That type of reflection and feedback will start them on the path, and will make it easier to start learning to ride the bike.”

Anyway, sorry for the long winded meandering metaphor. I am positive others have come across this situation as well. What do you do when a panicked project sponsor calls ‘after the train has left the station’ looking for Agile to save their projects? If so, how did you handle it?

There was an issue loading your timed LeadBox™. Please check plugin settings.

Leave a Reply