Software Engineering: Scaling Agile: Architecting Your Team Structure

We all know that in small Agile projects the team structure is simple and easy to understand as small projects need seven to ten team members to form a cross functional team. This cross functional team would have a leader and several team members including developers, testers, business analysts and database specialists for example. According to Scrum, roles such as Product Owner, Scrum Master, Team Members hold good. Also we hear Scrum practitioners saying “Scrum does not talk about Architects or Designers or Testers. All are team members.” Yes. Some agree and some don’t. That’s ok as long as teams exhibit the necessary behavior to deliver what is required to be delivered. How do we structure large-scale agile teams? What behavior do we expect out of these teams. This blog post is about considerations for team structuring in large-scale Agile projects or programs.

Many of us wonder how we get Agile implementation going in large teams. For this, obviously we need to scale up from one cross functional team to many. “Scrum-of-Scrums” – that’s what we hear. It is not as simple as that. It is about scaling up your delivery capability or setting up a delivery engine to adopt Agile methods and deliver large projects. In order to do this we must be able to mention what we need from our proposed large-scale delivery team. That will help us structure the team to satisfy our needs.

So, what kind of behavior or expectations do we have from large-scale delivery teams that implement Agile methods? Here is a list that helped me conceive a delivery engine show above.

1) We need a team structure that can follow Agile principles and practices.

2) We need our team to understand business requirements, decide architectural needs and design optimal solutions – and we need our team to resolve dependencies and create user stories. In this process, our team must be able to develop PoCs on need basis to validate their approach.

3) We need our team to create, maintain and prioritize product backlog.

4) We need our team to implement user stories.

5) We need independent verification to cover various areas of software testing such as functional testing, security testing, performance testing and so on.

6) We need effective build and release management in place.

7) We need a program or portfolio management team – if we need to deliver a program or project portfolio.

8) We need a governance mechanism to provide necessary encouragement, support and timely course-correction so that our delivery engine is functional and capable.

9) We need this system to facilitate coaching on need basis for our team members.

Every structure comes with an associated behavior. This is true for all systems including team structures. Understanding the goals and expected behavior of your project organization and putting together a team structure is a meaningful way to architect team structures that can deliver results. What do you do? Do you follow one of the named methodologies and go by its suggested team structure? or do you think through and architect your team structure?