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.
