We are embarking on a journey … as with most journeys there is excitement, nervousness and a pinch of fear We are going to use Kanban for our support process. I’m going to blog about the journey – each leg promises to be exciting and full of lessons
“To get through the hardest journey we need take only one step at a time, but we must keep on stepping”
- Chinese Proverb
The current suppport process is not working and we need something else. Kanban was explained briefly and those present are willing to give it a go. This is were I join the journey. I have been tasked with getting the process started – explaining kanban and assisting the support team to get going.
(I have previously blogged about Kanban and I have created a presentation explaining the basics. I also use Kanban for my personal items.)
First things first – we sat together and brain stormed over a whiteboard. “We” included me, the Customer Support Manager and the Senior Test Engineer. We had a basic understanding of the Kanban proposal, and an idea of the first “board”.
We then came up with any problem, issue, thought that we could think of and placed them on the white board. Some of these were easy to explain or deal with – so we chatted about them and moved them off the board.
The majority needed thought and discussions with others – so for now we just “parked” them.
We then moved onto the proposed board – looked at the limits, and looked at a definition of done for each column. Whilst doing this a bunch of new issue stickies were created – and went into the parking lot.
Each of us had some work to do and we decided to start the process in 4 days time. The developers will rotate through the support team, there will be 3 developers allocated at a time, for around 15 days (their sprint duration).
Day 1 – I created the board and had a meeting with all involved to explain what we are doing and how it will work. Our board is based on the kick-start example from Henrik Kniberg.
I gave a brief introduction on Kanban to the support team. We then played the Name Game to illustrate how limiting work in process works. No-one was opposed to the new process, but rather there were concerns about how it would affect individuals.
eg: The 3 developers on the support team have no knowledge of Product X. Some valid points were raised:
- they will be slow at fixing Product X bugs
- the knowledge they gain will be lost as they only work on that product when they are in support thus only every 5 or so months
- they are more concerned about their teams products, than other products (like Product X) which they need to support (The devs work on scrum teams which are product focussed)
We need to try the process and see what other concerns creep out. As with any process, frequent inspection and adaption will need to happen for this to be successful.
The Customer Support Manager will add stickies for his top 10 bugs. The Senior Test Engineer will document and train the necessary people in what needs to be done to meet the “Definition of Done” criteria. And in 3 days time we will have our first stand-up…
Some other reading on Kanban:
Kanban by David J Anderson (book)
Kanban and Scrum – Making the most of both – Henrik Kniberg, Mattias Skarin (book)