We’ve launched dependencies!

Last night the team stayed up late making sure that the update to the site went smoothly. This morning our users were greeted with dependencies. This is a big deal for us as we were getting quite a few requests for dependencies. In fact, several people asked us why we launched without dependencies. I thought I’d take a minute to talk about that.

I have a love/hate relationship with dependencies. When we designed LiquidPlanner we realized that when you put all of your tasks in priority order you just don’t need that many dependencies. The reason being that if Task-A needs to be done before Task-B you just drag it up above Task-B and (provided they’re assigned to the same person) Task-A gets scheduled before Task-B. So if you slice your big projects up into small enough pieces (say by doing Scrum with one month sprints) then the whole “need” for dependencies just gets a whole lot less urgent.

We have been using LiquidPlanner to plan our internal work since about April 2007. It is now a year later and we have added dependencies, but we never really missed having them. In fact, one thing that dependencies do is make your project plan brittle. They make it hard to alter the plan without breaking a dependency or messing something up. That is not to say that the project can’t change easily, just that the project plan cannot. This is kind of an artificial penalty for updating your plan to reflect changing reality.

I am all for moderate use of dependencies to build project plans. But I think that products which demand that you put a bunch of dependencies in place in order to get a halfway sane plan have trained many project managers to bad habits. They’ve become addicted to dependencies. And the more you use dependencies to solve your scheduling problems the more brittle and hard to maintain your project plan becomes.

So before you add that dependency ask yourself, “Do I really need this?”

Because if you can just prioritize the work earlier then you’ll end up with a schedule that is much more flexible and resilient to the change that inevitably occurs when a project plan meets reality.

I first heard the phrase “eat your own dog food” while doing some vendor work for Microsoft. Although I’m not sure why — none of the development teams I worked with used Visual SourceSafe, perhaps because it was an acquisition product. I also never saw a PM pull up a Microsoft Project plan on their laptop. More on that later.

Although I like to think of it now as steak tartar, we’ve been eating our own dogfood at LiquidPlanner from the beginning. I wish I had screen shots of some of the scaffolding UI that we had early on. Thanks to our uber-talented development team, it made a quick evolution to what you see today. This philosophy of also developing for ourselves has uncovered hundreds of opportunities –some we’ve responded to, and still others we’ve had to leave on the table for a while.

Deciding what to do next is sometimes tough. The night before our public beta launch at DEMO, my colleague Jake Gordon nailed it when he said, “We’ll know tomorrow what we need to work on tomorrow.” You gave feedback, we listened, and as a result, task dependencies will be in our upgrade to version 1.1 later this week.

I have to be honest – for a while, dependencies had fallen from the table to the floor. I’ll explain why as I beg you to consider carefully what you wished for and use the power of dependencies wisely.

Most of us on the development team have been forced to use or have willingly tried to use Microsoft Project at some point. One of the things we identified early on as a negative about the user experience was dependency maintenance. Because resource leveling sometimes behaved in unpredictable ways, hard coded dependencies were used to force logical scheduling. And Microsoft Project gave you an abundance of choices for types of dependencies, such as “finish -n,” where task B cannot start until task A is “n” days from completion. These types of dependencies falsely present themselves as reliable. In an uncertain world, you can’t always say that task A will finish in exactly 15 days, so how can you be certain that task B needs to start 5 days before task A finishes? For that matter, how can you say for certain that task B needs 10 days of lead-in time? Uncertainty is cold-hearted like that. The dependency above is actually not solving the real problem. It’s likely that task A needs to be decomposed further, because task B is dependent on some component of A.

Another issue with direct dependencies occurs when you need to move a chunk of work out of one project and into another. This is common for all types of projects. Just because you want to wait to do the fancy garden landscaping doesn’t mean you don’t want to do it at all. You’ll get around to it. Maybe just do the brick patio this go around. So you move that task or set of tasks into your project folder for Q4′08 … but if you have dependencies with items back in Q2′08…. I think you can see where this is headed. My prediction is you will next ask for a way to quickly delete all dependencies.

We honestly never missed direct dependencies in our development work, but we realize that we are only one data point. The automatic resource leveling / implicit ownership dependencies just worked in our case. In our small agile development team, we frequently are not working on our top task. We also don’t spend any significant amount of time moving items around in priority to reflect what we are working on. The idea is that even if you are context switching between three tasks, you still only actually work on one at a time and it all comes out in the wash. So if Jake needs something from me, he nudges me and then just works on the first task that’s not dependent on what he needs from me and life goes on. When we level set at mid-sprint, those items at risk are noted, adjustments are made and development proceeds. At the end of sprint, a decision is made as to the readiness of the whole feature.

We’re initially launching with simple Finish – Start dependencies. I can’t say for certain if more complicated forms of dependencies are on the table or not. It’s ultimately you who will tell me.