Bridging the Unknown
This article has been previously published in the Coaches’ Corner section of issue 3 (Spring 2017) of AgileVox, the magazine published by the Scrum Alliance.
In the climax of Indiana Jones and the Last Crusade, Indiana Jones follows three clues that lead him to the Holy Grail. One of those cluse implores him to “leap from the lion‘s head.” Faced with a deep, wide chasm – with a lion’s head on one side and empty space ahead – he must step into the unknown. In leaping from the lion’s head he suddendly finds himself standing on an invisible bridge crossing the chasm.
My intent is not to say that Agile is a leap of faith or that you must cast everything you know aside and jump into the unknown. The role of Indiana Jones is for the pioneers who first bring Agile into your organization. They deserve the credit: Whips and cool hats must be passed around.
Those that follow may have a lesser task, but a daunting one nonetheless. In the movie, Indiana Jones throws a handful of gravel and dirt onto the bridge, making it visible and easier to cross. But crossing still takes nerve, and his companions don’t simply stride across the narrow bridge. They take small steps and continually reassure themselves that the bridge is real, if hard to see.
In an Agile transformation, those small steps are iterations or sprints, and the reassuring inspections of the bridge are the regular reviews of working product, or increments. These are not random practices; they are necessary for everyone, from managers to teams, to reassure themselves that the path being followed is trustworthy. While your company’s Indianas have identified the path to agility, your leaders and teams still require continual reassurance as the path is trodden over and over again.
The way we achieve this is paradoxical. We shorten feedback – a lot. That is, instead of keeping sprint lengths longer so that teams are able to gain experience delivering in four-week, then three-week, then two-week cycles, we encourage them to take a (small) leap of their won, going immediately to one to two weeks.
Shortening the sprint length alone isn‘t enough, though. We also need to help teams deliver working product – an increment of functionality, however small and inconsequential, that the team feels confident can be released then and there. Make this simple. Encourage teams to keep their sprints as short as they dare, and then take the smallest amount of work they feel confident they can deliver in a single sprint. If they try and fail, get them to deliver even less, but help them make what they do deliver shippable.
We know why this works. Every complete sprint allows the team to learn and adapt their ways of working. The shorter the sprint, the more opportunities to learn and adapt. However, learning is only possible when there is something tangible to inspect at the end of a sprint. Something that is complete and ready to go live allows the team to learn about all aspects of the way they work. And management gains confidence in how Agile works, turning their attention from the mechanics to the results.
An interesting thing happens as work is delivered at the end of each sprint. Teams learn and adapt, making changes that make the next piece of work easier to complete. Taking small steps and delivering shippable product creates a virtuous cycle. The leap becomes a careful crossing of a barely visible bridge, which quickly becomes a saunter across a well-traversed one.
Still from “Indiana Jones and the Last Crusade”, © 1989 Lucasfilm Ltd.