An agile approach to managing dependencies
Capturing and visualising dependencies between work items is the most obvious way to manage dependencies, but have you ever felt that things go out of hand really quickly?
How dependencies are managed traditionally
Traditional project management, for example, using Microsoft Project or other Gantt Chart tools, uses task dependencies of any of the following four types to denote dependencies:
- Finish-to-Start: The first one needs to finish before the second one can start.
- Finish-to-Finish: Tasks need to finish together.
- Start-to-Start: Tasks need to start together.
- Start-to-Finish: This is not common, so let’s conveniently forget that it even exists.
If you are like me and need a refresher, the paymo website has a simple and good article on task dependencies.
I have often seen the same approach being used within projects delivered using agile methodologies. Even within Jira, tools like Jira Align and Jira Portfolio/Advanced Roadmaps offer the capability to capture and visualise dependencies between work-items. I have tried using some of these tools but everytime the number of dependencies increase beyond a handful, the visualisation resembles a cobweb making it less useful for quick decision making.
So with the agile mindset of embracing simplicity, I have experimented with various approaches over the years. Here is one of those approaches that has survived several projects and organisations.
An alternate agile approach
The key difference in the agile approach is the use of Epics to collect Start-to-Start and Finish-to-Finish dependencies. If work items need to start or finish together, this makes perfect sense, isn’t it?
I usually approach Finish-to-Start dependencies based on the size of the tasks. Smaller pieces of work usually form part of the same epic, but if any of the items are larger I tend to keep them in separate epics. Start-to-finish, which was the one we were trying to forget, can also be modelled as separate epics if they are big enough.
If I were to describe the approach, it would be to flatten the dependencies and bundle them into one or epics that are then sequenced (or prioritised) based on the dependencies. That way the dependencies either get done together or before the dependent work.
The basic rule for epics that has always worked for me is to bring together work items that are closely related and are likely to be dependent on each other to bring business value. This also allows me to report back on value based on the completion of epics.
Advantages
The biggest advantage is that the complex problem of dependency visualisation and management goes away as this approach is much more simple. No more crazy cobwebs.
The second advantage is that this approach leverages existing agile concepts of breakdown, epics and prioritisation. It fits in well with the agile best practice of small granular epics.
Dependencies in scaled agile
I still retain the habit of linking together dependencies using Jira issue links because of the extra information when you need it. Maybe it's my OCD or fear of missing detail, however I don't use for visualisation or for managing dependencies on a regular basis.
In a scaled agile environment especially where different teams work on different epics, I have resorted to marking dependencies between epics, so that you can still visualise the high level dependencies. The advantage still is that the complexity is much less than when you try visualising dependencies at the story or task level.
Photo by Bryson Hammer on Unsplash
Posted under: Atlassian Jira, High Performing Teams, Agile Delivery Management, Scaled-Agile