In previous articles, I outlined the guiding principles for organizing agile teams (start here if you haven't started the article series yet) and described the Ideal Team Structure (ITS). This is the first in a series of articles to describe various organizational design patterns to start the journey to the ITS given the real possibility that your large organization cannot switch to the ITS immediately upon starting the transition to agile software delivery.
Given the challenges of an organization of specialists and complex systems architecture, the simplest way to organize your new agile teams is to stuff everyone needed to deliver solutions for the business intent into large (10 – 40 people), dedicated feature teams. The obvious disadvantage is that you are tossing out all the benefits of having small teams (7 +/- 2). First, think of all the communications connections needed for, let’s say, a 30-person team. According to Brooks Law, that would be 435 different communications paths within the team. Second, agile ceremonies, such as sprint planning meetings and daily stand-ups, will most likely turn into arduous, extended grinds with so many people in the room. The other possibility is that these ceremonies happen within the expected time boxes (i.e., 15 minutes or less for stand-ups) but the worth dissipates as people rush past the real value of executing the fundamentals of the ceremonies in order to keep to the time box.
However, engineering is all about finding the best solutions given a set of constraints. If your teams can get past the downsides of a large team, this organization of an agile team may be the best solution for the short term. The biggest advantage of the large team model is that you do not generally have to reach outside of the team to build solutions for almost any business intent. From an ideal delivery flow perspective, keeping the builders of the solution in close collaboration with the Business Intent Generators (BIG’s) is a huge advantage. Because you have almost every skill needed to build the desired solutions, the need for managing dependencies across teams is minimized or eliminated. Most importantly, the large team model does provide a path towards the Ideal Team Structure (ITS). With the mixed skills, application knowledge, and domain knowledge all on one team, team members can pair together and work in less familiar applications to gain a broader set of knowledge and skills. If this knowledge sharing investment is done well, team members can rapidly make their journey towards becoming generalizing specialists while retaining their learning in a knowledge capture platform (i.e., wiki). Before too long, the need for a large team diminishes as the ability of a smaller team of generalizing specialists can now build solutions that used to take a much larger team of specialists.
The key is to not live in the large team model for a long time. You need to clearly plan and execute your people transformation towards creating more generalizing specialists and thereby building for flexible feature teams that are more aligned with a 7 +/- 2 ideal team size. If you are going to try out this model as your interim step towards the Ideal Team Structure (ITS), you need to make sure to put an experienced agile lead (i.e., Scrum Master) in place to help facilitate the team’s activities and minimize the impacts of the large team disadvantages.
If the large team model scares you (and it should!), I will outline alternative agile team organizational models in future articles.
© 2012 AgileTrailblazers, LLC – All Rights Reserved
Interested in training to help advance your agile journey? Click the button to view our current list of public training courses! Use code BLOG10 for 10% off!
