Great advices! I love TT and used it often, although in a mostly eclectic way. One of my favorite part is the mode of interaction. What I found that most managers missed the most about it is that the solution is rarely having a single mode of communication, but rather limiting the high cognitive load modes to 1 or 2 clients and transitioning to low cognitive load modes before switching.
So, if you develop an API, you start doing collaboratively with one client, so that you learn and confirm the needs quickly, then do some facilitations with one or two clients integrating your API the first time, ironing out and automating the process, for finally ending up putting with the API being part of the X-as-a-service offering. The trick is the team is mostly focused on the first part, are available for facilitation on the second part and mostly ensure things are running smoothly on the last part. As a rule of thumb, I recommend something like 60-30-10 or even 80-15-5. The trick is, if the lower items take more than that, you must upgraded them to a higher mode until you can put them back in the background. A team that passed more than 10% of their time fixing bugs in a X-as-a-service mode is inefficient. You should admit the feature wasn't ready for XaaS, select a client which has problems, start working closely with them, and only bring back the previous development feature once the broken feature is in a better step. The first part here, admitting the feature isn't ready, is the most important. Elsewhere, the devs will try, justifiably, to bandaid the problem when clearly, you need more than just a bandaid.
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.
Nicely written with clear solutions. Some of these topologies embedded in our Scrum of Scrum and Safe practices.
Glad you liked it! Thank you, Arvind.
Great advices! I love TT and used it often, although in a mostly eclectic way. One of my favorite part is the mode of interaction. What I found that most managers missed the most about it is that the solution is rarely having a single mode of communication, but rather limiting the high cognitive load modes to 1 or 2 clients and transitioning to low cognitive load modes before switching.
So, if you develop an API, you start doing collaboratively with one client, so that you learn and confirm the needs quickly, then do some facilitations with one or two clients integrating your API the first time, ironing out and automating the process, for finally ending up putting with the API being part of the X-as-a-service offering. The trick is the team is mostly focused on the first part, are available for facilitation on the second part and mostly ensure things are running smoothly on the last part. As a rule of thumb, I recommend something like 60-30-10 or even 80-15-5. The trick is, if the lower items take more than that, you must upgraded them to a higher mode until you can put them back in the background. A team that passed more than 10% of their time fixing bugs in a X-as-a-service mode is inefficient. You should admit the feature wasn't ready for XaaS, select a client which has problems, start working closely with them, and only bring back the previous development feature once the broken feature is in a better step. The first part here, admitting the feature isn't ready, is the most important. Elsewhere, the devs will try, justifiably, to bandaid the problem when clearly, you need more than just a bandaid.
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.