Two weeks ago on the blog, I wrote about the
contract model for software, how it is so appealing and yet ... and yet ... it doesn't seem to work out well.
Yes, you certainly can try to organize the project like it is a contract. You can write a specification, and you can have deadlines and deliverables ... and when those deadlines go whizzing by, you've got no one to sue.
For that matter -- where did those deadlines come from, exactly? In many companies in North America, the estimates are done by middle management in a spreadsheet -- that's if you are lucky. If you are unlucky, they are done senior management on the back of a napkin, and, sometimes, at a golf course.
Without the rigors of contract law to protect us, we are left without defense mechanisms. Heck, even the 'rigors of contract law' aren't to great; they tend to set up the two parties as opponents, fighting over the pie.
I would like to talk about a more excellent way.
Imagine Take a Trip and Visit a Strange Planet ...
This is a different planet named Morpheus. The ways of this planet are not our ways; the thinking is different.
On this strange planet, the typical business does not need to do estimation, or at least, not much.
Instead, the end customers make requests, the technical team works with the business to figure out what they will build, and then goes and builds it. Teams have a known period of time for regression testing, and try to size each new feature request about the same.
The Morpheiods don't give estimates; they expect that, at any time, the requirements will change so much that estimating is a waste. What they do track, and can predict, is
lead time. In other words, if something is priority #1, and it goes into the queue today, and you want to pay for a regression test run, they know it will be available in about how_much. (Typically, lead time is less than a week, with a regression cadence of under a week.)
But that's not all of them; that is only the people who live on North Morpheus.
On Southern Morpheus, the culture is a little different. On South Morpheus, no one does estimating at all. Instead, people work as hard as they possibly can, and things are done "when they are done."
The theory being: Most well-run companies are profitable. As important as hitting the holiday rush is, in the long run, it doesn't matter. They will have some product out for Christmas, and there will be another one out next Christmas, and all the time and money spent estimating, planning, controlling, tracking, and so on, could be better spent
actually building and testing the software.
These approaches might not work for your organization. I understand. When we imagine this happening on a different planet, if everyone agreed, if there was no resistance ... I hope you can see how it is
possible that such a strategy
could work.
It turns out that some companies actually can produce software this way, and be successful long-term.
Back on Planet Earth
I worked for a company that had a "small projects" team a few years ago. The team worked on maintenance of IT systems that were mostly independent. At one point, the team had something like two hundred requests in it's queue, and could perhaps get twenty or thirty of them done in a two week period. Management wanted to solve this problem with numbers, with process, and metrics, and tried it several different ways.
If you have played this game before, you know that the mid-level priorities and lower never, ever, ever get done. The high priorities always win; the best you can do is to shuffle the deck.
In the end, they junked it all.
The final decision was that every two weeks a council would meet and decide what the priorities were for the next two weeks. If it wasn't a priority for now, then, likely, there would be some other priority later. (We were not alone in this; David Anderson did something very similar in his
Microsoft X-IT Case Study. Fancier words and some other concepts, but, well, pretty much the same thing.)
Let's talk about the southern Morphoids. Believer it or not, when describing them, I was also describing the development/release process of
Id Software, the company that produced the wildly popular "Wolfenstein 3D", "Doom", "Quake", and "Rage" game series. Owned by the lead technical staff, the team does not make promises to the press -- instead, they write and ship games people will buy.
I know, Id is the exception, you couldn't structure my company to be like that, and so on. Yes, I know.
Yet consider a small,
ramen-noodles profitable web startup, delivery Software as a Service.
The company has customers that are billed monthly by credit-card. Say they pay $20/month, and the company is profitable, and gaining members.
Why spend all the energy on estimation? Couldn't you 'just' do a bag or work and ship it every now and again? Collect customer feedback, if they like it, keep it, if not, change or chuck it.
Who said we had to have estimates at all?
What Are You Getting at Matt?
There are alternative ways to think of the work, ways other than "We create a contract with some external entity, called the business, then build something according to that specification by a certain date."
My favorite example of this is the Amazon.com "
Two Pizza Team." Amazon teams don't just build the software and hand it off for maintenance, they collectively own the specification and decide what they will be.
It turns out that, if you've got infrastructure and can measure sales leading from new features, you can simply hire a team, set them loose, and measure their results.
Perhaps "you can simply" is too strong a word; but what I am saying here is that there are different ways to structure the work than the contract buyer/service provider metaphor.
Not only on planet Morpheus, but even on planet earth.
Back At Your Shop
No, I am not suggesting that you barge into your managers office and say "Matt Heusser said we should stop doing estimates!" That probably won't end well.
Believe me, I've tried. In 2004 I took at look at our "small projects" process and emailed my boss "
Petition the King", by Ron Jeffries, which, it turns out, suggests the
exact management process we would implement two years later.
Only, at the time, I was a heretic suggesting something crazy.
People have to come into these things in their own way.
More than that, it's a bit of a fallacy to see the distinction as either/or. In many cases, a good tester can add a great deal of value by helping to collaborate over what the system will be, or by suggesting alternative ways to handle errors and "corner case" situations.
When the original authors penned the
Agile Manifesto, they included this phrase:
We have come to value ...
Customer Collaboration over Contract Negotiation ...
That is, while there is value in the items on the right, we value the items on the left more.
I'm not sure exactly what they meant -- with seventeen people in the room, they likely meant different things -- but still, I get the idea they were trying to push us, ever so slightly, in the direction of the morphoids.
I'm not saying we should abandon estimates. Instead, I'm just saying that if we could find ways to shift the energy of the discussion toward the work itself, well, that might be a more healthy place to be.
Have you ever seen this done? Done well? What did it look like? If not, what would it take for us to change the world so that we might push a little bit in this direction?
I'd be happy to hear your comments.