How Do You Manage Dependencies in Agile Projects?

I am writing this post to share my thoughts on dependency management and write about how it impacts Agile teams. The motivation to do this is my previous post 'Yet another Dreadful Dependency'.  We hear stories similar to this in our work life. Don't we?

A task we perform can be independent or dependent (on something else – say another task). It is independent when we are free to start and end the task without having to worry about anything else. It is dependent when we have to think and do it in a logical sequence by considering all dependent tasks.

Sometimes you need to wait for another task to finish so that you can start a new task. Sometimes you wait for another task to finish so that you can finish your current task. There can be a situation when you wait for a task to start so that you can finish your current task. Also there can be a situation when you wait for another tasks to start so that you can start a new task. That’s how we have 4 types of task dependencies FS, FF, SF, and SS. This is not a traditional project management stuff. This applies to all projects including Agile projects. When you think in terms of these 4 types of dependencies, you can streamline every iteration or Sprint by minimizing dependency issues.

I think, we need to think deeper than this. Can we categorize task dependencies in some other way? Do we have techniques to deal with such dependencies? Let me explain.

How do we categorize dependencies? We can group dependencies under several categories such as

Technology Dependency – This category is about dependencies arising from architecture, design, coding, components etc. Here are some examples.

1. Program A cannot function until Program B is developed
2. We have to change the program as component X has changed
3. We cannot develop layer-Y in our architecture until layer-Z is ready

Data Dependency ¬ This is about dependencies related to data readiness to complete project tasks. These dependencies are often ignored in projects as project teams find ways to create data in some way or the other. I am sure we learned ‘logical dependency’ and ‘physical dependency’ in our DBMS course. I am not talking about those here. Here are some examples.

1. Acceptance Tests cannot start until we get adequate data for testing
2. Data sources A, B and C need to be in sync to start integration testing
3. Defect X cannot be reproduced until the logger is turned on to capture the trace of events

Application/Service Dependency – In this category we come across dependencies involved in developing, maintaining or testing your current application with reference to other related or dependent modules, applications or services.

Build Dependency - I have not included build dependency under technology dependency because dependencies related to build management deserve a separate mention. When we create builds we identify dependencies and compile programs in the right order. Also, when it comes to several interrelated applications or a suite of applications, build dependency becomes a pivotal point. There are several techniques and tools to identify and manage build dependencies.

Operational Dependency – These category includes other operational dependencies such as release dependencies, data migration dependencies, connectivity dependencies and so on.

These sound more conceptual and theoretical. Can we look at dependencies in a different way, analyze and understand them?

Is there a simpler way? Good question. Fair enough! With all these categories of dependencies, our discussion can become overwhelming. I know. We need to have a simpler way of identifying and categorizing dependencies. A logical way is to identify dependencies at three levels – product roadmap planning, release planning and iteration or Sprint planning. However, awareness on different categories of dependencies is necessary. With that awareness we won’t miss out any.

For each dependency, all we need to do is ask these questions.

1. Is this an internal dependency (local to the project) or external dependency?
2. When will it hit us - short, medium or long term? How much time do we have to plan and manage it?
3. Is this dependency going to last for a week or couple of weeks or months or more? Or is it perpetual or recurring?

These questions help us understand the circle of influence (internal or external), estimated time of start, and expected life or duration. Without these we cannot understand the gravity or impact of dependencies. Without these, we will not be able to reduce anxiety and spend our efforts on the most important tasks. With out these we will not be able to identify the right techniques to handle dependencies.

What are the techniques?  There are many techniques. Here are some pointers to those techniques.

1. Learn and apply design by contract and practice DIP (Dependency Inversion Principle). A downloadable PDF on design principles is available at http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf.  It includes information on DIP. If you are a hardcore programmer, read this post for more information http://www.pelshoff.com/2012/02/dependency-management. 
2. Use stubs, mocks etcetera to manage the situation until you get the real objects to depend on.
3. Don’t ignore data dependencies. If something is necessary – for example, production data, you cannot live without it. Make it a criteria. Don’t accept junk data for testing.
4. Application/Service dependencies can be haunting. What if a service breaks in real time? A way to handle this is to build robust exception handling mechanism. In addition to this, check dependency issues through automated scripts or snoop error logs. Here is a PDF file on managing dynamic service dependencies - http://proceedings.utwente.nl/13/1/S5-1.pdf.
5. When you work with multiple teams (for example, Scrum of Scrums or with multiple dependent projects) dependency management has to be handed through proactive thinking, asking questions and triggering discussions in meetings. In addition to asking ‘Are we dependent on other teams?’ it is necessary to think ‘Is there a team that depends on us?’ 

If you are a researcher or student here is a PDF white paper from OOPSLA 2005 - http://www.lattix.com/files/dl/wp/oopsla05.pdf.

I think I have shared a good number of concepts and practices here.  How do you manage dependencies? Do you use any tools or techniques? Let us discuss.