Key 12 - External Dependencies/Deadlines: Michigan Agile Philosophy (MAP) Project Key

12. External Dependencies/Deadlines

I realize my mind is a little strange. I’m going to pretend this is a good thing. When I was thinking about dependencies, my mind began thinking about things like Penn and Teller, dominos, then Rube Goldberg machines and finally…the game Mouse Trap.

For those of you who have played that blasted game you know it can be a love/hate thing. I wanted that game so badly. Once I got it and found out that it only worked one out of every ten times I was furious.

Usually it would go a little something like this:

I would turn the crank. Some of the time the boot would kick over the bucket and dump the marble down the zig zag stairs. If it didn’t get stuck or fall off the track it would go in the chute. YES! Now we’re cookin’! It was going to work this time. It would hit the pole. Sometimes the ball would fall into the bathtub…sometimes not so much. If it didn’t drop, I wouldn’t panic, I would simply drop it in the bathtub. If I was lucky it would trickle through and hit the seesaw. Often it did not. From there I would drop the diver into the tub and eureka! The mouse cage would drop…one notch. I would push it and it would go another couple. I’d flick it and it would go further. This is about the point where I would dump the whole board over and start over.

In the game of mousetrap each stage is dependent on the one before it. If one fails, well everything else gets jacked as well. Sometimes our projects have similar dependencies. Our piece of the project is often dependent on pieces that another group is working on. It could be that another project is dependent on something we are doing. Sometimes it is another product.

These aren’t necessarily bad things, they are just things to keep an eye on. They can be risks if they are not monitored. I remember an app I created that used Wikipedia’s API (Application Programming Interface) to get data and display it in my own format. Worked great. People loved it. Then one day, Wikipedia changed their interface. That meant the feature in my app would now be broken. I had an External Dependency on Wikipedia. It’s good to know where those dependencies live so that those risks can be monitored. This way your customer isn’t the first to find out.

Deadlines can be good things. On the psychological level they push us to move forward. On the project level they give us a constraint that is often unmovable. The fact that the project is constrained helps us to make decisions about which features should be added, which ones shouldn’t, and what staffing we need to deliver the feature set by the deadline.

It’s important to know when another project is dependent on work you are doing, especially if they have a deadline. At the end of the day there is only so much work that can get done. Understanding deadlines will help prioritize the most valuable chunks of work and to get them done first. Identifying the places where dependencies exist and then communicating with those that are affected is critical to the success of all projects.

In your project you should identify External Dependencies and Deadlines. Maybe stick them on a card and put them up on the wall in your team room. You can always talk about them at your planning meetings as well. Just don’t lose sight of them. The last thing you want is to end up with a Mouse Trap game for a project.