Same S**t, Different Year

For the past few years, I’ve been playing fantasy football. If you’re not familiar with the concept, you join a league with some other people, pick a name for your team, and then draft players from the NFL. There’s an order for picking players based on your record from last year and each NFL player can only be chosen by one team owner. Your score for each game against another team (usually one “game” per week) is based on the yardage and scoring that your players contribute to their real NFL teams.

I’ll be honest – I’m a pretty good owner. I’ve won the title once and come in second twice. My success is based on a sound strategy:

  1. I pick as many good running backs and wide receivers as I can early because they tend to score more points on a weekly basis.
  2. I pick the best player available at the time. The best player available is determined by what is recommended by a couple of sources (magazines and web sites) as I figure that they probably know more than I do.
  3. After each week during the season, I look for trends in the past couple of weeks to see if there’s an undrafted player who is really producing that I can pick up and I drop one of my non-producing players.

One of my opponents in the league follows a different strategy. He arms himself with all of the same kinds of data that I have. Then he follows hunches and drafts players way too early (when they will probably still be available in later rounds), thereby wasting his good picking position. He ends up with a good picking position (much better than mine) because he’s always finishing in the bottom half of the league. So, not only does he have a bad strategy and bad results, but he never seems to learn from his previous mistakes. Of course, luck is involved in this game. Injuries will take your best players out for weeks or even the whole year. The best running back in the league will have a crummy offensive line and get nowhere. The NFL coach will let your running back do all the yardage work and let some guy come off the bench to score all the touchdowns. However, even with all of this, a sound strategy, a good bench, reacting to the situation, and contingency plans can keep your team in the playoff picture.

After draft night last weekend, I got to thinking how similar this was to my last product at a former company. Every release we would get a feature set, spend a couple of months designing the features, do estimates based on our design, argue over the validity of our estimates, and end up with a feature set that just fit into our time allotted. The end of the development cycle would come up right at the end of the year, just before the holidays and the week off we were supposed to get. The end of the entire release (bug fixing time) would coincide with the company’s flagship product which we were supposed to ship with. In other words, we were set up to work under stress with little margin for error. Inevitably, we would start to run behind, have to work through the week off during the holidays and go through a death march, working nights and weekends, for four months until we shipped. We had a bad strategy, poor contingency plans, and never seemed to learn from our previous mistakes. Before the next release, we’d say, “Well, we’ll just have to do a better job designing and estimating this year.” It’s a classic waterfall development cycle without any room for error, and no contingencies built in.

In previous products, we might use the waterfall method, but when time was running out, we’d be able to drop a feature to keep the release process sane. In any software release, you have the three main variables built in: time (including people, so person-hours), quality, and functionality. Things work best when there’s flexibility in the quality and functionality parts. The powers that be usually don’t like to ship extremely buggy software, so there’s only so much flexibility on the quality end. If you aren’t willing to drop any functionality, you expand the person-hours. Given that you usually have a set team size (and don’t forget that adding people to a late project doesn’t usually help) that means simply working more hours. As appealing as that sounds to upper management, especially those who haven’t written software in years, working tons of overtime doesn’t help as much as you might think. The garbage that gets written after you’ve been working for ten or twelve hours in a day is truly staggering. I frequently came in the next morning wondering what on earth I was thinking when I wrote that code or fixed that bug the night before. Essentially, I wasted hours of my life and didn’t help the project any.

If your release cycles are going the same way, take action sooner than later. Be willing to drop functionality as the release falls behind (lots of features are extraneous “nice to haves” not “need to haves”). Use a different release cycle process – will an agile process work where you are? Push the ship date back – many (but not all) ship dates are simply chosen out of thin air. When you push back at management or marketing, sometimes you’ll find that these dates really are flexible. The worst thing is to keep making the same mistakes over and over again. Can you get better at designing and estimating? Sure you can. Will it ever be perfect? Unlikely. Do some companies succeed this way? Sure. Has yours? Chances are that it hasn’t, which is why you’re still nodding your head as you read this.