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.
