The Impact Your Teaming Strategy Has on Velocity

Teams in Agile are a very specific construct.

Teams are made up of six to eight people…sometimes a person or two more, sometimes a person or two less…but the idea is that everyone should be able to talk to everyone else and pay attention to what each other are doing. They should be able to work together. They should be able to collaborate with each other. They should know each other.

Teams should have everything and everyone necessary to deliver the stuff that is in their backlog. Whatever it is the team is working on, they shouldn’t have to go outside the team to get to done. That means they should be in control over making and meeting a commitment by the end of the sprint. They have control over their work.

Teams should be dedicated to each other. Dedicated in the sense that they are not assigned to multiple teams at one time. They are not working on multiple backlogs at one time. They are not assigned to multiple projects at one time. The idea is that they should be able to commit to delivering, without concern another project or team will get in the way.

Teams should own the technology they are working on. They have to be the only team working in a particular codebase. Either that or there has to be enough safety in the codebase that the team can make changes without impacting other teams working on the same software. They have to know the impact of the changes they are making at all times.

Teams should be able to establish a stable velocity against a known backlog. Establishing a stable velocity against a known backlog is the only thing that keeps an Agile team on track. It’s the only thing that will give transparency into their progress against the goal. If velocity isn’t stable, you have no idea if you’re on track or not. Period.

The inability to form these kinds of teams is one of the major impediments to adopting Agile.

No degree of mindset shift…no degree of adopting new practices…will make a poorly formed Agile team effective.

Teams that are too small often don’t have everyone they need or don’t have enough people to swarm around problems. Teams that are too large tend to break into sub-teams working on their own sets of work. Communication begins to break down. Teams that are missing key skills can’t get do a definition of done and deliver partially completed work.

Teams with people assigned to multiple teams struggle to make and meet commitments due to conflicting goals, objectives, or priorities between teams. Teams that have deployment conflicts with other teams often introduce problems into the codebase that aren’t detected in the sprint and create work that isn’t captured in plan.

All of this leads to unstable velocity.

Fixing this is the work of the Agile Transformation.

If you don’t fix this, you are just going through the motions of doing Agile.