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 143 posts at DZone. You can read more from them at their website. View Full User Profile
I've been rambling on for the past few
years about agile in larger, more complex enterprises. Quite often in
that discussion, I'll get asked to show a real life example of what I
mean when I refer to a larger, more complex product. I think there are
quite a few folks in our industry that have not worked on products of
this scale, so I think it is a fair question. This post is going to
explore this a bit. A large, complex product is one where many
products are integrated into some larger product that has some distinct
value proposition. The core products are products in and of themselves,
with teams and product owners and revenue projections and customers.
The integrated products also have teams, and product owners, revenue
projections, and customers. The resulting matrix looks
something like this:
In this case, we have several integration products... online
banking, phone banking, payment processing, and remittance processing.
These products leverage payment services, risk services, business
intelligence, and corporate financials. I
want to reiterate... both the products identified in the rows AND the
products identified in the columns have teams, product owners, revenue
projections, and customers. As a company, I sell both dimensions to
different customer bases and different markets.
Let's make this
look a little more physical than just a matrix in an Excel
... and here lies the nut of the issue with the feature team vs.
component team debate. Agile tells us that we have to build a cross
functional team that is made up of individuals from each of the blue
boxes and maybe some folks from the orange boxes. They become a team
and deliver cross-functional features... but from who's perspective?
Which dimension are we accounting for? We need to account for both.
to give you some insight as to the environment... the technologies
involved here included Java and .NET and Cobol; Web Services and
Enterprise Data Warehousing and ERP systems... not to mention that there
is specialized business domain knowledge held by the developers and
analysts in each part of the product organization. At the very least it
is a bit naive to think that we are going to mash all this up and get
hyperproductivity in just a few sprints.
I am all for disruptive
change... but this is the kind of disruption that results in nothing
So what I am saying when I talk about
organizing around capabilities... or services... or components... is to
build agile teams around the sub-products in the organization. You
might also form agile teams around the integration the various
sub-products. The challenge then becomes how you manage the enterprise
portfolio so that all of the teams are in sync and constantly converging
to deliver value along both dimensions of the matrix.
that I think most teams don't get the value from Scrum that they expect
is that they have narrowed their definition of value to something that
they can control.
If I'm part of a Scrum team organized around
the Credit Card Payment Processing engine... and I build a lot of great
features into my product... but the business really cares about the
Phone Banking System... which you are a an integral part, but not the
entire thing.... what happens? Your value is not recognized by the
business... and THAT is the problem. Many of us say we are systems
thinkers... but what system are we thinking about. We
have to care about the flow of value... not features from our part of
Note: These images
were created by a good friend of mine, Brian Sondergaard, who blogs
(sometimes) over at http://blog.
softwarearchitecture.com. He created these pictures for a talk we
did together in DC at Agile 2007 around how to use RUP to scale Scrum.
The 7 or so people that came really seemed to like it ;-)