Mining Code

Dependency Map Analysis

pen on paper showing a graph
Photo by Isaac Smith on Unsplash

If you’re not up to speed on the concept of dependency mapping, then I’d suggest taking a look at my previous post where I talked through how to go about building a dependency map.

So what happens now? You’ve gone through the workshop and now have a bunch of data that’s telling you what? Something about your system? I’m going to run through some of the actions I take when attempting to understand a dependency map.

A network diagram depicting a dependency map
An example dependency map

Assess the aggregate dependencies

Our first step is to get a clearer aggregate picture of the data so we can assess each team against the others.

We do this by counting the inbound and outbound dependencies for each team and then tallying them. For our simple example above, the output would be a table like the one below. I’ve previously described inbound and outbound dependencies here.

TeamInboundOutbound
Monitoring11
Infrastructure14
Network22
Penetration Testing32
Finance30
Security32
Ops01
Development03
Business10
UI11
UX10

We can now apply some sort of order. When we come to begin resolving dependencies, we want to maximise the complexity we can eliminate while being careful to minimise disruption. A tough ask, but one we can work towards if we remember to maximise outbound and minimise inbound.

Categorise each team from your dependency map

Looking at the above table, we can see that the range is 3 for inbound and 4 for outbound. This then provides a midpoint of 2 for each.

High Inbound / Low OutboundHigh Inbound / High Outbound
Low Inbound / Low OutboundLow Inbound / High Outbound

We’re going to categorise each team into a 2×2 matrix depending on their count of inbound and outbound dependencies. We’ll use the mid-point as an inclusive boundary. Anything higher than the midpoint will be in the appropriate high category.

High Inbound / Low Outbound
Penetration Testing
Finance
Security
High Inbound / High Outbound
None
Low Inbound / Low Outbound
Monitoring
Network
Ops
Business
UI
UX
Low Inbound / High Outbound
Infrastructure
Development

Apply the appropriate strategy

For each category in your dependency map, there is an appropriate strategy to be applied. It’s worth remembering that this is just a guide, there is likely to be an enormous amount of context that isn’t shown here.

High Inbound / Low Outbound

Think networking, these are teams that everyone needs something from, but rarely need to go outside their own team to get something done. If you’re familiar with team topologies, these are classic platform teams. Teams in this situation may find it incredibly difficult to manage their work effectively as they often don’t fully understand how much of a dependency they are on others. They may often find themselves constantly juggling priorities instead of doing value work.

WIP limits cannot safely be applied here without crippling the estate.

The goal here is to help these teams produce self-service tooling and high-quality documentation to minimise the volume of dependencies. It’s likely that these teams have specialist knowledge that doesn’t make sense building in every team. Track the incoming requests in order to look for patterns that show where we should be targeting our efforts.

High Inbound / High Outbound

This one is simple, don’t touch. Yet. While it may be tempting to starting isolating dependencies within your most tangled team, you’ll likely end up crippling another part of the system should you do so.

The impact of this type of team is often felt across the entire estate and requires a significant coordination cost.

We don’t have one in our example but imagine if we had a team called ‘Spaghetti’, which had 5 inbound and 6 outbound dependencies. We like the look of removing some complexity and start to apply practices to isolate that team. While they may now love their additional capacity or skills, the teams which were previously dependent have now become orphaned.

For these teams, we will look to help alleviate their tangled nature by removing complexity from around them first. Work with them to apply good Agile and Lean practices in order to maximise their internal efficiency.

Don’t apply WIP limits here as it will have a similar effect to isolating the team, instead look to apply WIP limits at the boundaries.

Low Inbound / Low Outbound

These teams are generally pretty independent to start with. They should be able to demonstrate good predictability, so applying WIP limits to help manage flow would be a great step. These teams may already be benefitting from Agile and Lean practices.

Look for opportunities to help these teams become the vanguard of change. It is also worth assessing their service to see if they could offer more to customers.

Low Inbound / High Outbound

This is what we’re looking for, teams that we can begin to ring-fence without crippling the surrounding estate. These are teams that often need external expertise, but would not impact the wider business if we started to help them build capability internally.

The key things to look for here are the reasons why.

  • Are they lacking the skills required to execute on their work?
  • Do they need access to specific people outside the team?
  • Is there a technology or policy preventing them from becoming more autonomous?

These are the teams to begin working with as we reduce complexity while building capability.

I ran this in a large financial enterprise and we demonstrated that by isolating a single team from amongst the 30 or so that were present, we could actually reduce overall complexity by a massive 28% across the whole of IT.

Conclusion

For now, this is where my series on building a dependency map will end. We’ve introduced the concept and some new terminology, built one, and then performed some initial analysis.

It is my hope that you are now able to start looking at your system in a new way, pursuing evolutionary change through the reduction of complexity.

I have now run this program in a wide variety of organisations and have seen astonishing results during and after my time there.

If you have any questions, then please get in touch on the right. And if you end up running this, definitely let me know. I’d love to hear how it went.

I work at DevOpsGroup, helping our clients solve complex problems relating to Agile, Lean, culture, organisational design and data-driven business.

Self care when working from home

A working from home setup. MacBook Pro, white ceramic mug,and black smartphone on table
Photo by Andrew Neel on Unsplash

There’s been a deluge of advice on how to survive working from home recently. I almost didn’t bother, so as not to add to the noise. But I figured what the hell, even if one other person can be helped then maybe I should.

I’m a consultant, so work from a variety of places. Home is a common one, often for extended periods of time. Working for an excellent company that is remote first, DevOpsGroup, has given me plenty of time to perfect my pattern. Here are my tips on looking after yourself when confined to the house.

