Inevitably Agile

somethings are just inevitable …

A month into the kanban support journey

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.

Retrospective

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?

Select one:

Happy ………….. OK …………. Disappointed

Other comments:

What worked well:

What can be improved:

What doesnโ€™t work:

Any suggestions:

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.

These were:

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.

Conclusion

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.

Advertisements

6 responses to “A month into the kanban support journey

  1. Karen October 26, 2010 at 2:26 pm

    I have a brilliant technique for clearing your backlog. Apply some blanket rules and close a whole bunch of issues. If they are important they will come back, but at a rate you can deal with. Plus the psychological effect on the team is huge.

    Here are my favourite rules:
    Close all issues in the lowest one or two categories as won’t fix.
    Close any issues that have been assigned to outside of your team for more information as can’t reproduce, ask people to reopen if and when they provide the info.
    Close any issues logged by your internal team, in future fix them when you find them don’t just log them.
    Close any issues older than 3 months, if they weren’t important enough to get fixed in the last 3 months, they probably won’t be in the next year.

    We are down to 67 issues from 600 earlier this year. Our teams think they can make this 0 before the end of the year!

  2. Erica S. October 26, 2010 at 2:50 pm

    Kanban boards are excellent way to control the workload. We usually just load into the first lane the work for the week and try to close all the tasks in one-week iteration. So we have Monday reviews to decide what to pull in this week from backlog and ideas.

    With distributed teams physical boards become a limitation. We are looking into using an online solution, if it’s simple enough… This one seams promising: http://www.getsmartq.com/

    Did you consider using a software kanban board?

    • sam October 26, 2010 at 3:07 pm

      Thanks for the comment ๐Ÿ™‚
      I am not a big fan of electronic tools replacing big visual boards. In my opinion and experience they lead to less conversations happening. That said I am very lucky to only have worked with co-located teams. Please let me know how the tool works for you guys!

  3. Carlo October 26, 2010 at 5:47 pm

    Nice stand up process / rules. Glad to hear things seem to be going well.

    Would have been interesting to see your CFD as well; would help to understand the context of your backlog buildup

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: