Agile Team Structure

In the past, we’ve used component teams in development: teams of people that with generally the same skills. These teams are typically assigned a part of a project to work on.

Bringing these different teams together to create the final product can be a hassle and can result in unnecessary dependency management, overwhelming overhead, and a longer process. Learn how to build Agile teams that are cross-functional and are optimized for an outcome as opposed to output.

Want to know more about forming strong Agile teams? Check out our whitepaper: Build High Performing Agile Teams Through Trust and Alignment

Video Transcription (has been slightly edited for brevity and clarity):

Traditional Horizontal Team Structure

My name is David Hawks with Agile Velocity. And today I’d like to talk to you about agile team structure. I believe that many teams out there are actually struggling to achieve the benefits of agile because their teams are not optimized for delivering value. Here’s what I mean by that: As organizations have scaled, we have created teams horizontally called component teams. These teams are focused on the UI layer, or teams that are focused on the middle tier layer, or teams focused on the backend database layer. When we have teams structured this way, when we get a requirement, one of two things come into play:

• The UI team reads the document and figures out what they need, more than likely they’ll need something from the middle tier team. When they go to make this request, that team has a queue of work they have to wait in. And then when the middle tier team goes to work on it, they probably need something from the database team. The database team also has a queue of work and eventually they deliver something back up to the middle tier and the middle tier delivers something back up to the UI team and eventually, we get something delivered. Hopefully, we don’t loop around in this process where UI says it wasn’t exactly what they needed and they have to go back to the middle tier and the middle tier says we need something else from the database. All along our customer has been waiting for this feature. Do you think the customer is happy with this process? No. It’s lengthy, it takes a long time. The reason why is because there’s a lot of handoffs, there’s a lot of dependency management, there’s overhead in the organization of all the people trying to manage these dependencies. It gets really complex. It takes a long time. It’s error-prone and it doesn’t lead to having the best product possible.
• Another challenge—each team reads the document, it says we need a shape. The UI team knows what a shape is (triangle), the middle tier team knows what a shape is (circle) and the Database teams say we know what a shape is (cylinder). Everybody goes along and works on the project until the end when they try to integrate these pieces. Do you think this goes smoothly? No, not at all. Everyone thinks the project is green and we get to the end and all of a sudden, we go red. We’re banging our heads against the wall because everything didn’t align in terms of our understanding and we find out too late.

So we try to do things where we’re integrating more often, trying to share when having this type of structure. But this structure is focused and optimized for output purposes. It’s optimized to deliver as much UI code and have resources that are working together. So when we think of scenario 1, when we were delivering this thing and the DB team down here, how well do you think the DB team actually understood the business requirements? Probably not at all, but they’re building the best database architecture. Their focus is the output of database code. Or the middle tier team is focused on the output of the middle-tier code.

Agile Vertical Team Structure

We really should be focused on as an organization is not just output, but achieving outcomes. We’re trying to deliver as much value as possible. And in the structure of horizontal teams, we’re not optimized for delivering value, we’re just optimized for delivering stuff. There’s a scary stat in our industry that says 64% of the stuff we deliver is rarely or never used. we’re delivering a lot of the wrong stuff. We’re optimizing for the wrong thing. What agile argues for is cross-functional feature teams, to form teams vertically, that cut through all the layers of the cake. We want to deliver value every sprint. That means we have to break our work down in ways, instead of creating a user story that says “build the database tables of the shopping cart” what we really want is to build a little bit of the shopping cart, “add items to the shopping cart”. A later sprint will deliver “remove items from the shopping cart”.

What we’re focused on is organizing our teams this way—we have this acronym called INVEST part of which stands for independent, valuable and testable. We want user stories and the things teams are working on to be independent, valuable and testable— they have user value, each thing is testable from a user perspective. Building the database tables for the shopping cart wasn’t testable. We could verify it meets the design specs, but we can’t verify it actually solves the user’s problem until we have integrated with these other pieces from the UI and middle tier. It’s not independent, they’re highly dependent on each other. Agile puts people together on the same team that have these dependencies so the people are close together and getting things done. We’re simplifying the communication path by putting the dependent parties on the same team. The verticle teams need to coordinate every day all day. The database people might be on different teams, and they might still need to coordinate, but not all day, every day. We may create a community of practice, for those database folks to continue to stay in sync; we don’t want to end up with 5 different database architectures, but we can do that with less often communication where we want to organize teams focused on outcome and focused on value delivery.