Archives for December 2012

As you get to the end of the year, it can be natural to think about the roadmap for following year. What will 2013 bring? What are the goals and KPIs?

I was in such a meeting discussing the roadmap when someone mentioned a weather report. That got me thinking. Roadmaps and software delivery plans are very much like weather forecasts.

All you know for sure is the current weather. It is raining outside is equivalent not to the state of your issue tracker, but of the running product.

As soon as you go forward in time you are guessing, so don’t kid yourself. You may have a good idea on what will be done in a sprint, in the same way that the 5 day forecast can be pretty good.

In software there are also multiple glimpses into the future via the branches that you have going. That pull request from Bob that adds featureX is one example of a future peak at when you go through a code review and probably eventually merge it into master, or a release branch.

Although there is an inverse relationship between the delta in time from now and the likelihood of the forecast is correct, that doesn’t mean it isn’t worth doing. We still use long range forecasts, but they are different types of measuring sticks. For example, you may want to ask

“I want to go to Costa Rica in February, what is the weather likely to be like then?”

You can statistically have a view point. On the software side you can get good at measuring a) your team, b) scope, and c) the risks in the project. This shouldn’t be confused with “knowing”. In fact, it isn’t worth going into intricate detail on each item and scoping it out for the next year to get a conclusion, as that is only one reality that you are mapping (this is why I prefer LiquidPlanning for this kind of work btw, to get a model vs. one path). You care more about the trends.

So, the next time someone asks you for a year long roadmap, maybe show how the probability changes over time and making it crystal clear how you are playing the role of a meteorologist.

Playing with the English language can be fun. Do you remember when Jack Dorsey banned banned the term ‘users’ from the Square work place?

There was a discussion around the coupling of “drug users” to your clients/customers. I have heard of some folk who want to blanket-change the term at their work place too.

That view may be throwing the baby out with the bath water though. There are many terms that can have a subset usage that is something society may think of as “bad”. In the drug realm itself there are many. Should chemists not use the term ‘acid’?

If you look at the term “customer” you can see it as:

One that purchases a commodity or service

Great, that may fit the bill nicely. For Square this indeed can fit in very nicely indeed, which is why Jack may have opted for it there compared to Twitter, where there are many users who do not purchase a thing.

Now take a look at the word user again. What if you think of it as:

One who gets use of a commodity or service

I get a lot of use out of Twitter. Building something that people get use of seems pretty compelling to me, so don’t rush to kick out your users.