4 Comments
User's avatar
Rodrigo Sperb's avatar

Someone said the quiet part out loud! Indeed - fix the underlying problem, don't blame the signal...

Expand full comment
Bruno's avatar

I agree, given that the teams work is actually more like 'developing a product'. If it's more like 'providing a service' it's a different matter, primarily because of the different nature of uncertainty attached to that. And sadly that crucial distinction got lost in the rush away from projects towards (so-called) products.

Expand full comment
Maarten Dalmijn's avatar

Yes, that's kinda covered in point 3, except I talk about component teams instead of a service team, but the idea is the same. You're serving multiple teams.

Expand full comment
Bruno's avatar

That's true, to some degree. I'd say that component teams are somewhere in between. They - even though they often have more stakeholders - still have more autonomy regarding when to do what kinds of improvements to their component than teams doing primarily service-like work have. At least they can negotiate with their stakeholders, while the reality in more service-like work is, that you either can provide the service NOW or you're considered not being fit-for-purpose. And this in turn injects a kind of uncertainty that's hard to cope with; not to mention what a "goal" for a iteration or increment should be and look like then.

Expand full comment