Dependency management

Dependency management2017-10-12T22:05:28+00:00

What is the problem?

Agile aims to minimise dependencies, but they can’t always be avoided completely.

What is a dependency?

  • Agile assumes that the Core Team is self-sufficient.
    • It has everything it needs to deliver the stories to which it is committed.
    • So the team will not be distracted, interrupted or delayed.
  • But this is not always possible.
    • Especially in a corporate environment.
    • Or a large, complex development programme (including ’Agile at scale’).
    • Where DBAs, UAT teams, PMO, UI/UX design, etc. will normally be shared.
  • Everything the team lacks to get the job done is a dependency.
    • Inputs, information, skills, decisions/authorisations, data, environment, resources, facilities, …
  • Dependencies are a key contributor to the Critical Path.
    • That is, the longest path through the iteration or release.
  • Dependencies threaten to prevent the team from keeping its promises.
    • And to undermine its accountability for delivery.

So to ensure that they can fulfil their commitments, the Agile team needs to manage its dependencies actively.

Why are dependencies a problem?

Why are dependencies a bad thing?

  • They cause overhead.
  • They are inherently risky.
  • They reduce your adaptability.
  • They use up resources & increase your costs.
  • They reduce your velocity.
  • They undermine end-to-end visibility & transparency.
  • They make it much harder to see change coming.

In short, dependencies reduce your agility in almost every way.

Types of dependency

Broadly speaking there are three types of dependency.

  1. Dependencies between stories.
    • E.g., Story A cannot be (fully) implemented until Story B is ready.
    • E.g., a reporting system cannot be fully tested until there is something to report on and somewhere (e.g., a data source) to report it from.
  2. System-level dependencies.
    • That is, a story cannot be (fully) implemented until an architectural or platform feature has been delivered.
    • E.g., a repository, interface, etc.
  3. External dependencies.
    • E.g., A story cannot be (fully) implemented until an outside supplier has delivered a component.

Of course, you can start to implement any of these stories at any time. What the dependency means is that you can’t complete them – and so deliver working software.

Dependencies between stories

Sometimes stories have greater value when another story has already been implemented.

Dependency between Stories

It is important to acknowledge this fact if you are to deliver the maximum value as quickly as possible – a key objective for all Agile development.

So:

  • Where dependencies remain, identify any synergies between stories.
  • Recalculate their estimate & their value based of these relationships.
    • For example, the cost of implementing a Story B may be significantly reduced by the previous implementation of Story A, thus raising its priority.
  • Re-sequence the backlog to reflect this fact.
    • Even if it does not strictly reflect the business value offered by each story in isolation.

But be careful:

  • Only do this if all the stories will be implemented in the same release.
    • Or, even better, the same iteration.
  • Over a longer timescale, there is a real risk that priorities will change before all the stories are implemented.
    • So you will have wasted effort in creating useless capabilities.
  • And avoid implementing later stories simply because they will be cheap to build.
    • That does not mean that they will ever be used!

In other words, this situation creates a real risk that:

  • Your desire to deliver maximum value as fast as possible …
  • … will lead to you delivering things that won’t ever be used.

System-level dependencies

Another scenario is when you have many stories around a single theme, with shared architecture or platform requirements.

System-level Dependency

For example, what if you’re asked for multiple reports – each one a story-sized piece of work? What do you do?

  • Option 1:
    • Recognise the common system needs for all the reports.
    • Build a shared reporting architecture/platform.
    • Then build the individual reports.
  • Option 2:
    • Prioritise the stories individually.
    • Schedule their implementation in order of value.
    • Build only as much architecture/platform as you need for each story.

The answer depends on your attitude to risk:

  • How confident are you that, if you build the ‘system’ first, its high cost but zero value (in itself) will be repaid by the reduced cost & high value of implementing the later individual stories?
  • Or will the system requirements turn out to be irrelevant when:
    • The more functional stories change?
    • Half of the stories are cancelled?

External dependencies

If you depend on another group, how should the dependency be managed?

Dependency on External Groups

A lot depends on who you depend on.

If:

  • Your dependency is on another Agile team…
  • And that team is local…
  • And working on related stories…

Then:

  • Share meetings, collaborate across teams, etc.
  • That is, for the purposes of the dependency, act like a single team.

But if:

  • Your dependency is on the Extended Team or a group completely outside the Agile ecosystem…
  • You may need to set up a formal Dependency Log & manage the dependency in a more traditional way.
  • If you choose this option you may also need more explicit controls to be set up internally.
    • Specific dependency management tasks on the Task Board.
    • A risk or issue log.

Dependency Log

What needs to be recorded in the Dependency Log?

InformationUse
Title
  • Brief summary of the dependency.
    • ‘We need an x from y.’
Deliverable
  • Specific item(s) needed to satisfy the dependency.
    • Product, information, decision, resource, etc.
Function
  • Summary of the need the deliverable will satisfy.
    • And how it will satisfy it.
Dependency with
  • Area the dependency is with.
    • Other project/release, function, external party, etc.
Direction
  • ‘Inbound’ vs ‘Outbound’ vs ‘Exchange’.
Acceptance criteria
  • Specific test, quality measure, approval required before dependency can be satisfied.
  • Which side of the dependency is responsible for meeting each criterion.
Responsible
  • Team member managing the dependency.
Target date
  • By when must the dependency be satisfied?
    • Completion needs to be substantially before deliverable is used.
Action plan
  • Specific steps needed to implement dependency.
  • Include actions, target dates & owner or resource.
Contact
  • Individual on the other side of dependency responsible for ensuring that it is satisfied.
Status
  • Defined, Agreed, Blocked, Satisfied.

Dependency Log workflow

The process of creating and managing a dependency using a Dependency Log is shown here:

Dependency Log workflow

Agreeing dependencies

When agreeing a dependency, it is important to make sure that it is being taken equally seriously on both sides.

To ensure this, make sure that both sides agree:

  • Shared plan of action.
    • Interim actions.
    • Meetings.
    • Checkpoints.
  • Responsibilities.
    • On both sides.
    • Including single points of contact.
  • Escalation.
    • Criteria.
    • Procedure.
    • Route.

And make sure that the agreement is explicit. That is, it should be:

  • In writing.
  • Documented in both sides’ plans.
  • From a suitable authority.

Issues & risks

  • Always minimise dependencies.
    • E.g., refine stories to eliminate dependencies.
  • Do not commit to stories with dependencies you are not sure will be satisfied.
    • Rework the backlog if no other solution is possible.
  • In a complex environment, you may want to have a single, shared Dependency Log.
    • But this can reduce the visibility to a given team’s own dependencies to that team.
    • At the least, it should be possible to filter for each team’s own dependencies.
  • If you have many dependencies, it can be useful to draw a Dependency Map too.
    • Identify the active stories in the current backlog.
    • Lay them out on a separate sheet.
    • Draw lines indicating the dependencies between them.
    • Use the lines to show the type of dependency (Start-Start, Start-End, End-Start, End-End).
    • You may also want to use colours, tags, etc, to group dependencies.
      • Who the dependency is with.
      • Who is responsible for each item.
      • Etc.
  • If similar dependencies persist, restructure teams.
    • So all necessary skills & experience are included.
    • And these dependencies are eliminated.
  • Make sure that the ownership of shared elements is both clear and fair.
    • E.g., designs, architectural components, code, test scripts & data, etc.
  • If your dependencies make it clear that this is a conflict of priorities between the two sides:
    • Negotiate this shared priorities early and agree it directly with the ‘other side’.
    • Escalate quickly if no resolution can be found.
  • Review your dependency log every time the scope of work changes.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?