Painful Software Scheduling

I recently read an article from "Joel On Software" (http://www.joelonsoftware.com/printerFriendly/articles/SetYourPriorities.html) in which he discusses a feature prioritization technique. At some point, he mentioned "Painless Software Scheduling" in passing, and I thought to myself, "This sounds like something I should look up."

I didn't look it up. Instead, I decided to write about my experience of the opposite. Then I'll go back and read what the painless variety is all about and see where I stand. I don't have any good reason why I should go about it this way, but here I go!

I have had the honor of experiencing iterative development for a couple of years now. I've seen user stories (features), stakeholder meetings, feature costing meetings, and all the fun stuff that you get involved in when working with such a process. The best part is how the schedule is decided. Once the features are prioritized and given a cost the schedule is made. Here's how that goes.

Manager Type: "Hey Developers, how many features can you do this iteration?"
Developers: (counts hours, subtracts meeting time, etc) "uh, thirteen features."
Manager Type: "Thirteen? Guys, we have a backlog of 247 features. 213 of which are high priority"
Developers: "Well, we can only do thirteen. That includes coding, testing, documentation, and buffer for a million unknowns."
Manager Type: "Did you guys subtract hours because of meetings?"
Developers: "uh, Yes."
Manager Type: "I'll go ahead and clear those out for you. How many can you do now?"
Developers: (counts hours) "We can do thirteen."
Manager Type: "Still? Really? Why?"
Developers: "What do you mean why? That's how much we can do. That's what we calculated."
Manager Type: "After I cleared the meetings?"
Developers: "Right. We count our hours and take 60% of everybody's time and round down to the nearest whole number."
Manager Type: "I'll go back to the stake holders to get some more details on the features, then you can give us better estimates. So be ready to re-cost the features in a couple of hours."

Notice that the schedule doesn't exist. I'll bet money that when those "detailed" features come back it'll be the same conversation because the features don't have a detailed specification and the unknowns are just too large. That's painful.

Instead of annotating the rest the process I started above, here's a summary of the rest of the story: stakeholders end up in an eight-hour meeting, which they didn't have time for. The developers end up spending two days waiting for features and defending their estimates. The manager type argued every single feature on it's merits and motivation. Now nobody in the company wants to do it again. Most people that were involved in that eight hour meeting won't be showing up to the next one.

Try to run that process a couple more times and pretty soon, sales people are selling features so they're guaranteed to make it into the next iteration (or the current one), developers are giving insanely low estimates to their manager type will get off their back, and support people stopped talking about features all together. It was just too dang painful.

I would like to point out that the schedule still doesn't exist.

I know this scheduling thing has been done before, so why is it so painful? I can think of a couple reasons. It's painful because someone is pissed-off at some point. Everyone wants features now. It's not easy to take a list of 120 features and only release the top 20 of them. It's not easy to tell someone that their feature wasn't a high enough priority to get completed. It's insanely hard to tell everyone that the developers had to drop 5 features because of some unexpected pitfall. But the point is that something gets released.

This schedule will be completed by the end of this blog, dang-it.

I've noticed that painful scheduling leads to a lack of adoption from the people that create a need to make a schedule. The people that think of the features, the developers that implement them, the people that sell them, and even the people that want to create the features have no faith in any process put forth when the results are never seen.

How do we get all these valuable people to want to suggest, implement, sell, and schedule features? My guess is that's where painless software scheduling comes into play. The challenge we face is to make it easy to get features suggested and prioritized.

Let's start with making the prioritization meeting short, remove the debating of features on there merits and just get people to understand the feature and tell you how valuable it is to them. Make sure a reasonable number of features can be prioritized in no more than two hours. If you're looking at 247 features, try to slim down that number. Combine duplicates and remove extremely vague ones. You may even find features that only apply to one or two customers. Those can go.

Then, hand that list over to the developers and let them cost the features. If the feature is too vague, break it into smaller, more cohesive ones and keep the values of each the same as the original. If there are dependencies between features, slice and dice them until those are minimized and keep the values generally the same. I don't know how you'll do it, but you're smart. You'll figure it out, just do it. Trust whatever number the developers tell you. The more you have confidence in there estimations, the more confidence they'll have in themselves. That way, they will be far less afraid to come to you to drop a feature out of the iteration because of an unseen pitfall. After all, you don't want them to crank that last one out two hours before the demo. It will be buggy and useless anyway.

Now you have a schedule. If you started with 100 features and the developers can do 20 per iteration, then you can have it released in 5 iterations. Repeat the last two paragraphs between every iteration and you'll hone in on a number of iterations it will take and your confidence in that date will get higher with each run. If you make it easy for the stakeholders and the developers, they'll adopt the process and it's not painful for them. It's a lot of work for you, but when every body else is confident in your schedule, at least it's not painful!