Agile Management

Agile Management (3)

Thursday, 14 February 2013 21:01

The Kamikaze Agile Pilot

Written by Fernando Santiago

 chickenpilot

 

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.

 

swns_ikea_monkey 

 

A week ago we all went bananas about a cute monkey wearing a winter coat and wandering into an IKEA store in Toronto. The image was cute, unexpected, so it captured everyone’s attention. Darwin, the monkey, was taken to a sanctuary for monkeys, heated of course, so the coat and diapers were removed leaving just a plain monkey, no different than the others in the cage; it never was.

Similarly, many companies have adopted agile and have no problem in applying many of the visible rituals, so you find walls covered with sticky notes, stand-up meetings with people rolling their eyes back (ok, not always). However, under the covers, software is being designed, developed and tested the same way they did before.

One of the main reasons for this limitation in extending the scope of agile practices is forcing agile into projects better suited for other approaches, or for a combined approach that may include agile. Particularly larger projects tend to have components that do not mix well with agile. Instead of defining a delivery strategy for the project that could include agile, incremental and even waterfall; the whole scope is forced through the same approach.

Agile is for projects that are difficult to predict, highly volatile in requirements, solution and technology, things we cannot plan upfront. Under these conditions, floating scope not only makes sense, but is the only sensible thing to do. However, floating scope remains the ultimate frontier when it comes to agile adoption because it reverses the way we think about projects. In a traditional approach, we start with scope as the independent variable, and the capability of our process determines time, cost and quality. In floating scope it is the exact opposite: we start with fixed time, cost and quality, and the capability of our process determines how much scope we can cover. Scary, uh?

One of the reasons behind the difficulty in applying floating scope is when agile is forced to projects that are predictable, stable, non-volatile, even legislated, where floating scope cannot be applied.  The second major reason is that floating scope requires a deeper understanding of agile, beyond the rituals and paraphernalia. Furthermore, this understanding is needed not only by the delivery organization, but also by the sponsor and other key stakeholders that are usually too busy to attend an awareness session, including a PMO that still needs status reports and measure of progress (which can be done with the right tools). Here, the basics of organizational change management come into play.

Agile is not just chickens and pigs, but it should not become a monkey under a winter coat either: cute but still a monkey.

standup

 

Agile is not about rituals; it is about developing software differently

In too many organizations that have adopted agile you can see walls covered with sticky cards, stand-up meetings and even pictures of pigs and chickens. However, beyond the rituals, software is being designed and developed exactly the same way as before. Agile methods have been around since the nineties, and after twenty years in the process of adoption most organizations are still scratching the surface. This is not unique to agile; adoption of innovation has always been this way, as human nature is to resist change; we welcome new technologies, ideas and gadgets, as long as we can use them to do what we do mostly the same way. In the past it took several generations for innovation to generate change. Today, with the acceleration of technology, it may take just a few years, but it doesn’t happen instantly.

Adoption of agile in organizations is a process that needs to be understood. The first generation of projects will likely stay on the surface of rituals and tools. Practices like collocation, full allocation, stand-up meetings, etc; can be done even when using a waterfall approach, so they are comfortable. In order to move to deeper waters, teams have to embrace agile practices that can act as triggers for change. One of these practices is “time-boxing” and another one is “quality is non-negotiable”. When these two practices are combined, teams are forced to think differently. When the team knows that the iteration will not be extended, that overtime will not be approved, and that stories with defects will go back to the backlog and that the demo with the sponsor and stakeholders will not be pleasant, things start to change.

Floating scope is probably the practice that has the highest potential to trigger change. On one hand, it reverses the logic for managing projects, with scope being the dependent variable. On the other hand, it requires trust between the delivery organization and the customer organization. Trust that the team will deliver a solution that is capable of realizing the benefits that justified the project, in the time and cost expected and with top quality. When there is a relationship of trust between the project and key stakeholders, this start to permeate down to the team, and allow agile practices to turn a platoon into a self-managed team of smart people that need less direction and more space to deliver high quality solutions.