Sign-in

Entries from March 1, 2008 - April 1, 2008

Tuesday
Apr012008

Depending on Dependencies

sm_glass_and_candle.jpgWe'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.

Monday
Mar242008

Dogfood and Dependencies

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.


Thursday
Mar132008

Another 6 minutes to make the pitch 

Under the RadarWhat is it about that number?

Next week, LiquidPlanner will be presenting at the Under the Radar conference in Mountain View. And just like at DEMO 08, we'll have exactly six minutes to pitch the company, the product, and the business opportunity. (By the way, look closely at the rotating banner ad on the DEMO site to see a shot of Charles and Bruce in their on-stage glory.)

The audience? Press, investors, analysts, private companies, and other service providers. We'll be sharing the "Work Together" session with our friends at blist as well as Cozimo and SlideShare. We'd love to meet you if you're attending.

Tuesday
Mar112008

SXSW 2008 V - Geek Spring Break

I’m thinking that there’s more to the whole games as reality thing.Today is just fun.

The "How to Rawk After SXSW: Staying Insprired" was much fun. Candy was thrown to/at the audience. I won't go into details but it was basically a big geek lovefest. Totally sweet!

I'm in the big ballroom (A) waiting for Jane McGonigal to talk. I'm about written out. My fingers no longer talk to my brain before writing. This'll be my last post from the conference. I may or may not write an overview or retrospective later.

There are some key take aways that I have for anyone thinking about coming to SXSW. These are colored by my position evangelizing a product at a conference where I am just an attendee.


  1. Don't focus only on "relevant" panels.
    Branch out and try a bunch of different panels because SXSW is really about inspiration and ideation. You never know where you will find "relevant" material.

  2. Don't skimp on the nightlife.
    This is where the magic happens. I had the best conversations with people that I met in bars. And on that topic, get to your venue about 30 minutes before the party starts. You will really want to get in and start mingling. Talk to everyone you can. Everyone here is friendly.

  3. Don't friggin' pimp your product every damn time you get up to a mic to ask a question.
    In fact, if you don't have a question (as in, ends in a question mark) don't go on some long rambling discourse about how open source software is changing the world through social networking for the good of children in Angola on SourceForge. Get up, ask your question (one or two sentences at most) and then sit down and listen to the answer. We're at the panels to hear the panelists, not you (so much).

  4. Get lots of business cards.
    LOTS!

  5. Get familiar with Twitter.
    Sounds weird, but I really get Twitter now. It is one of the coolest productivity tools for conferences ever.

  6. If this is your first SXSW, there will be others (hopefully).
    You don't have to do it all. Meet people, see a few good panels, learn how SXSW works. This conference is more like a romantic relationship than a business one; you need to woo SXSW, not power sell it. You are building a long-term relationship.


Later I'm going to hit the futurist talk and then... well... there's just the one more night in Austin with my friends Jerry and Shiner

.

Monday
Mar102008

SXSW 2008 IV - Startups, Pirates, Secrets and Bootstrapping

Austin Texas storm SXSWMy morning started off with a bang. Thunder. Yes, it is raining like hell. Big fat drops and lightning strikes.

The first panel was good too.

Eric Hellweg of Harvard Business Journal Online moderated a great panel on "The Care and Feeding of a Startup". He was the most dynamic moderator I've seen at the conference yet. He did it "Jerry Springer style", walking up and down the aisles with a mic. I actually found this very effective and would recommend it to confident moderators in the future.

One of the key points that I got from this panel was that the founding team needs to focus on building out a strong core product feature (or small feature set) and that VC funding can be quite distracting if you let it. In particular, Blair Garrou from DFJ noted that early stage VC funding for web startups can distract from listening to your audience.

Then it was "Startup Metrics for Pirates: AARRR"!

Arrrr!

While tempted to write the rest of this post in Pirate Speak, I think I'll continue in more modern parlance.

This was a very entertaining and fairly informative too. The deck can be found here and is well worth your while to read.

The key take away from this was that you want to find a small set (like say... one) of actionable metrics to gather and monitor. If you can't make a decision with a particular metric then it is not actionable.

They talked a bit about tools for metrics. Of course Google Analytics was in there but there was also CrazyEgg.

The round table of FailOkay, maybe I'm the last to the party but CrazyEgg is just incredibly cool! It does click tracking on your pages and allows you to slice them by traffic source. They has some really good examples of using the CrazyEgg data to redesign a webpage for a gaming video site. Totally sweet (and you know I'm a data visualization junkie).

Unlike yesterday's keynote (the social media reaction to which was actually called out by the conference organizers before this keynote) Frank Warren rocked the PostSecret presentation. Totally inspiring. Totally uplifting. His speaking style is perfectly fitted to the subject and the message. He is a master of handling questions (some of which were only kinda questions) and setting everyone at ease even when you were quite uncomfortable. Amazing.

Thence to the "Boostrapping 101" panel. Damn. Philosophically interesting, but practical and useful as ice skates on a pig.

Now I'm just waiting for the "Stories of Failure: Surviving Start-up Mistakes" presentation. (Picture at bottom)