Identifying sequencing and dependencies

Organisations, teams, and individuals rely on each other to do tasks. This need or ability to rely on each other requires a working relationship between those involved and introduces dependencies: if one team or individual doesn’t do their part, it can have a knock-on effect on the ability of another team or individual to do their part.

Last week, we looked at the different types of teams that we might use or encounter in Agile projects. Remember the functional team that typically looks after work relating to a particular function?

Well, imagine that one of our functional teams is focused on finance and that one of their actions is to secure funding from the bank so that we can implement a particularly expensive feature. Unless that team achieves its action and gets the finance, then the feature-focused team won’t be able to progress with developing and implementing that shiny expensive feature. We’ve got a dependency.

Our ability to manage these dependencies increases agility and leads to the reduction of waste in our teams. Waste in this case could refer to time, materials, technical skills, and more. This is where the roadmap can come in handy: by putting the actions on the roadmap in different swim lanes – perhaps by team responsibility, for example – we can start to plot out and visualise the dependencies between different teams.

Any project that requires several consecutive steps will have dependencies. Let’s use the following example to visualise this:

An author writes a story, the editor checks it, and the publisher finally prints a copy. The dependency between the author and the editor is that the editor checks the manuscript. This provides a safety net and adds value, but also slows down the process and perhaps encourages waste.

If we were to create a roadmap for this example, then the particular section that looks at this interaction might look like this:

_{An example roadmap}

By visualising the actions, we can see the dependencies: until the author writes the story, the editor can’t do their work. Until the editor does their work, the publisher can’t do theirs. Visualising the dependency then allows us to confirm that the interaction adds value. In this case, the dependency between the author and editor reduces risk and adds value but increases complexity and can be disruptive to the progress of the project. Does the relationship need to exist to make the project a success? What risks would happen if we removed or changed the relationship?

Dependencies can be found both internally and externally to an organisation or project. Although dependencies may at first seem ‘counter-Agile’, they are necessary when considering the high level of technical expertise and risk management expected of Agile teams. The goal of Agile teams is not to exclude or eliminate all dependencies but rather to improve workflow and minimise complexity. We stated earlier in the course that Agile encourages simplicity through design. Agile aims, as practitioners say, to ‘increase the amount of work not done’.

Map out some dependencies

Later this week, you’ll create a roadmap for how you can deploy Agile in your team. To help prepare you for this, carry out the following exercise:

1. Brainstorm ten actions you or your team will need to do to deploy Agile in your team. For your team members, this might be ‘Learn what Agile is’, and for you, it might be ‘Prepare a presentation on the benefits of Agile’. Don’t worry about the order just yet, just get down at least ten actions.
2. After you’ve got your ten actions, take another look at them. What is the correct order? Rewrite them in the best order.
3. Next, look at the order and identify the dependencies. What can’t happen unless something else has happened? Draw arrows between any actions that have a dependent relationship. Is there any way to remove that dependency?