What Do I Mean by a Complex Product?
The Agile Zone is brought to you in partnership with Hewlett Packard Enterprise. Discover how HP Agile enterprise solutions can help you achieve high predictability and quality in your development processes by knowing the status of your projects at any point in time.
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.
Let's make this look a little more physical than just a matrix in an Excel spreadsheet...
... 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.
Just 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 getting delivered.
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.
The reason 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 the product.