We had hired some new people, and we needed to assimilate together. At the cabin for a week, we could learn to work together.
We were in a remote location with internet access, each other, and the food we carried in. We would do real work (mostly proposals) and in doing the work learn where our frictions and strengths are. Ideally, it would lead to self-coaching and we could leave a fully formed team.
But What Will We Eat?
Food planning was where we ran into planning stress.
To begin with, we didn't want to spend days of effort on planning the food. Our time is expensive, and planning what we'd eat is not something we could afford days of effort on.
On the other hand, we needed good up-front planning, because we couldn't really change our minds once we were there.
Different people would want different things (some vegetarian, some vegan, some restricted, other people omnivores and near-carnivores). Some liked to snack on fruit, others on olives, others cheese and crackers. Maybe we'd want tea, maybe soda, maybe beer, maybe fruit juice.
Having too little food or too little variety might cause clashes between people; some would have exactly what they want while others went without anything that they liked (or could eat). We didn't want to use this time to increase the dissidence between people. We had to be "fair."
Likewise, some were very concerned about sourcing responsibly v. saving money. Did it matter if the eggs were cruelty-free and free-range? Did the meat need to be grass-fed and hormone-free? Did coffee and chocolate need to be fair-trade? Did the politics of the store matter?
The need to cover all contingencies, and we had to have a final answer up front.
That's planning stress. It's not a big deal, you would think, but as amateur event coordinators without professional help, the team put everything into the plan that anyone might need (or want) .
We ended up purchasing over US$500.00 in food.
The food was great. We had roasted vegetables, soups, middle-eastern fare, awesome pancakes, snacks, drinks, roasted meats, gourmet olives, cheeses straight from the Netherlands. By Thursday, we were simply sick of eating great food. We had prepared a whole turkey, and only sampled bits of it (out of curiosity and politeness, mostly) because we were so tired of great food.
The food we had left over would have fed a small village for a week.
We clearly overspent and overstocked, and as a result we had a pretty high level of waste.
By the way, it was a smashing success as far as creating closeness among the team members and producing good proposals. Something about cooking together and working together all day taught us to respect and value each other. I can recommend the retreat idea, but highly recommend using professionals for food planning, or at least establishing a reasonable budget for the team to work within.
How Does This Relate To Software?
This same behavior is observable in projects.
If you have to give up-front requirements and make promises on an 18-month project then you have to ask for everything you might want in the next 18 months. It's hard to know everything that you might need, so you put it all in. After all, you want to be thorough.
Some features won't fit into the plan and will have to be dropped, so you'd better have something else waiting in the wings that has been carefully thought-out.
Of course, the client doesn't have clairvoyance either, so they don't know exactly what they'll need a year and a half from now.
We are told that over half of all software features produced by developers are never or seldom used. Sadly, we don't know (in advance) which features those are.
If you pick the wrong features or not enough of the right ones, then the product will not be accepted by the market or the customer. You won't know until acceptance if the customer really wants it (by which time your innovative new features may be commonplace). You could do a great job churning out features for 17 months only to fail utterly in the 18th.
You can't change your mind once the project starts (at least not cheaply), and you can't know if you're right until after it finishes.
We might plan two years' worth of work into an 18 month project. Sometimes more than that.
Planning stress causes overload.
Just as we could have been happy with less than half as much food, most projects could be just as successful with fewer features, or with implementing less of each feature.
I consider "planning stress" to be made up of (primarily):
- The period for which you must forecast needs
- The time before you can find out if you're right or wrong
- The need to be comprehensive
- The costs of being wrong
Reducing scope or period would reduce stress, as would more frequent feedback. Smaller batches (as are common in Agile methods) try to address this.
What if it were only a week? What if we could release new software to some of our customers for comment every week? It's unlikely that we'd load more than 6 or 7 days worth of work into a 5-day week, and we'd be willing to make trade-offs and scope reduction this week, since we can vet our ideas at the end of the week.
What if it were a day? A matter of hours?
John Tangney once told me "Continuous deployment takes all the stress out of building software." I think he's probably right. Knowing that you can change your focus or change your mind about a feature at any time is very freeing.
No comments:
Post a Comment