Organizational Myopia?
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.
Comments (2)
Steve
Bingo! Now, go back to the sauna and finish articulating the thoughts…please.
Mike Cottmeyer
Hey Steve,
Thanks for the comment. The one point I wish I would have made more clearly is that, when we have a component team in reality… but we 'think' we have a feature team… and we 'talk' like we have a feature team… and we 'write' like we have a feature team… we lose the meaning of the language.
Over the week here in Oredev, one of the speakers was from Nokia… the group that worked with Bas Vodde and Craig Larman… the one that resulted in some of the case studies for Bas and Craig's book where they make a strong case for feature teams. Well… after talking with this guy… I learned that what they were calling a feature team… I was calling a component team.
It all comes down to this… without a CLEAR understanding of context… all these references are meaningless. One man's component team is another's feature team. I believe the lack of context is harming our ability to communicate meaningfully and resulting in some misguided interpretation of 'best practice'.
Anyway… on my way to Denmark!