Articles by Bill Miller
It was worse than I thought. I figured I’d be able to get at least one essay a week published during the month of November, but that even proved to be difficult. I’m just juggling …
What if you could be more accurate in your software estimates? What if you could gain more control over your project schedule? What if you could improve your product quality and know that you did …
The month of October has just come to a close, and it was an interesting month here on You Want it When? The month started with the first of a series on metrics: “Software Metrics: …
Purpose
To clarify some possible misconceptions about the goal of this article series, it is NOT to advocate that there should be unrealistic schedules. Quite the contrary, I don’t support expecting a team to deliver herculean …
Scott Sehlhorst, who writes Tyner Blain, a blog dedicated to software product success, and I had a debate over email about outsourcing. Scott recommended a topic and I decided to focus the discussion on his …
Management Approach
I’ve identified eleven tasks that I believe are essential for delivering to an unrealistic schedule. While the tasks are numbered, they signify a loose priority. It’s not intended for them to be followed exactly one …
You’ve probably been there, working to deliver on one of those unrealistic schedules. They all roughly follow the same trajectory. The marketing team sponsors the next project with a must hit inflexible date, an inflexible …
You’ve probably heard someone say it, or you may even say it yourself: “You design quality into a product; you don’t test quality into a product.” The last time when I heard those words uttered, I had to restrain myself from reacting. What did this person mean by that? The product was in trouble. It released late and with low quality. Customers were rolled back to the former version, and now the product marketing team fears that if things aren’t corrected soon they will lose market share.
What’s your worst fear as a software professional? My worst fear is changing jobs and joining a team that is in crisis. You’ve probably been part of a team, heard about a team or witnessed another team in your company deliver to one of those unrealistic schedules. Often times, the project starts off right, but entropy slowly builds as changes are introduced to the schedule with the velocity of an open fire hydrant. It doesn’t start that way: it builds with a crescendo. It’s not a case of replacing the old water with new water; it’s a case of filling a pool that’s filled 98% of capacity while watching the water spill over the sides and drain into the streets.
I often wonder why software teams always seem to be committing to unrealistic schedules. You know when the sales team signed a contract with a customer to deliver functionality on a date without ever asking the engineering team whether it were possible. Never mind the roadmaps identify an entirely different set of functionality than what was committed. And guess what? The product roadmaps can’t change either; the sales team has signed contracts on that functionality too.
