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.
Dependencies
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.
