Mike is a certified PMP project manager and a certified ScrumMaster. Mike was involved with the creation of the DSDM Agile Project Leader certification, holds this certification at the Foundation, Practitioner, and Examiner levels. Mike was named an honorary member of the DSDM consortium and served on the board of APLN and the Lean Software and Systems Consortium. He currently co-leads the PMI Agile Community of Practice. Mike is a DZone MVB and is not an employee of DZone and has posted 148 posts at DZone. You can read more from them at their website. View Full User Profile
When we talk about scaling agile... we are really talking about how to
coordinate the activities of many small teams to do the business of the
enterprise. The interesting thing is that we don't have to go from 6-8
people to thousands in one giant intellectual leap. There are plenty of
problems to solve moving from only one team to as few as three or four.
are we going to make sure that each of our teams are working on the
right stuff and in the right order... how are we going to establish
context and coordination? This post I want to explore a few models I've
used over the years to try and solve this problem.
Scrum of Scrums
seems to be the standard answer for scaling agile projects. Do you have
more than one team? Easy... do a Scrum of Scrums. Great... but what
does that mean? Who participates? How often do they meet? What are they
tasked to do? If you have ever tried to answer this question for a real
company... the idea can begin to break down pretty quickly.
simplest implementation of a Scrum of Scrums involves the ScrumMasters
from each of the teams getting together to deal with any
cross-functional issues the teams can't deal with locally. This group
meets daily and answers the same type of questions the team members
answers during the daily stand-up... what did your team do yesterday...
what did your team do today... are there any organizational impediments
that will prevent your team from delivering the sprint? This group
usually meets sometime after all the other Scrum teams have had their
This is a pretty useful collaboration tool if
the teams are largely independent from each other. Remember....
independent means that they share few dependencies. If the teams do not
need to operate in a coordinated fashion, from either a requirements
perspective or a technology perspective, this model can work pretty
well. It can be used to manage minor dependencies, but the goal of the
Scrum of Scrums is primarily to communicate between teams and provide
support for other teams that might be struggling to meet their
Product Owner Team
talked about the idea of a Product Owner team at the single-team level.
We established that the role of the Product Owner was often too big,
and an abstraction of too many roles, for a single person to do
effectively. This is a pretty common problem in a mid-size organization
because there are lots of stakeholders. It is even more common in an
organization when you have more than one team working to deliver an
In this case, you might want to consider
pulling the Product Owner team out of the single team and have them
work across several teams at one time. In this scenario, the Product
Owner team might have a Chief Product Owner, the Project Manager, the
Business Analyst, and UX designers. Just like in the small team
scenario, this team is responsible for grooming the backlog for each of
the Scrum teams and making sure that there is sufficient information
ready for the team to consume during sprint planning.
In this model, each Scrum team would have a proxy for the Product Owner team and likely its own ScrumMaster.
Product Owner team would be a team of its own with a prioritized
backlog and full time team membership although they will likely have
responsibilities outside the team as well. The Product Owner team works
with each of the proxies and ScrumMasters to make sure that they have
sufficient information to act on their behalf. The members of the
Product Owner team are available to all the Scrum teams... just not
allocated full time like the proxies and ScrumMasters.
model works best primarily when its requirements that need to be
synchronized across Scrum teams. You'd probably use this approach with
feature based teams that can work across the entire software stack. We
are in effect building a team of folks that are responsible for all the
requirements decisions that cannot or should not be made at the
individual team level.
Product Owner Team with Architects
is a variation of the Product Owner team that is really geared more
toward Leffingwell's component team model. Because component teams
don't work across the entire software stack... there are technical
decision that will have to be made across teams. Interfaces will have
to be defined... software contracts will have to be established...
complementary technologies will have to be chosen.
Irregardless of component teams or feature teams... I tend to like this model.
my point of view... it is always a good idea to have the technical
folks collaborate with the requirements folks to make sure that the
requirements space and the solutions space are kept in balance.
Technical collaboration with the business is built into the very fabric
of our small team model but has to be explicitly accounted for when we
start scaling technical decision across multiple teams.
like the Product Owner team is responsible for the decisions that
cannot or should not be made at the team level... adding the Software
Architect to the Product Owner team creates accountability for those
technical decisions that cannot or should not be made by the team.
by all means... drive as many technical decisions down to the team as
possible. This group of folks should only deal with the decisions that
you don't want made by the team... because they are bigger than the
team... because they are primarily strategic business decisions
masquerading as technical decisions. I'll also add that these decisions
should not be made in vacuum... they should be made in collaboration
with the teams that are actual doing the work.
you've come this far... you might find yourself in a situation where
you need not only requirements context and coordination... and
technical context and coordination... you might need a team of folks
that can glue it all together once it is built. You need a team that
can integrate the components and you need a team of folks that make
sure it all works together when you are all done. Not a trivial
Context and Coordination
notice in these models... the more dependencies you have... the greater
the context and coordination costs. And remember... at this scale we
are only talking about 3 or 4 or 5 teams.
When you build your
organization around small independent teams... where each team has
autonomy to do what it needs to do to deliver against it's
objectives... you really just have a special case of 'small team
agile'. Product Owner or Product Owner teams don't make all that much
difference to the enterprise. Your concerns are not making sure that
everyone is working on the right stuff in the right order... you are
more concerned with making sure that we are communicating and
cooperating. This is not a trivial problem... it's just that the
solution is not all that expensive.
When you start introducing
dependencies between requirements, you have to make sure that everyone
is working together to build the same product. At this point the
Product Onwer or Product Owner team discussion becomes much more
critical. You need a group of people that are charged with making sure
all the teams are working together to build the right features, in the
right order, and with the right level of common specification. Your
context and coordination costs just went up a notch.
organization is so big, or so complicated, that you are really building
systems of systems... you have a tremendous amount of dependence and
interdependence across the product landscape. Each system may be a
product in its own right and has to balance its own priorities against
the priorities of the cross component features. Its no longer just that
requirements are dependent on each other... your software architecture
and technical infrastructure all has to be aware of what's going on.
Your context and coordination costs have just gone through the roof.
Can this still be agile?
depends on how you define agility. I believe that you can build your
organizations around small self-organized agile teams. Where I get hung
up is on the single wringable Product Owner making all the decisions. A
few posts ago I made the distinction between Product Owners and Product
Ownership. We need Product Owners... but more than that... we need
organizational Product Ownership. Each team can be independent and
agile within the boundaries established by the broader organizational
Agile organizations build capabilities around
small self-managed agile teams. Product Owners and ScrumMasters guide
those teams. That DOES NOT mean that these teams get to build whatever
the heck they want with no guidance from the larger organizational
entity. Product Ownership involves establishing the broader
requirements context and coordinating how our small agile teams work
together to deliver the business value expected from a larger, more