A few months ago I co-authored a white paper (with V. Lee Henson) on the…
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.
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 demand 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. 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.
You should organize around products or features where you can. Organize around subsystems where you have shared functionality. We call these collectively business capabilities. 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 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 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.
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 architecture and organizational architecture. Begin the hard work of breaking dependencies. If not, all you can do is go through the motions of Scrum. Until you do, you will never get the value you are working towards.
The reason you’re not feeling very agile is because you don’t have these kinds of teams. 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.