Written by Mike Cottmeyer Thursday, 5 November 2009 08:09
Okay… I want to write a quick little post here to point out something that is becoming increasingly obvious to me. I’ve talked quite a bit over the past year about the ongoing feature team/component team debate. We talk about how agile teams are supposed to deliver an end-to-end cross-functional slice of the application architecture. When applications get big, I’ve talked about how sometimes we have to organize around large scale system components or services. So here is the deal… I think that in practice… most people actually get this. It seems that the more I talk to people doing agile in large organizations… the component team model might be THE primary organizational model in the enterprise.
Great right… no debate? Well… actually no. The problem is in the language we are using. If we are only building component features… software that is theoretically ‘valuable’ to the business… we are not building software that is sellable in and of itself. It is only the integration of multiple services or components that our external customers really care about. To some degree we are deluding ourselves about what we are really creating for the business. We get better at building our feature subset… our component features… but as an enterprise we are not getting any better at getting value out of the overall system. We are not getting better at delivering the end-to-end apps that our customers care about.
I think that to some degree we are guilty of a sort of institutional myopia. Because we can’t control anything outside of our team… because we don’t own, or have influence over, the PMO… over management… over the architecture group… over the integrated feature set… we control what we can control… we pretend the rest doesn’t exist. We focus on our team. We desperately want to be good at what we do and we want to deliver value. We want to do valuable work. So what do we do? We change the rules. We redefine value and call it a backlog item. We redefine our customer and call him a product owner. We say that we are delivering working software that our ‘customer’ wants… but at the end of the day… we are just delivering a piece of the overall puzzle.