The Brave New World of Schedulation
Schedulator is the software project management system we originally developed at NITI to solve a simple problem: I'm a programmer, and I ended up as a manager, and I didn't want to spend all my time doing management.
It's essentially a fancy automated implementation of Joel Spolsky's Painless Software Schedules, where each developer can manage his/her own schedule. By combining the results generated that way, you can produce an accurate schedule for the whole team.
Schedulator isn't very many lines of code, but it's the result of years of tweaking of the Schedulation process, which actually works pretty well, and has a lot of advantages over "normal" software scheduling. As part of my new job, I've been redoing major portions of the Schedulator to make it more flexible: it now supports bug tracking systems other than FogBugz, for example (although that one's still my favourite :)), and no longer requires GracefulTavi (as much as I like wikis, doing it that way led to a pretty inflexible design).
The new Schedulator isn't packaged up nicely, and may never be because it has a pretty limited audience. But it should be much easier to get up and running with the new version than the old one, because it has far fewer prerequisites (and the parts that have prerequisites are now optional plug-ins).
I did, however, write some extensive documents explaining the theory and practice of Schedulation. My favourite is the first one, Schedulator Philosophy. Read it, and maybe find out if Schedulator is right for you.
The Google Factor
Not long ago, pcolijn wrote about Google's development process and compared it with Schedulator. I generally agree with his analysis. The problem is that most of the problems Peter identified were not problems with Schedulator, per se: they were problems with the general team atmosphere and management. (I'm allowed to say that, because I was one of the managers.) Schedulator is very compatible with the "Agile development style" done at places like Google. Okay, so Schedulator doesn't come with any index cards included, but it does do a lot of the grunt work of arranging those index cards - particularly when there are hundreds of them in your bug tracking system and they all seem important - for you.
As much as Google is indeed awesome, hires a lot of great people, produces a lot of great things, and makes an awful lot of money in the process, I sometimes caution people against taking their experiences at Google too seriously. People in highly successful companies are prone to an attribution bias, much like people are in unsuccessful companies. That is to say, no matter what your team does at Google, Google is still going to be making billions of dollars. And no matter what your team does at some unsuccessful or dying company, you probably can't pull it out of the toilet. In both places, the consequences of your actions are disconnected from reality. (Bill Gates called this the honeymoon phase.) At Google, raises and bonuses for everyone. At the unsuccessful company, even great people get laid off sometimes because there's no money to keep paying them.
For example, the article that Peter was responding to had this very important paragraph:
- Another incentive is that every quarter, without fail, they have a
long all-hands in which they show every single project that launched to
everyone, and put up the names and faces of the teams (always small) who
launched each one, and everyone applauds. Gives me a tingle just to think
about it. Google takes launching very seriously, and I think that being
recognized for launching something cool might be the strongest incentive
across the company. At least it feels that way to me.
Sure, this is a great incentive for people to work harder, and Google's very wise to do it. But do the math: every single project that launched? Always small teams? But Google employs thousands and thousands of programmers! They can't all be on the big screen. In fact, most of them can't. But Google's still successful.
Which kind of team are you on? How can you tell? Statistically speaking, you're probably on the unsuccessful kind. And beware of logic that sounds like, "my team did this, and we weren't too late" or "their company did it this way, and went three years overtime." There's a correlation there, but there could easily be no causality. Super-ultra-smart people could do their project plan on stone tablets and still get their projects done an order of magnitude faster than complete boneheads.
That said, I used (and still use) Schedulator, and it works great for me :)