I don't want to manage dependencies; in fact, I don't want to have any dependencies. Is that even realistic? On smaller efforts I think it might be possible. Lately I've been working on large programs with 50 or more people on the project, with multiple teams and many times multiple companies involved. Here dependencies are a reality.
So what do we do about them. My mantra to teams is simply:Eliminate dependencies
If you can't eliminate them, minimize them,
and as a last resort plan and manage them.
Let's talk about eliminating dependencies.
If there are dependencies how can we eliminate them? Many times what appears to be a dependency is not a real dependency. If you've ever had a house built, you've probably seen this. The walls are ready to be painted, the flooring is not in yet, but it's ready to go too. Which goes first? Of course you paint first and then put in the flooring. However, in this case there's no hard dependency, although some might say there is.
You could choose either order. You could put the flooring in first and then paint the walls or you could do the reverse. The logical choice is to paint first. Why put in new carpet or nice hard wood floors only to spill paint on it. In this case it's logical to paint first. However, what if the paint crew isn't available for 2 weeks and the flooring crew is ready now. You might choose to put the flooring in first and then let the paint crew ensure they take care not to spill paint on the new flooring.
If there are dependencies how can we eliminate them? Many times what appears to be a dependency is not a real dependency. If you've ever had a house built, you've probably seen this. The walls are ready to be painted, the flooring is not in yet, but it's ready to go too. Which goes first? Of course you paint first and then put in the flooring. However, in this case there's no hard dependency, although some might say there is.
You could choose either order. You could put the flooring in first and then paint the walls or you could do the reverse. The logical choice is to paint first. Why put in new carpet or nice hard wood floors only to spill paint on it. In this case it's logical to paint first. However, what if the paint crew isn't available for 2 weeks and the flooring crew is ready now. You might choose to put the flooring in first and then let the paint crew ensure they take care not to spill paint on the new flooring.
Let's look at a software example using user profiles. Consistently teams I work with want to build the profile setup feature first. They feel it must go first; that everything else depends on it. This is an approach, but it's not a real dependency, only a perceived dependency.
If you have another story that needs a user profile in the system that story doesn't care how the profile data got there only that it's there when needed. In this case you can eliminate the dependency, keeping in mind that the first story to use a profile will have some profile work to do (e.g., create a data model and get test profiles in the database). This is just one example of where some dependencies are can be eliminated.
The next post we'll talk about minimizing dependencies.
The next post we'll talk about minimizing dependencies.
.
No comments:
Post a Comment