Be Agile When You Go Agile

There are many sides to business travel. After 10+ years most of the excitement is gone and I certainly have no love for the kind of agility that is required when climbing over sleeping passengers in ever more tightly packed economy seats. However there are two aspects of business travel, especially on the long haul flights, I still enjoy. One is the hours without any inflow of e-mails or other communication. After spending the first hour clearing out the mail box to create peace of mind I can literally feel my brain shifting from input processing to reflection, analysis and true understanding. I love it! The second thing I really enjoy is the chance encounter with an interesting person.

On my way to IFS development center in Colombo, Sri Lanka the other week I ended up next to bald middle aged lady wearing a turban. Before we had even taken off she had managed to have conversations with three members of the flight crew, including a nice Swedish chap who recognized her and spoke with her as if they were friends. This will make for an interesting few hours I thought, and sure it did.

Turned out she was professional trainer for Project Management Institute (PMI) on her way to Qatar to train project managers in an oil company. With her many years of training high level international project managers in IT, pharmaceuticals, and oil & gas, and IFS recently having rolled out a new agile project methodology in all our development projects, project management became the topic of discussion. This of course after she had told me why she lost her hair, about peoples reactions to her wearing a turban, and what she loved about night safaris in the desert.

After briefly describing the work we have done in IFS over recent years to move to Agile development methodology, I asked what her top advice would be for how we continue from here. Her response was quick and clear, and the same advice she gives to most organizations.

1. Don’t think that one single methodology fits all projects, because there are many different types of projects. For example Agile methodologies may work well for many development projects, but for say a project to implement a set of legal requirements by a fixed date (if for example the new laws come into effect on 1 January) a traditional water fall method with more up-front planning is often a lower risk approach. And innovation projects striving to create new markets or products might need something completely different.
2. Before you start a project, make 100% clear what the end goal is, and how you will measure and follow up that the project is on its way to reach that goal. She told a classic example of an oil company that spent many years and billions of dollars to drilling for oil. When they eventually found a tiny amount of oil, too little to be worth extracting, they cheered and declared the project a huge success. Why? The goal was never to extract a lot of oil – it was to develop horizontal drilling techniques.
3. Review your project portfolio regularly. Just because a project was allowed to start it is not a given that it should be allowed to finish. Even if the project is half way, perhaps there is another project that would be more beneficial to run? In her opinion the rest of us have a lot to learn from the pharmaceutical industry (where only a few percent of projects are allowed to finish) when it comes to commercially managing a project portfolio.

Although this advice might seem obvious, it is easy to forget. Just looking to myself I can admit that we have not always been defining clear goals for the projects we run in IFS Labs (although we are very good at killing struggling Labs projects in favor of more important ones). We also recently had a discussion in our management team about whether we should push for stricter adherence in all project to our documented way of doing Agile development. I am pleased we decided to allow the projects a high degree of flexibility in how they apply the methodology. At the next opportunity I think we should discuss whether we should indeed use Agile in all projects, or if there are some project better served by other methods. Agile development has created great results for us, but it doesn’t mean that it automatically is the best approach every single time. Perhaps we should be agile in how we apply agile?

I am writing this post on a flight from UK to Sweden and reading in SAS’s in-flight magazine that they will soon equip their aircrafts with WiFi and cell phone coverage. Seems like we are about to lose one of our last oasis for thought and insight.

And to the lady in the turban…. Denise – if you are reading this, thank you again for a memorable meeting and your sparkling personality.