Bedeviled by Dependencies

Esther has an M.A. in Organizational Leadership, is the author of over 100 articles, and co-author of "Agile Retrospectives: Making Good Teams Great" and "Behind Closed Doors: Secrets of Great Management". She’s a founder of the AYE Conference, and serves on the Board of Directors for the Agile Alliance. www.estherderby.com.

  Agile   Applications Delivery   Information Technology  

It doesn't matter whether you work for a big company or small company: When delivering a product that requires the work of more than two teams, dependencies are part of the picture. Time after time, I see projects tangled up in dependencies. Does it have to be this hard? Some dependencies are inevitable, but some are self-inflicted.

Some dependencies just are. Either the product won't function without all the pieces, or the product isn't useful until it performs a series of steps related to a particular task.

Technical dependencies arise from the way data or transactions flow through the system. With a technical dependency, you can't ship (or fully test) the software until all the component parts are done. The lag between finishing the first and final components may be weeks or months. You won't find out how all the parts work together until they are all completed.

Functional dependencies involve workflows, operations and other temporal processes. For example, it might make no sense to perform Action D before Action A, or the product may only have value when it performs Steps A through D.

It may take a long time to build all the functionality of Steps A through D--too long to meet customer needs and market demand. As with technical dependencies, functional dependencies can lead to lag and late learning on projects.

There's another …

Please log in or sign up below to read the rest of the article.