Skip to main content

Dependencies Prevent Agility

A truly Agile team isn’t just any random group of people and it’s not a group of business analysts doing a daily standup to coordinate their work either.  It’s not merely a group of developers that meet every other week to do sprint planning. Nor, is an Agile Team a project team with folks matrixed across two or more other Agile teams.

What is an Agile team?

An Agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product.  Dedicate these people to the team, and as a rule, do not move them between or across teams as demands ebb and flow.

I’m going to suggest that the very definition of an Agile team is getting in the way of forming Agile teams. Mostly, because we misunderstand what a product actually is.

In the small, this guidance is clear, it’s the system.  All the way from user interaction to data and back and all the abilities to deploy and install said product into production. However, in the large, forming a team like this isn’t usually possible, and often not advisable—even if it is possible.

Also, in the large, a product is actually a sub-system of a larger systems-integration.

When you look at a product this way, it’s often possible to create a small, cross-functional group of people that has everything—and everyone—necessary to produce a working, tested increment of product.

Business Capabilities

You should organize around products, or features, where you can.  Organize around subsystems where you have shared functionality. We call these business capabilities, collectively. Once you have the business capabilities understood, align the business capabilities with the technical architecture and ultimately the organizational architecture.

The intersection and alignment of business, technical, and organizational architectures are where you form a complete cross-functional group.  A team of people that have everything—and everyone—necessary to produce a working, tested increment of their part of the product.

Because your business, technical, and organizational architectures are probably broken—you will have dependencies between these teams that you are going to have to manage. For now.


Over time, the job of the Transformation initiative is to break these dependencies because dependencies are evil and you need to break them.

The more you manage dependencies the less Agile you will be. Period.

Over time, as you break dependencies, you will be able to treat each of these teams as pure Agile teams.

Start forming teams that align business capabilities with technical and organizational architecture. Then, you are ready to begin the hard work of breaking dependencies. If not, all you can do is go through the motions of Scrum. Until you break the dependencies, you will never get the value you are working towards.

The reason you’re not feeling very Agile is that you don’t have these kinds of teams.  You have way too many dependencies.

No amount of daily standup meetings are going to fix this problem.

An Agile culture won’t do the hard work for you.


White Paper
Agile Transformation White Paper 75 Min View

Learn what a structured Agile Transformation is supposed to look like.

Transformation Explained 47 Min Watch

Learn how to achieve true business Agility.

White Paper
Clarity in the Backlog 20 Min View

Take a deep dive into how you should go about creating clarity in your backlog.