“We’ve never had a successful release”
You just finished this really hard feature. The whole thing was worse than anyone realized. Not only that, but the feature wasn’t clearly explained, so you lost time churning on the actual requirements. Despite all the confusion, iteration, and technical challenges, you managed to get it working! You look back, savoring how much you have learned and grown.
You show it off to the product owner. He barely seems to hear you. His shoulders slump in disappointment.
“Great, but we are still four weeks behind.”
Your team is infected with Development Disappointment Disorder.
It looks different in every team. The manager who sets unreasonable deadlines then demands overtime. The project manager who gets angry at every little thing. Developers who feel they need to point fingers to shift the blame. The boss who is never happy no matter what is achieved. The team that feels they have never had a successful release.
Unreasonable Expectations
Development Disappointment Disorder is caused by unreasonable expectations. Someone thinks, hopes, or wishes they can get 100 units of productivity from a team and codebase that only can sustain 30-40 units. They want the impossible, and no amount of cajoling, pressuring, yelling, or passive aggressive comments will change reality.
Productivity is not completely a people problem. Every team has an upper limit to what they can produce in a system. The human mind has boundaries. Very real limits exist given the team’s size and existing codebases. While new technical tools and libraries enable more productive teams, these changes often are hindered by an existing codebase. The team with a multi-million line C# codebase is not going to get much value from the productivity gains possible with Haskell’s type system.
You cannot rush software development without incurring a drop in quality, stability, or maintainability. The work is complex and difficult: every expert in our field agrees with adages like “adding developers to a late project makes it later.”
Suggestions
-
For the technical staff: How accurate are your estimates? How consistent is your throughput? Do you regularly under-estimate your features? Do developers often say, “oh, that’s only…"? Are some types of features “always late”?
You must learn to be blameless in this situation, and that means striving to give as accurate an estimate as you can with what you have. Throwing estimates out without much thought only makes things worse. How long did a similar feature take last time? If you regularly have inaccurate estimates in a certain area of the system, put extra care into those estimates, working to provide the best estimate you can.
-
For the business: There is only so many units of productivity that fit into a given time frame.You need to assess every feature and estimate, and consider the risk with each.
Acting disappointed, angry, or passive aggressive will not get you more features, it will only demotivate the technical staff. You will get more consistency, because they will consistently work slower. You will get more hours, but each hour will see a massive drop in valuable work.
Acting disappointed, angry, or passive aggressive will not get you more features
If you are unhappy with the work produced, you need to consider why. Were you told it would be sooner? Did you promise that to someone? What changed since then? If the feature isn’t actually needed, why did you pick it? If spending twice as much made it not worthwhile, was it really a good choice?
What would happen if you didn’t promise when the features would be done? Either way, your promise doesn’t change when it will be done, it just adds risk to your credibility. Often the only thing to be gained by giving out estimates and time-lines is risk. Unless the customer is truly blocked on your estimate, simply communicate what you are doing, not when you hope it will be done.
Often the only thing to be gained by telling customers an estimate is risk
- For the team: Celebrate your successes. Abolish the notion of a “failed release”. Build up a culture that finds little victories throughout the release.
With these tools you can fight Development Disappointment Disorder. You can start to celebrate what you do accomplish. A team that is energized and motivated will accomplish more. The team that celebrates their work will strive for more.
