- Separate projects teams doing application development
- Separate BAU teams
- Separate operations teams
- Etc.
So how do we deal with this?
Re-organise to service teams?
Organise teams around end-to-end products or services. These product / service teams would be responsible for app dev, BAU changes, and operations.
Would this work?
Given that one team is handling the lot, we shouldn't have problems with different approaches. But what about interactions between product / service teams?
More significantly, major re-structuring is always a rather crude intervention. It may technically work but is more likely to engender an incredible amount of change resistance.
In most situations, I prefer lighter touches first.
Encourage natural consistency
There are generally two approaches to consistency in ways of working:
- Attempt to impose it via policy
- Encourage it via exposure
Consistency encouraged via exposure is what I call natural consistency:
- Have showcases between teams about how they do things and ideas they have
- Rotate people between teams
- Combine into one team
But natural consistency will not eliminate all variances in ways of working. For that matter, it should not eliminate all variability as we should expect that doing different things requires working differently.
So no matter how naturally consistent we are, we still need to work out how to work together despite our differences.
When we're building services that need to communicate, to send messages to each other, we will be explicit about both the messages and the protocol.
That's pretty much what we can do with teams:
- Agree clearly on how you will work together
- Agree what is part of the protocol (decided between teams) and what is outside (decided within team)
No comments:
Post a Comment