Agile traveling

This post is inspired by The Magic Suitcase article by Francesco Cirillo, on the value on searching the simplest (and lighter) solution over adding weight and force to bring a project forward; I experienced a similar analogy between traveling and Agile planning.

The context

The Onebip team was (in part) in Rome, for the Christmas party of our company. After the party, we had a sort of "free" day since we could return to Milan at any time (it's a 3-hour trip). Thus we decided to visit Rome, one of the most famous and ancient cities in the world.

However, we had no real time for planning our visit to Rome's landmarks, as it had been a busy week trying to close the last tickets and setting up vacation times for most of us while rotating to monitor the production systems.

We had a minimal plan, a path that our CTO explained to us during the party: two or three places stringed next to each other and reachable by foot (Colosseum, Trevi Fountain, Pantheon). So the only planned next step on that morning was to go towards them.

In the face of uncertainty, in this case Rome's mass transit system, it's difficult to plan much in advance. In fact, at 9 am the B subway line completely stopped, leaving us 3 kilometers from the start of our tour at Coliseum. Any detailed plan containing time slots would have gone out of the window.

The backlog

In the case of a project managed with Scrum, there is a product backlog containing features that can be estimated in value and in the effort necessary for their development. The backlog of Rome tour was instead a list of places and landmarks we wanted to see.

There is a big difference between a tour backlog and a product backlog however: it would be difficult to model many of the places to pass through as independent. While features are splitted in user stories in Scrum, you cannot really consider the cost (in time) to go to different places by foot as only depending on where they are, since it depends on the path you have chosen and where you are at the time.

Iterations

With these difficulties in planning, the one-piece flow comes to mind: just plan the next item to bring from inception to completion. In our case, just plan the next place to visit, leaving options open to decide the further ones at the last responsible moment.

When the subway stopped (for good) at Garbatella, we planned to cover the 3 kilometers to Coliseum by foot, without knowing what we would do next. Not being knowledgeable on other transportations, we only had the subway and walking options.

We didn't commit to visit other locations at the time. Not even lunch was set for a predefined time, something that is standard during trips. :)

Iterating over locations came very natural because of the time box we were moving in: train and plane tickets were already bought and checked-in, so the problem was essentially the maximization of what we could see (scope) in a fixed lenght of time, our only "release".

The last responsible moment concept helps keeping minds open about our choices, not straining ourselves on one location (feature) despite increasing costs and a changing context. For example, we decided to go to the Vatican just after arriving at the Tiber river, not knowing if there would be time for that as it was the only location situated in the western zone of Rome. We postponed the decision until it was accessible at an acceptable cost, and we would never have gone there if it would have meant losing the train.

Does this remind you of death marches towards features and of missing deadlines?

Cost vs. value

When continuously evaluating the next step, it's crucial to be able to estimate the cost of a choice (visit Vatican with respect to the Trevi Fountain); the value of the places usually stay pretty constant throughout the day, while the cost varies basing on your current location and how much you're tired.
The members of a tour can estimate this value, for example basing on the Kano model :

• what you want to absolutely see: the Coliseum.
• other "linear" locations to pass from (the more the better): Piazza Navona.
• not important things: enter the Vatican.

Tools support

Google Maps, and smartphones in general as guides are essential tools in Agile traveling. The Agile movement rightly considers more important people and interactions over processes and tools, but there is a baseline of tools which enable a process to work.

For example, try working with slow machines and you'll cripple the Agile practices that provide feeback. Try test-driven development in the 60s, when compilations were performed during the night and program entered with punched cards. Try pair programming without adequate space organization and monitors and you'll get backache.

The costs and risks

Like the magic suitcase metaphor tells us, a large risk in this trip is the weight of the suitcase or backpack you're carrying: I got a severe backache due to the 20+ kilometers of walking during the day. A smaller backpack would have reduced the cost per kilometer, making us even faster in moving throughout the city.

This approach also sacrifices maximum time efficiency: you're always going towards the best value/cost alternative, while a preplanned trip may lets you see more things. However, if a single bus or train breaks during your plan execution, you're going to have a rough time keeping up with it.

There are also costs related to tools: the 3G Internet access to get directions and estimate walking times, and the need for reloading the batteries of smartphones. This reminds of buying monitors, machines or services like Saucelabs: sound investments to increase visibility and feedback, but not free ones as the focus on people and interactions would make you believe.

Conclusions

Traveling and visiting a city is a helpful metaphor for explaining Agile methods. It's also a way to apply the same principles of feedback, planning, estimation that we use every day to a different domain to see what stay the same and what is influenced by the domain instead. Consider the assumption of independence of stories and why it is important for deciding what goes into a release: during a walking tour, your options for the next choice are much more limited.

As another example, let's think about what happends when the people doing the work are also the users (in traveling); how can you set up a product owner which is representative of all? On the other hand, "customer" collaboration is also greatly simplified...