Continue reading “Self care when working from home”

Dependency Mapping

A large number of coloured cables plugged into a machine.

Recently, I published an article where I discussed the concept of dependency as a proxy for complexity. I also tried to show that complexity is the biggest aspect to consider when attempting to improve the flow of value. This is all part of a concept I call Dependency Mapping.

Following publication of the article, I had a few people who read it on LinkedIn reach out for some advice on actually doing it in their place of work. In this article I will dig deeper into the process by which we can start to map out dependencies. With the map completed, we can then work to remove them.

Dependency maps are going to be messy as they try and convey a huge amount of information. We’ll aim small, and then offer some suggestions for improvement from there.

Continue reading “Dependency Mapping”

Why complexity is killing your business

dependent adjective

de· pen· dent | \ di-ˈpen-dənt  \

determined or conditioned by another

If you ask 10 people why Digital Transformations fail, you’ll get 10 different answers, often with phrases like “buy-in” and “culture” thrown around. Although there isn’t a simple answer to this question, I’d like to talk about one that often gets ignored. Dependencies.

You have a dependency if something is contingent on another, here are some examples:

  • “Getting this work complete is contingent on the tests passing.”
  • “We need the platform team to spin up a test environment before we can run the tests.”
  • “We need to have sign-off before we can allocate time to create the instance.”
Continue reading “Why complexity is killing your business”

Penny Flow, an Agile Game

Summary:

This Agile game is based on The Penny Game.  I’ve seen it in various incarnations, but this is based on the original concept.  Instead of simply showing how batch size affects throughput, this game has been heavily modified to give several additional lessons.  Attendees can expect to learn about Agile’s roots in Lean manufacturing, batch size theory, single piece flow, being adaptive to change, quick feedback and communication.

Each round after the first is essentially optional, you can choose exactly which lessons you wish to deliver.  This may be all of them for more experienced teams, or fewer for those new to Agile.

Continue reading “Penny Flow, an Agile Game”

Agile Risk Management

Risk Management is a part of everyday life, crossing the street or even walking downstairs in the morning carries with it some risk factor.  A project is no different.  When projects were managed by default by using high overhead techniques such as PRINCE2, risk was an integral part of running a project; they were cataloged, monitored and actively mitigated through the use of logs and registers.  Many of us have since abandoned these heavy methods in favour of lighter approaches, such as Scrum or Kanban.  However, amid all of the confusion in the revolution, we appear to have thrown the baby out with the bath water.  Even now, risk is rarely included as an active element in our practice, and rarely done well.  I would propose a new method of managing risk, something lightweight that fits with our de facto practices, but with the rigour of the old guard.

What is Risk?

First, let’s define risk.  The ISO31000 standard defined risk as an uncertain event, which should it occur, will have an effect on the project meeting it’s objectives.  Notice the lack of connotation here, risk isn’t some inherently bad thing, it’s simply a degree of uncertainty.  The message is clear, we should be looking for, and actively managing, all forms of uncertainty.

Risk sits in the middle of cause and effect, some cause may trigger an effect, although we don’t know.

Risk Context

Continue reading “Agile Risk Management”

Tracking Agile Projects

Tracking Agile Projects is about monitoring the project health, and checking adherence to the schedule is a relatively simple exercise.  The amount of work actually completed in an iteration is compared with the amount of work expected to be completed.  Differentials are feed back into the amount of work expected to be completed in the future iterations, which has a self corrected effect on the project schedule.

Continue reading “Tracking Agile Projects”

Agile Planning and Scheduling

Agile Planning and Estimating covers the activities involved in actually planning how the software being developed is going to be built, splitting up the development into manageable pieces and deciding a schedule for the release.  This part of my Agile development guide is based on the excellent book by Mike Cohn, Agile Estimating and Planning.

Continue reading “Agile Planning and Scheduling”

Agile Project Initiation

All relevant stakeholders should be present at this meeting, including owner, Scrum master, clients and developers.  For a Scrum overview, please see Agile Overview.  This guide is heavily influenced by Mike Cohn’s Agile Planning and Estimation.

Choosing Themes

At project initiation, the team will meet in order to determine the themes and goals of the project.  In determining these themes, many factors will need to be considered.  These themes will also need to be estimated and prioritised so that the development team knows what to build.  These initial themes will form the general functional requirements for the project and will be expanded upon later on, when more knowledge is gathered about exactly what needs to be done.  The owner will determine the themes, but the developers will aid in this choice.  Developers can help this decision by indicating the risk level or dependencies of each theme.  These themes are often written on Index cards and should be considered at a high level of abstraction, such as:

  • As a user, I require the ability to add new cars so that I can manage my growing stock.
  • As a user, I should be able to buy items using a credit card so that I can process my order quickly and securely.
  • As a user, I want the software to record my high scores so that I can try and beat other scores.

Note that there is no technical specifics here, these are simply general, high level features that the user requires for the product.

Continue reading “Agile Project Initiation”

The Agile Approach

Collaboration

Contrary to traditional management methods, an Agile approach considers the team to be a single cooperative unit.  Individuals are not scored on the amount of work completed, but the team is monitored as a whole.  This serves to improve team cohesiveness and ensure that anyone working on a project is dedicated to the success of a project through collaboration.  You are all in this together.

Product Owner

The product owner is the individual responsible for establishing a common vision.  This person is often the sponsor or customer of the project.  The owner must be the lead in identifying features (Stories) and prioritising the workload such that the highest value is being delivered.

Continue reading “The Agile Approach”