An agile team is not just any random group of people. An agile team is not a group of business analysts doing a daily standup to coordinate their work. It’s not a group of developers that meet every other week to do sprint planning. It’s not a project team with folks matrixed across two or more other agile teams.
An agile team is a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product. These people are dedicated to the team, and as a rule, do not move between or across teams as demand ebbs and flows.
I’m going to suggest that the very definition of an agile team… a cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of product… 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. In the large, forming a team like this isn’t usually possible, and often if possible, not advisable.
In the large, a product is actually a sub-system of a larger systems integration.
When you look at a product this way, it is often very possible to create a small cross-functional group of people that has everything, and everyone, necessary to produce a working, tested increment of product.
The idea is that you organize around products or features where you can, and you organize around subsystems where you have shared functionality. We call these collectively business capabilities. Once you have the business capabilities understood, you align the business capabilities with the technical architecture and ultimately the organizational architecture.
The intersection and alignment of business architecture, technical architecture, and organizational architecture is where you form a complete cross-functional group of people that have everything, and everyone, necessary to produce a working, tested increment of their part of the product.
Because your business architecture, technical architecture, and organizational architecture are probably broken, you are going to have dependencies between these teams that are going to have to be managed. For now.
Over time, the job of the transformation initiative is to break these dependencies.
Dependencies are evil and they need to be broken.
The more you manage dependencies the less agile you will be, period.
Over time, as you break these dependencies, you will be able to treat each of these teams as pure play agile teams.
Until you start forming teams that align business capabilities with technical architecture and organizational architecture, and begin the hard work of breaking dependencies… all you can do is go through the motions of Scrum. You will never get the value you are working towards.
I’m telling you guys… the reason you’re doing agile and not feeling very agile is because you don’t have these kinds of teams and you have way too many dependencies.
No amount of daily standup meetings is going to fix this problem.
An agile culture won’t do the hard work for you.