Becoming agile

That’s the Waze, a-ha, a-ha

On virtually any trip I make by car, I open my GPS APP, Waze. I do this for a number of reasons: It’s social, it’s a learning experience, it is a good investment and, yes, it also helps me get there effectively and on time.

Such investments and learning opportunities are relevant for organization life as well. If you don’t make these opportunities, they will not happen on their own. Just the same way that if you don’t open Waze on every trip (longer than driving to the corner shop) you will not know if you are getting into heavy traffic or heavenly clear roads.

For those of you who are not familiar with Waze, it is a GPS mobile application that provides near-real-time data on traffic. The way it works, is that is collects data from active Wazers on the road, and uses it to calculate traffic speed. It also enables users to report on important events, such as obstacles on or near the road, weather alerts, police presence, and more.

So it is quite clear why it is social. It is also clear why it helps me get to places. The question remains what makes it a learning experience, and what makes it a good investment.

The learning comes from improving my ability to plan things ahead. I learn what routes are better at what days of the week and times of the day. Yes, I can also do it by recording the data myself. But by having some preliminary data at the start of the trip, and validating it as the trip unfolds, helps me make better judgments on the same trip and on subsequent trips. It also helps me realize ahead of time whether I need to make a decision – for example to call a client that I am going to be late or early.

The investment is in contributing continually to improving this near-real-time data. When I open-up Waze I provide this data to others, not only to myself. Likewise, other Wazers help me by merely using the service. In fact, one of the main reasons that I acquired a smart phone in the first place, is to be able to use Waze. That was an investment too.

As it turns out, not surprisingly, the closer I am to the target, the better the accuracy becomes. As someone once told me about product development: The longer it is, the harder it gets.

A long trip is not quite as predictable as a long trip:

Different routes have different speed characteristics and different slowdowns:

Indeed, these kinds of investments are true for other aspects of life, not only for using your smartphones.

It takes a lot of learning to understand that planning is not a one-off activity per release or per product version. It is something that takes place continually. The more planning you do, the more you understand whether you are going to meet your interim milestones (call them iterations, if you like).

It requires making investments in order to build the framework to gather data as you go in order to be able to do your planning: the short, and medium, and the long term.

When driving somewhere, it does not make much sense to look at the map, divide it leg by leg, and extrapolate how long it is going to take based on logic and common sense alone. It requires hard data, even inaccurate, but hard data, to do that.

In order to be able to create such a framework, you will need to learn how to start the project in the first place. How to create a contract with the customer that is not stifling into rigid plans. Such are agile contracts – a framework that helps two companies inspire one another, and not bind into unchangeable scope.

Alongside the contract with the client, you will need to learn which walls that exist within your own organization divert you from increasing the pace of making software. Where do you have ‘traffic jams’ that could be avoided by using another, simpler, route?

In order to do planning continually and effectively you want to be able to collect data about what the road looks like ahead? Where are the technical ‘traffic jams’ that you will meet along the way, and that maybe you can resolve before you get there? How do you measure them? Collecting data about your application’s complexity, and testing it continually provides such data, and provides early feedback, and to fix them before they become complete roadblocks.

The way you architect your product may also need to change. By looking at the map and guessing which parts will be slower you don’t get real data to make good decisions. You have to be out on the road in order to figure out whether your car can make it or not; whether the road is good enough or not. Good architectures are unfolding as you get more data collaboratively, and not by hoping for the best and then starting the journey too late.

And finally, I am sorry to break this to you – it is all about you. If you change, your organization will also change. If you provide others with tools that you can use on your own, maybe they will also change. Ultimately, whatever your role is, developer, tester, architect or CEO, you are responsible to make the change.

Are you the kind of person who waits for other to make all the changes on your behalf? Or are you holding the wheel of the car which is your own professional or personal life?

Agile Practitioners 2013 is a great opportunity to make such investments. Join us for the fantastic star cast we have gathered to make this investment a real learning experience for you and your organization.