Taking on dependencies


A recent discussion on how to deal with dependencies when you’re an agile team got me thinking…


Whether you are doing agile or waterfall (and whether the team you are dependent on is doing agile or waterfall), you should assume that what the other group delivers will be late, broken, and lacking important functionality.


Does that sound too pessimistic? Perhaps, but my experience is that the vast majority of teams assume the exact opposite perspective – that the other group will be on time, everything will be there, and everything will do what you need it to do. And then they have to modify their plan based upon the “new information” that they got (it’s late/somethings been cut/whatever).


I think groups that plan that way are deluding themselves about the realities of software development. Planning for things to go bad up front not only makes things smoother, you tend to be happily surprised as things are often better than you feared.


A few recommendations:


First, if at all possible, don’t take a dependency on anything until it’s in a form that you can evaluate for utility and quality. Taking an incremental approach can be helpful here – if you are coming up with your 18-month development schedule, your management will wonder why you don’t list anything about using the work that group <x> is doing. If, on the other hand, you are doing your scheduling on a monthly (or other periodic) basis, it’s reasonable to put off the work integrating the other groups work until it’s ready to integrate (based on an agreement of “done” you have with the other group).


That helps the lateness problem, but may put you in a worse position on the quality/utility perspective. Ideally, the other team is already writing code that will use the component exactly the way you want to use it.  If they aren’t, you may need to devote some resources towards specifying what it does, writing tests that the team can use, and monitoring the component’s process in intermediate drops. In other words, you are “scouting” the component to determine when you can adopt it.


 


Comments (5)

  1. Geek Noise says:

    Taking on dependencies from non-agile teams

  2. JH says:

    We had the same pessimistic (rightfully so as it proved) view of a dependency we were using on one of my previous projects. The problem came in that the dependency was, essentially, a DAL but they wanted each of our "domain" objects to inherit from the dependency they were building. Nope.. no interfaces here. Have fun!!

    It was painful. It was late. It was under-achieving. Ain’t it wonderful?

  3. Chris Parnin says:

    I find it most successful when the first stage tries establishing a "flow" from start/input to end/display as soon as possible.  That way feedback loop brings issues up more quickly.

    If there is a dependency, then that means there are already established "clients".  This should make things easier in directing development to satisfy others; which is better than development in a vacuum.

    @JH

    "objects to inherit from the dependency they were building".

    Sounds more like then wanted some form of dependency injection: visitor pattern, mixin classes, etc.

  4. JH says:

    @Chris

    It would sound that way until you have to rebuild your application (from scratch) for a third time because the hammer comes down and they say "You MUST inherit from these objects we will create for you". Then it just sounds like lunacy.

  5. Kevin Kerr says:

    I think these recommendations hold true in any engineering discipline.