Note: In the post Enterprise Agility-The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility and the Agile Release Train in a single slide. We repeat it here with an annotation callout.
In this post, we’ll describe the Agile Teams [callout (#1)] that are responsible for creating all that high quality software.
You can see from the graphic that we’ve indicated some number (<=10) of agile teams that collaborate on building the bigger system. Since it’s an agile team, it has a maximum of ten or so members, and includes all the roles necessary to Define/Build/Test (see Chapter 9 of Scaling Software Agility) the software for their component or feature. The roles are Scrum/Agile master, Product Owner and the Team itself. The Team includes fully dedicated developers, test and test automation experts, tech leads, and support from component level architects, SCM/build/infrastructure support personnel, or indeed, whomever it takes such that the team is fully capable of defining, developing, testing and delivering working and tested software for their component into the system baseline.
These teams are most typically organized around a software component or a feature. Most enterprises will have a mix of both, some component teams focused on infrastructure and architectural components, and some feature teams focused on larger scale, current, value-delivery initiatives. Agile Teams are self-organizing and tend to reorganize themselves continuously based on the work in the backlog so the teams are more dynamic than static. (That’s one of the reasons the open space environment works more effectively).
We’ve indicated on this slide that there typically a maximum of 5-10 or so such teams cooperating on building a larger system or subsystem (the system, application or product domain). However, this isn’t a hard or fast rule, but experience has shown that even for VERY large systems, the logical partitions defined by system or product family architecture tend to cause “pods” of developers to be organized around the various domains. This implies that perhaps 50-100 people must intensely collaborate on building their “next bigger thing” in the hierarchy. And as we’ll discover later, this is also about the maximum size for face-to-face, collaborative Release Planning at the system or subsystem domain level. So while this construct and the numbers are somewhat arbitrary, it does track real world examples and is a fairly natural way to organize for large scale agile development.
Of course, even that’s an oversimplification for a really large system, as there are likely to be a number of such larger domains, each contributing to the portfolio (application suite, larger system, or whatever). From a purely mathematical scalability standpoint, ten such domains, each consisting of ten component teams each could be the agile organization containers for up to 1,000 practitioners. In practice, this is about the largest, highly cooperative, development project I’ve personally seen. While there are certainly much larger numbers of practitioners in some really large software enterprises, it is not typically the case that all, or even most, must contribute cooperating code. Rather, it is far more likely that the teams are organized around somewhat stand-alone product lines or applications with relatively thin interfaces.
So this big picture model appears to serve us well in describing an organizational and process model that could work for teams of many hundreds of software practitioners, who must collaborate frequently and intensely to deliver a large scale system in an agile manner. You’ll also notice a Release Management Team a little higher in the graphic. This is covered in Chapter 18 of SSA, and it will also be discussed in a post later in this series.
In the next post (Big Picture #2, later this week), we’ll discuss the heartbeat of the agile enterprise, Iterations.