I can still remember the moment.
I was sitting in an IT leadership meeting. The team was talking about the great variety of reporting tools we were using. The analysts were using MS Access, the programmers SQL Station, the Business Intelligence folks were using the Business Object front-end GUI Web Tool, and some business unit was trying to purchase Crystal Reports in order to do it's own thing.
I remember the moment, when the director of software development slammed his fist on the desk and growled "We need to standardize on one reporting tool, and we need to do it now!" (I believe he said something about "Amateur Hour", but I am not sure. This is a true story, and I don't want to embellish.)
It was a long time ago; I was a bushy-tailed young engineer, only present at the leadership meeting to discuss the progress on the Quality Assurance sub-committee, where I was the chairperson.
I wanted to ask "Why?"
So we have a little bit of redundancy in tools. So we need to cross-train some of our support folks, and have some inefficiencies when people transfer and need to learn a new skill.
Ok. So what?
We a few thousand a year really a critical priority for a 120+ person IT department? Didn't we have bigger projects, more important projects, more bet-the-farm projects to focus on, and other opportunities to save more time and money to look at?
For that matter, why now
? Couldn't we defer the decision a week, a month, a year, two years? What did it hurt to wait?
Of course, I didn't say any of this out loud. Remember, I was a young, easily influenced developer, scared for my job. If anything, my body language probably implied the same as everyone else "Those other people have got to get there stuff together."
Ten years later, I think I have learned a few things.
There is no Them
Blaming the other guy is a great posture to take; you get to be righteously indignant at the other guy and
you don't have to do anything!
By attributing blame to an outside group, you are also claiming the problem is not your own, and taking no responsibility for it. So blame is great, in that we get to feel good, but it is very bad, in that the problem will probably not get fixed -- or at least, we aren't going to make any positive influence toward a fix.
Ten years after the director of software development slammed his fist on the table, the company still has a pile of reporting tools. Somehow, I am not surprised, but that's only the first insight.
Deferring the decision as long as possible isn't just my idea; it turns out to be one of the principles from the Toyota Production System (TPS), the manufacturing system credited for eating Detroit's lunch. The lean software development elevates this to a core principle, and it is not just the lean community - Robert "Uncle Bob" Martin, a co-author of the Agile Manifesto, lists the Liskov Substitution Principle as part of his SOLID principles
of object-oriented programming. Liskov encourages programmers to create interfaces, which allows them to "switch out" major components, like the web server, the database, the operating system, etc.
When UncleBob started writing Fitnesse, they did the simplest thing that could possibly work, saving files to the file system, not a database. By designing interfaces with Liskov, the technical team could get a proof-of-concept GUI up fast and work on persistence later.
When the app was getting close to completion, UncleBob realized it was good enough. They didn't need to implement a DB layer. The application was open source; thanks to Liskov, if someone needed it, they could "just" implement it themselves.
This is the power of deferred decisions.
Another term for the deferred decision is an option. We know about these in the financial markets; you pay a little bit more to buy an option now, to control costs in the future.
Options in the Enterprise
Estimates are hard. Look, they are. We don't know how long things will take, and if we take a week to go create a work breakdown structure and build some confidence with work in meetings and on paper, it's likely that our estimates at the end of the week will be about as accurate as they were at the beginning fo the week!
Of course we can do it better than that. We could spent the week actually creating prototypes and proofs of concept, building real confidence that the work is possible -- but it management wants to control scope and schedule, to do anything even modestly ambitious, and oh and it's got to actually work, then, well, it's a craps shoot.
That is where options come in.
Consider the CEO who needs to know if the team can deliver the application by October first, because if the company doesn't make October first, it can't make the Christmas Shopping Season. He also needs to know if he should purchase television advertisements on multiple channels, because prices will go up exponentially as the date approaches October.
He could purchase an option; pay a modest fee to the providers, which will allow him to buy airtime in the future at a locked-in low price.
Changing our goal, from locking-in decisions early, to deferring them, can change the way we think about our work and the way we do things. Again, this is not my idea; Chris Matts has been talking about Real Options
in the Agile Community for years.
Except I suspect that answer won't satisfy the CEO. He needs to know
if you can do it, but he also needs to know
that the answer will be yes
We still have plenty of work to do.
More to come.