Why isn’t my Agile working? Dependencies

Agile_Ed
Agile_Ed
Sep 3, 2018 · 4 min read

In my last post I looked at some of the problems teams can have with Scrum that cause them to have incomplete sprints. All of those problems were at the team level as were the solutions for them, but what if you have problems that are outside of the control of a team?

The dependency problem

In an ideal world your development teams (they may be Scrum teams, but not necessarily) would be truly cross functional, meaning that they contain resources that cover all areas of the system so that they can implement any change or new feature front-to-back. In this scenario they don’t have any dependencies on other teams in order to compete their work.

In reality however, organisations usually have teams that are centred around products rather than projects (or features). This means that each product team is going to be focused on their own priorities first, or maybe the priorities of one other team (aka client) who need their help. If a third team have an urgent feature to release that also needs help from that first team, but this additional feature is not on the first teams list of priorities, then you have a problem.

Making features your focus

Given the waterfall background (and top-down “control” management structures) that a lot of organisations have come from it’s not a huge surprise that teams are often focused on products rather than features. And it could be that in some instances this works and makes sense — no approach is a one size fits all solution. But aligning teams by features has some interesting benefits, once those teams are suitably resourced.

An example

Imagine you had the following teams spread across an organisation: sales, marketing, product management, technology, operations. Now say you wanted to introduce a new way of billing customers based on a new sales model. Who owns that? Maybe sales do. But there is a good chance that implementing it will involve all of the other teams too — which will be a lot harder to co-ordinate.

But what if you had a dedicated “new billing” team that was made up of resources from all of those other teams? Now you have a cross functional team who can affect all required areas of the organisation in one go. It’s safe to say that they will be rolling out their new billing feature a lot sooner than if they try to co-ordinate all the other teams.

Small organisations

If your organisation is small this can be a fairly easy thing to fix. You can re-distribute the resources in your product teams into new feature teams so that those teams are cross-functional, and they can then start to knowledge share in order to break down the dependency problem even further (as more people will have the specialist knowledge rather than just one person).

Large organisations

If your organisation is large this could be a harder problem to solve, and as I’ve said before (in this post) this will depend on the top most level of the organisation wanting to push the change through, as this is the only way to break the bureaucracy of such a big shift.

NOTE. There will be harder problems to overcome here that are beyond the scope of this post. You’ll be dealing with established teams, team members ways of working (that they might like), people who have built up their empire over time who are not going to be happy that there is a movement to take it away from them over night, and so on. There are approaches to handling these problems, but they should not be underestimated.

Cross team coordination

These kind of cross functional team structures are somewhere that Scrum can fall down, because specialised control is lost and code bases can become a free for all with everyone making changes.

One way to address this is to introduce the idea of “Guilds” (they may have different names in different places). These are horizontal “virtual” teams across the vertical feature teams that specialise in a particular area or technology. By meeting regularly the Guild can ensure that all of those specialists have a view of what work is being done and they can check that it aligns with the overall strategy / architecture.

The organisation wide backlog

If the top level of the organisation does buy into the change to start working in an agile way then, regardless of the size of the company, they need to put time into creating a single backlog of prioritised work. This may sound like a challenge but it can be done (any many large organisations do). The enormous benefit of this is that not only does any unimportant (or junk) work get raised and become visible, but it gives everyone in the organisation a clear view of the priority of the work to be done. So even if you do still have significant dependencies across teams, everyone will be ready and available to work together because they know that a particular piece of work is the highest priority across the organisation.

Summary

Unfortunately fixing the dependencies problem isn’t as easy to fix as the team problems I covered in my last post, and there isn’t a single approach to finding a solution.

The warning sign here is that big, hard to break dependencies show that your organisation is not (really) working in an agile way, and if there is no movement to resolve the situation then it shows that the organisation is not trying to change / improve either. That may be understood and accepted by the powers that be, but it is going to leave the teams on the ground to try to manage and resolve these dependencies themselves, and without a centralised, agreed and visible list of priorities that is going to continue to be a very difficult situation to manage.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade