KanbanThis

Kanban 007

by Sean Brijbasi on 01/23/15

If you work in an organization where you have some autonomy on the project you're managing it's okay to go ahead and implement kanban right in the middle of it. I did it for a QA project I was managing. Even though I didn't have any management authority over the development team (different contractor) I implemented kanban for the QA team within the boundaries under my team's control. Eventually we were able to let the developers in on what we were doing because they noticed an improvement in the overall process. WIP was limited without much fanfare--we just let the developers know that we couldn't do everything they were asking us to do in the amount of time they wanted us to do it and be able to promise the really good work we were doing. We made sure that they understood our commitment to them and the quality of the work we were going to give them. We asked them if we could have shorter releases because it made it easier for the QA team to provide support to the developers and allowed both teams (which were becoming one team) to focus on the tasks that provided immediate value to the users. This had the effect of balancing demand against throughput.

I've sometimes heard Kanban in the context of "managing from the middle" and I thought maybe this sounded a bit derogatory. But when I think that James Bond usually dropped himself right in the middle of whatever trouble needed to be solved and worked his way out instead of trying to solve it from the outside, I think maybe that's not such a bad thing.

I know. James Bond is a fictional character. But I think you get the point.

Comments (0)

Trust in Kanban

by Sean Brijbasi on 01/14/15

The reason that Kanban has worked for me so well is trust. I've found based on my experience that trust is the most important characteristic of high performing teams. Under pressure and during the most dire circumstances, teams whose members trust each other perform at a high level to meet any challenges and overcome any obstacles they encounter. On my projects, one of the ways trust is built among team members is by making policies explicit. No one is surprised. Everyone is treated fairly. With clients trust is built through focusing on quality. The client starts to trust your team. They begin to understand that you share their vision, that you care about their results, and that you're willing to go above and beyond what they even require. Trust among teams and clients is the axel around which successful projects turn. Building trust makes it easier to ask your client about mapping their value stream. Building trust makes it easier to talk to your client about limiting WIP. Building trust makes it easier to suggest more frequent deliveries. Building trust makes it easier to explain how balancing demand against throughput is beneficial to the project. Building trust also makes it easier for your client to say Yes to Kanban.

Comments (0)