Oh, and we’re hiring!
During my last couple of years at Microsoft, the Office organization was making a broad transition to a new, more agile engineering process. It wasn’t exactly textbook agile, but it was a lot more flexible when it came to changing requirements and iteration. It was an admirable change, and I’m not sure an organization the size of Office could make a wholesale change to a “truly agile” culture in a short time like that. However, a result of these changes was that we all had to rethink how we approached things like scheduling and ship-readiness. Under the new process, we were operating on a schedule of regular, more frequent “releases” (in the early days, this just meant “semi-stable builds”), each consisting of a fixed number of sprints. There were a ton of tools in place from previous releases to manage the schedule, but since our team (and the organization as a whole) was new to this, we knew it would take some tweaking to get it right.
We tried many different methods (and I won’t go through them all here), but in the feature areas I was PMing, I found some success using randomized historical models to predict delivery dates. I didn’t invent the techniques in this post (though I modified them a bit to suit our needs), but I hope it serves as a good explanation of how you can use Monte Carlo Methods (and simulation in general) to better predict the future. (Okay, that sounds ridiculous.)
Read the rest of this post