So its one month later… what has happened?
Adaption of board
After 1 week we started adapting the board. The first change we made was to add blocks numbered 1 to 10 in the todo column so that it was clear what was highest priority.
After 2 weeks some more board changes occured…
The second change was to move to a bigger board! We had all the issues that were being worked on pre-kanban on the board, but we excluded them from the limits on the columns. The result was a really messy board.
The third change was to introduce a “parking lot” column. Many issues were with customers or hardware, and they got “blocked” stickies but were holding up the process due to column limits.
The fourth change was to add a swimlane for “pre-kanban” issues. This way we could easily identify the issues with the current support team and those outside of the team.
All of these changes resulted in a much cleaner board, and made adhearing to (and noticing) the limits much easier. One glance at the board could now show bottlenecks easily.
After 3 weeks we held a retropective with a representative from each column attending. In order to get feedback from all people involved we also sent out an email asking everyone who was involved for feedback.
The questioned asked were:
General feedback – overall for the 3 weeks how did you feel about the new support process?
Happy ………….. OK …………. Disappointed
What worked well:
What can be improved:
What doesn’t work:
Important to note is that everyone agreed that making issues and bottlenecks visible on a board works well – better than any previous attempts at managing support items. YAY!
Looking at the data collected we then used dot voting to highlight which problems were most important to the group and thus needed to be addressed first.
Clearing the backlog – Currently the backlog items are piling up as we are limiting how many issues the support developers can look at.
Knowledge Transfer – There are a handful of developers with loads of domain knowledge. As such they do more or less everything around those domains. We need to start the painful prcess of transferring this knowledge. Naturally as the domain expert is not doing the actual work it will be slower. The suggestion here was to try dedicated time from the experts – 2 hours a day for 3 weeks.
Support Process Flow – documented. Whilst the kanban idea was explained to the first group of developers going through it – it has not been explained to the second group, so they were a bit lost for the first day or so. Also the testers in the support team have never worked in an agile way so the stand up routine is still a bit odd to them. We agreed to do a basic diagram of how the board works and what each roles responsibility is. This way anyone can look at the diagram and quickly come to terms with the new process.
One additional small item was actioned:
Template for sticky – each sticky on the board looks slightly different – and it does get confusing. We will put up a template (start date top left, end date top right etc) for people to follow.
What have we done/noticed since?
Our standup process has changed. We were going around the group – each person saying his bit but that meant jumping around all over the board and it was very confusing. After attending a Kanban course our Support Manager made the suggestion of starting from the last column and addressing all tasks there then working our way backwards to the first column. This is much better!
Moving from right to left emphasises the PULL of kanban, we are also able to discuss blockages in any of the columns as soon as we discuss the column rather than waiting till the end of the stand up. After some internet searching I came up with a new format for our stand-ups. This is now printed up on an A3 paper and stuck up next to the board as a reminder.
Another contentious issue is when to do full solutioning, when to apply a quick fix and when to add a change required to the product backlog for the development team to do. We have decided to have this discussion after our first column (Dev Analysis) and present the choices with pro’s and con’s for the Support Manager to decide on.
To add a bit of fun to the board I created South Park characters with some space to scribble your name underneath. We have 3 of each character. So each person on support can pick one that personifies them, add their name to the bottom (it wipes off) and stick that on the tasks they are working on.
We started with 3 developers rotating through support for the duration of a sprint. The idea is to balance this evenly between all 6 development teams and rotate amoungst them so that everyone gets a turn to be in support.
We’ve had some good days and some bad days 🙂 All in all based on feedback and observations we are all getting more comfortable with the new kanban process, and starting to make it work for us.