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
Teams are the Building Blocks of Agile Organizations
you are going to embrace any form of agile, you need to start by
thinking about your teams as the elemental building blocks of your
Teams are Elemental
of whether you decide to organize around feature teams or component
teams, you need to look at the team as the fundamental unit of
organizational capacity. Francois Bachmann from SprintIT has a great
way of saying this... build projects around teams... don't build teams
We've got to stop thinking about how we are
going to resource level across teams... or how to optimize the
utilization of individuals within teams. Instead, let's think about how
we can increase the performance of the team overall. Let's think about
how we can develop better capabilities, greater technical prowess, and
better working relationships between team members.
Great teams deliver great software... period.
the team as the elemental unit of throughput... and knowing that over
time we can establish a stable team velocity... we can begin to think
about becoming predictable as an organization. We can start to see our
teams as the building blocks around which we'll construct our agile
organization. We'll be able to deploy teams of teams that solve our
most critical business problems.
of a team as a black box that has both inputs and outputs. The primary
input to the team is the prioritized product backlog. The output of the
team is working software on regularly defined intervals. In order to
get working software on regular intervals, you have to have a steady
input of prioritized product backlog ready for the team to work on.
is up to the business to normalize the input to the team if they expect
to get a predictable output. If you put crap in the system... you are
going to get crap out of the system. No groomed product backlog... no
So from the teams perspective... all the
normal agile stuff applies. Apply all great engineering practices... do
the visual progress indicators... collocate... have daily stand-up
meetings... do team building... and conduct retrospectives. That is the
stuff inside the box. Regardless of scale... the team is king. They are
an empowered, self-directed, self-manged unit of organizational
Everybody outside the team is responsible for making
sure the teams have the proper inputs so that the business can get
predictable outputs. The business has to act like a UPS that protects
the team from unexpected spikes and brownouts. Scrum calls this
function the Product Owner. I don't care so much what we call it... or
who does it... we just need to make sure somebody or someone does it. Context and Coordination
Regulating inputs to the teams means providing context... what we are going to do and why; as well as coordination... when we are going to do things and in what order.
the past few posts... we established that the Product Owner in Scrum is
the single person that acts as our UPS for the team. We've already
explored how in any moderately complex organization, this role is too
big for a single person to handle. What I am saying here is that naming
a single person to play the role of Product Owner is not nearly as
important as fundamentally making sure that each of our agile teams has
We need stable input so the teams can deliver
predictable and coordinated outputs that align with the broader
organizational objectives. This is not a product owner problem, it is
not a team problem, it is a business alignment problem. Abstracting
this problem behind the Product Owner concept only hides the mess.
problem is further exacerbated as we start putting multiple teams
together in order to deliver on broader organizational objecives.
Remember... the problem is not finding single person to serve as a
Product Owner... the problem is making sure that teams of teams have
proper context and coordination.