Have you had that conversation with the struggling team that wants to switch to Kanban? They don't really know why - but they've heard that Kanban will be easier. So why don't they switch processes?
We are failing at Scrum, so let's switch to Kanban!
Does that sentence make sense in your world? I hear it quite a lot. Well not stated that emphatically. In fact, most teams don't know that they are failing at Scrum - but they are... it is such an easy process to follow - how could you fail?
Cutting to the gist of the problem - a team that cannot complete stories in a sprint.... well they are failing. You could ask why they cannot complete stories in the sprint. There may be several legitimate reasons, typically it is an impediment beyond their control. Something like getting "sign-off" from some stakeholders that the feature desired works as expected and doesn't break anything else. When you see this "reason" and investigate it - you will typically run across the deeper true reason... lack of trust.
Let's leave that overt reaction to something that's happened in the past that caused this - trust response called, sign-off required, to another time. Let's focus upon the current trust response... switching processes because we cannot be successful with the current process.
As a transition guide, this is one of those dialogues I wish to avoid because it may appear that I enjoy the chaos of the team failing. A team that is failing, knows it, and is still trying to fix things is one that has hope, it is a team I can work with, it is a team that needs to go back to the very basics of software development. Learn to control their environment. Practice the discipline of changing ONE known thing at a time and building their product with this ONE difference. Then testing their product with this ONE known change to see the expected effect upon the system.
A team lead that understands this and expresses the desire to build this capability in the team, and acquire the infrastructure (such as testing tools, and environmental controls such as DB migration scripts) to practice the discipline is a pleasure to work with.
So what are the legitimate reasons to switch to Kanban?
I will leave that to you dear reader... tell me in the comments....
I'm pondering a different question - how does a team re-build trust with its stakeholders?
We are failing at Scrum, so let's switch to Kanban!
Does that sentence make sense in your world? I hear it quite a lot. Well not stated that emphatically. In fact, most teams don't know that they are failing at Scrum - but they are... it is such an easy process to follow - how could you fail?
 |
| More Prescriptive -to- More Adaptive |
Let's leave that overt reaction to something that's happened in the past that caused this - trust response called, sign-off required, to another time. Let's focus upon the current trust response... switching processes because we cannot be successful with the current process.
As a transition guide, this is one of those dialogues I wish to avoid because it may appear that I enjoy the chaos of the team failing. A team that is failing, knows it, and is still trying to fix things is one that has hope, it is a team I can work with, it is a team that needs to go back to the very basics of software development. Learn to control their environment. Practice the discipline of changing ONE known thing at a time and building their product with this ONE difference. Then testing their product with this ONE known change to see the expected effect upon the system.A team lead that understands this and expresses the desire to build this capability in the team, and acquire the infrastructure (such as testing tools, and environmental controls such as DB migration scripts) to practice the discipline is a pleasure to work with.
So what are the legitimate reasons to switch to Kanban?
I will leave that to you dear reader... tell me in the comments....
I'm pondering a different question - how does a team re-build trust with its stakeholders?
Comments