Almost every organization that explores the transition from waterfall to agile uses the approach of a pilot project which, in many cases, turns into a “kamikaze” operation, doomed by design.
For those who don’t know the term, “kamikaze” pilots were used by Japan in the Second World War to slam their planes, loaded with explosives, into enemy ships. The most famous kamikaze pilot was also a renowned cook in the Imperial Navy, Cpt. Yoshiro Teriyaki, who invented the famous sauce so popular today. He was sent on a kamikaze mission and right before hitting the ship he pulled the plane’s nose and aborted the crash. After that date, he was called “Chicken Teriyaki”. Gotcha!
OK, now it’s serious. The pilot project for implementing agile has many reasons to ensure failure:
- The organization is not ready for supporting an agile project, and is waiting for the results of the pilot project to change. There we go with the chicken again, or the egg.
- The team will likely receive little or no training: just behave radically different, starting tomorrow. Sure, it’s going to happen.
- The tools are not in place, so the team has to invent them, and they have no knowledge or time to do it properly.
- Barriers start to mount, and there is no defined role or group accountable for removing them
- Expectations for delivering faster, cheaper and better will not likely be met because the pilot will not go deep enough into agile. To play safe, they will stay on the surface and just play along with the rituals of stand-ups, sticky notes, chickens (yet again) and pigs; so little or no benefits can be expected to meet such high expectations.
- The pilot will not likely get into how the software is designed, developed and tested. The project management life cycle may look agile, but the SDLC will likely be more of the same, so expect little or no benefits.
At some point, the project manager or scrum master and maybe the sponsor too have to choose between changing the organization and delivering the project. They will likely choose delivering the project, because there may still be some chance of success and it is known territory. Now the pilot has crashed, the project may be salvaged.
To avoid the “kamikaze” pilot project, a few recommendations come from common sense:
- Separate the accountability of transforming the organization and assign it to an individual or team that is not the project manager or project team. Consider a Sponsor for the Agile Transformation and an Agile Transition Team or something like this, with representatives from the PMO, SDLC and the business. This team’s main responsibility is to remove barriers for the pilot project, provide tools, adjust processes, etc.
- Set proper expectations with all stakeholders for the results of the pilot project. It is just the first step in a transition process, so don’t expect supernatural results.
- Educate, educate, educate. Not only team members, but all stakeholders, should be trained in understanding agile and how it works. Don’t forget Finance and the business. This should never be just an IT initiative. And training should not stop at the classroom; a combination of training and on-the-job coaching is needed to ensure the pilot succeeds.
- Choose the right project, and the right team. Not every project lends itself to agile, and the selection of the pilot project should be carefully done. Similarly, choose the right people for the team, as agile is not for everyone.
Despite the fact that many organizations have taken the risky route of a pilot project to implement agile, this approach has become mainstream today. The evidence that, when applied to the right projects, agile works is so overwhelming, that the failure of a pilot project is not enough to stop the winds of change.
