There are some rules of engagement that need to be considered as the Product Owner…
For now, we need to talk about some basic patterns for scaling agile projects. To talk about how we are going to scale, we need to talk about how we are going to organize. We’ll pull it all back together in a post or two.
Agile software development is all about small teams. So… what is the ideal agile team size? As far as I am concerned there is no hard rule, but most folks I talk with recommend somewhere between six to eight people. Smaller is okay… larger, not so good. There are just limits to how well more than six to eight people can really communicate with each other.
So what happens when you have a project that needs more than six to eight people? Well… you break the larger team up into several smaller teams. Makes sense, right?
To me, this is where agile starts to get really interesting. When you have more than one team working on a single project, maybe even a single code base, what is the best pattern for splitting the teams? There are two primary schools of thought.
Organize Around Features
The traditionally taught… and almost universally accepted… approach for organizing agile teams is to organize around features. For a very thorough explanation of feature teams go find the book “Scaling Lean & Agile Development” by Craig Larman and Bas Vodde. According to Larman and Vodde a feature team is a “long lived, cross-functional team that completes many end-to-end customer features, one by one”.
Highsmith states in “Agile Project Management” that “Feature based delivery means that the engineering team builds [customer centric] features of the final product.” I cheated here a little and grabbed the Highsmith quote from the Larman and Vodde book also. I figured it was okay because I read the Highsmith book too ;-)
Larman and Vodde summarize the ideal feature team as cross-functional, cross component, and co-located. They are working on complete user functionality, the team is made up of generalizing specialists, and typically six to eight people in size. In other words, our prototypical Scrum team.
The authors also point out several challenges with the feature team approach…. which I really appreciated by the way. Common barriers include… concurrent access to code, shared responsibility for design, difficult to learn skills, and organizational structure. Their assertion is that with modern tooling these challenges can be overcome… but it could take years.
I have to admit… this is clearly the most straightforward… and probably most effective way of organizing agile teams… but it makes some assumptions about your teams and your engineering practices. Like all assumptions, these need to validated. For a complete treatment of the feature team concept, go find the book… it is a good read.
Organize Around the Architecture
A more controversial approach to scaling agile teams can be found in Leffingwell’s book “Scaling Software Agility”.
Leffingwell introduces the idea of a design/build/test component team. The component team shares many of the same attributes of the feature team in that it is small and contains all the skill-sets necessary to delivery the user story. Leffingwell’s component team is empowered, self-organized, and self-managing. In short, they are a typical Scrum team. But… and this is a big but… they are working on component features… not end user features.
This is really the exact opposite of what is recommended by Larman and Vodde. A feature team would be made up of specializing generalists from each of the component teams. These specializing generalists would have collective responsibility for delivering the customer centric feature end to end. Not quite the same as a component team, huh? I told you this was going to get interesting.
Where Leffingwell is going… is that at some level of scale… on some projects (let your imagination run wild here)… the system WILL get big enough that a single Scrum team cannot contain enough specializing generalists to cover a single feature. In some systems… not all, but some… we are dealing with a systems of systems. Some organizations… some products… require a systems of system.
Just to be fair… go get Leffingwell’s book too… it is also a good read.
It’s a Tough Call
So… our first really important decision is to figure out if the feature team approach is going to work in our environment or if we need to go with component team model. Personally… I tend to start with the feature team approach and only move toward components if I have to… but the decision is very situationally specific.
To make this decision you’ll have to explore the diversity of your technology… how well your system is designed… what tools you have to manage your code base… the size and competence of your team… how much work the organization is running concurrently… and the quality of your automation.
You’ll need to get real about the politics and power structures in your organization. You’ll need to look at how well, and how empowered, all your cross-functional feature teams can operate. You need to take a hard look at what scale your feature teams WILL break down… at some scale they WILL break down. Is scaling to this level something we need to address now or can it wait?
Next post we are going to explore what being agile means to you. We’ll think about just how agile you want or need to be. There are a few key questions around this topic that you’ll have to ask… and answer… before we can decide how you are going to scale. The post after that we’ll plan to pull it all together ;-)