What Do I Mean by a Complex Product?
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.
Comments (5)
Anonymous
Interesting thought. I realize the scenario and have encountered similar situations.
I'd love to just give you a silver bullet and say perhaps you need to move more toward Lean-Agile or Kanban rather than scrum. But a statement like that wouldn't give anyone any guidance on best to proceed.
I think you started with the right idea: A blended team (pulling members from various products and features). Your question is from which perspective should they develop features/values to the overall products? My answer to that would be the team's perspective. Keep in mind, however, that the product backlog should be organized and prioritized by a Product Owner. And this product owner should have the larger picture in mind.
Now with the largeness of this situation, you could have multiple teams each working on one product. Then you would have a scrum of scrums overseeing the overall integration. This works to some extent. The breakdown occcurs when one team produces many more features than the other products and thus they start delivering lower value features for the overall systems.
One solution to this is to move to a Kanban system for the scrum of scrums. Take a look at which products/features are moving at slower velocity. Have the other teams move in and help the product that either (a) has the highest priority/value backlog list, and/or (b) is experiencing issues that slow down the workflow.
Paul Boos
One thought had is that it may be a communication/ownership issue. The product owner of the Credit Card Processing system, may be in need of being linked in to the Phone Banking team. In order to improve this linking and perhaps make it less intensive on the consumers (i.e. lower level product owners), the planned and actual values could be communicated on some form of big visible chart. I would think Velocity (high level value-oriented features) or Kanban (see where each item is as far as the overall system of systems team thinks it is) would work for a visibility, but this is only a one-way communication. There needs ot be a feedback from the lower level system's team up and how what they are implementing has the linked value. Without this, there will always be a disconnect I suspect.
Mike Cottmeyer
Thanks for the thoughtful reply. I tend to assume that people that read my blog have been reading for a while… I need to put in links to my older relevant posts.
https://www.leadingagile.com/2010/03/how-to-build-a-large-agile-organization/
Check this out… Scrum or Kanban at the team level… Lean portfolio management across the teams. I think you and I are on the same page. The cross functional team won't work and the Scrum of Scrum metaphor is insufficient.
I've been noodling around these ideas for a year or so. Check out some of my earlier posts.
Jessica Wolfe
Hey Mike! The link you provided in the comment above is no longer valid. If you still have this blog somewhere, do you mind sharing? Many thanks!
-Jess Wolfe
Dean Stevens
We have to care about flow – that's a process view.
We have to care about value. That's a vision and prioritization view. What does the team do when the Credit Card Processing is good enough – new features don't add sufficient incremental value? Is the enterprise agile enough to respond to this change?