Agile Know-How Magazine • Fall 2017
All multidisciplinary teams
can work autonomously on
the same code base. They
can thus draw from the same
product backlog and collabo-
rate with the same Product
Owner.
For this configuration to be
sustainable, it is important
for all teams to have the same
Definition of Done (DOD). It
is also preferable for the teams to synchronize the code among
themselves as often as possible.
Pros
• Offers great planning flexibility as each team can take any
item without imposing constraints on the sprints’ planning
(either regarding content or duration).
Cons
• Requires great discipline from all the teams to maintain
product integrity. This discipline is usually ensured by a
common DOD.
• Requires to have enough players with the right skills.
Important Consideration
To allow the planning of sprints of different
durations, teams will have to agree on mecha-
nisms for submitting, updating the base code,
integrating, and managing dependencies. What’s
important is to find a way to reduce the inspection
loop between the different teams’ versions to
avoid bad surprises when a team’s code is merged
with the common core.
Play #2 — Component teams
When it is impossible to create multidisciplinary teams due
to the lack of experts or because the skill sets do not easily
combine, component teams can become interesting. There are
two axes along which it is possible to divide the teams: business
activities and design layers.
8
agileknowhow.com
Important Consideration
Multidisciplinary configurations (i.e. Big Team or
Feature Teams) can prove to be difficult to im-
plement in environments that are distributed,
hierarchical, matrix based, or organized by practice
groups or by specialty. In these cases, the compo-
nent configuration will seem more suited.
But be careful not to choose your configuration
only to fit the existing organizational structure. It
could lead to a costly compromise that will deprive
you both from the benefits of Agile approaches and
from those of traditional methods.
For example, for an online purchase solution, a breakdown by
activities would look like this: the purchase process team, the
payment process team, and the delivery process team. As for
the breakdown by design layers, it would look as follows: the
mobile applications team, the web team, the web services team,
and the infrastructure team.
Even though this configuration is useful in certain contexts,
it results in an important constraint: the synchronization of
iterations. Since none of the teams is able to deliver a feature
autonomously, and because we expect to have an increment
abiding by the definition of done at the end of every iteration,
the teams need to coordinate the inter-team work in order to
deliver a single integrated increment at the end of each itera-
tion. Without this rule of operation, the teams risk having a
debt of additional work because the validation of work that is
allegedly done will not be complete before being integrated in a
subsequent sprint.
Pros
• Enables to regroup experts
due to limited resources or for
efficiency.
• Allows a Product Owner to
distribute the burden of pro-
duct backlog management to
other Product Owners.