Before I get on with describing the less-than-ideal organizational models, I thought it would be useful to spend some time describing what the Ideal Team Structure looks like to paint the picture of the target. And what better way to paint the picture than with a picture…
The picture shows an example of two big departments, but this Ideal Team Structure can extend to many, many departments. Within each department, there are one or more Business Intent Generators (BIG’s) where each BIG has one empowered decision maker for the business. Most often, this BIG will play a function as a Product Manager for a line of business. Each BIG has a single backlog that is prioritized by Product Owner which could be a separate person or an additional role played by the BIG. Each BIG’s backlog can be serviced by one or more feature teams of generalizing specialists, sized at 7 +/- 2 people, living and collaborating right with the BIG’s. These feature teams are outfitted with the skills and knowledge to be able to create and modify 100% the system components needed to delivery that business intent.
At some point, the business intent can be larger than the scope of one BIG and takes on more of a “program-sized” look. So, it is inevitable that there will be dependency management across backlogs. If the nature of your product line makes this the case more often, you may want to have a role in your organization that plays the uber-Product Owner with responsibility to coordinate the de-composition of business intent into the BIG’s backlogs, manage dependencies across these backlogs, and set the over-arching priorities at the program level. To that end, the BIG’s in the business might also need to re-organize to help minimize the amount of dependency management required.
To make sure the feature teams are running at peak performance, you need to create continuous improvement teams (see the original overview article). When one or more feature teams come up with a retrospective backlog item that might be too big for them to address in the next iteration, the continuous improvement teams catch this backlog and build the requested support tools and systems for the efficiency and effectiveness of the whole solution delivery organization. Depending on your current needs for development operations tooling, you may be able to have one continuous improvement team service a total of 10-20 feature teams.
So, you might be thinking – this is more complex than I thought it would be. Well, the answer is when you scale your organization to deliver large software systems, the inherent challenge of organizing a large group of people needs to be tackled – regardless of your solution delivery framework. The Ideal Team Structure (ITS) deals with these challenges well to create an organization that flows, has the right teams at the right size and flexible skill sets, and is well supported.
In future articles, I will outline team design patterns that provide an interim stepping stone from a big waterfall delivery organization towards the ITS.
Previous article | Next article
© 2012 CirrusLabs, 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!
