Insightful point. I like how you're approaching the ideas shared in the book, like Enabling teams (facilitating mode) should be short-lived, at least for one stream-aligned team. Then we should aim to move into an X-as-a-service mode, making teams more autonomous and scalable. But as you said, that's only possible when a great amount of …
Insightful point. I like how you're approaching the ideas shared in the book, like Enabling teams (facilitating mode) should be short-lived, at least for one stream-aligned team. Then we should aim to move into an X-as-a-service mode, making teams more autonomous and scalable. But as you said, that's only possible when a great amount of collaboration and facilitation has been done and clear and robust "APIs" can be provided.
Thank you! But really, the most important part is how if you suddenly end up passing more time in fixing bugs than working on new features, you need to change your mode of working. That amounts of fixes is a clear sign that something is wrong and the usual "bug fixing process" is usually not enough for tackling this. You need to go back to the drawing board, clear up what the user see and needs, and do the necessary refactoring to put it back in service mode.
And that's pretty much similar to Google SRE process: each service as to reach a specific SLA to be maintain by the SRE team. If it drops below it, the service goes back in the dev team and they have to bring back to the appropriate service level before the SRE team own it again.
Insightful point. I like how you're approaching the ideas shared in the book, like Enabling teams (facilitating mode) should be short-lived, at least for one stream-aligned team. Then we should aim to move into an X-as-a-service mode, making teams more autonomous and scalable. But as you said, that's only possible when a great amount of collaboration and facilitation has been done and clear and robust "APIs" can be provided.
Thank you! But really, the most important part is how if you suddenly end up passing more time in fixing bugs than working on new features, you need to change your mode of working. That amounts of fixes is a clear sign that something is wrong and the usual "bug fixing process" is usually not enough for tackling this. You need to go back to the drawing board, clear up what the user see and needs, and do the necessary refactoring to put it back in service mode.
And that's pretty much similar to Google SRE process: each service as to reach a specific SLA to be maintain by the SRE team. If it drops below it, the service goes back in the dev team and they have to bring back to the appropriate service level before the SRE team own it again.