Posts Tagged ‘task board’

77fb900d0923c2cdff00ab346fa453abOnce upon a time there was a team called the Kanban team. But they didn’t do Kanban. They had a task board and they tracked their work, but that was it. The Kanban team also had a new agile coach. This new coach wasn’t very familiar with Kanban, but did some research and realised that the team was missing some basics. The team met and did some exercises and reviewed their processes and board and made some changes – changes supporting Kanban basics. But these changes didn’t stick. And the team didn’t really like the new board. And the team didn’t feel empowered to improve on the new board. The fact that the lanes were taped onto the whiteboard also meant it was hard to change things on the fly, so in some cases the team could also not be bothered.

The agile coach was frustrated. The team was not learning and they were not growing. Their environment was changing and they were not adapting. They didn’t actually want to do Kanban. They had a broken information radiator. The agile coach decided to watch and wait. The more she watched the more she realised what the gaps were – where the team needed feedback – but she was at a loss as to how to resolve those gaps. She had conversations with certain key team members and stakeholders. She shared her concerns and observations. She created awareness through conversation. However, the team were not yet ready to tackle these things. They needed some guidance and direction. So she waited. And researched. And discussed. And watched some more. And then another agile coach recommended she read “Lean from the Trenches”. And she realised that this was what she had been searching for.

Having learnt from the first attempted iteration of the board, the agile coach decided on a different approach to presenting the changes. Thankfully these changes could coincide with a team reshuffle: the Kanban team would be no more. There would be a new team – a mix of old and new team members. And the incoming team members were familiar with Scrum and simple task boards. This provided a ‘good excuse’ to advocate some changes to the information radiator. So what she did was:

  1. Use the ideas from “Lean from the Trenches” together with her observations of how the team worked and the type of work that they tackled to draft a new task board. She made sure that the new task board still included the information the team found valuable on the current board – even where it was currently hidden or somewhat confusing. She also included some basic changes she hoped would help generate feedback to guide team-driven improvements.
  2. She shared her board with team members individually. She asked them what their thoughts were. She asked them for questions and feedback. She was happy to see that they quickly connected the new and the old and found the new version simpler to understand.
  3. She shared that she was going to remove the permanent lines. The lines would be drawn with whiteboard markers. It would be easy to change the board. Things would be more flexible.

Eventually the big day arrived. The agile coach and one of the analysts mapped the existing stories and tasks to the new board and then the hard work of ripping down the old board began. Come Monday morning, the new board was ready for stand-up. There were still some questions and some of the stories/tasks moved a bit during the session, but even from day one the process was working better:

  1. The team solved discrepancies on the board themselves. With the previous board iteration, they had turned to the agile coach when they had a question or weren’t sure how to use their information radiator instead of finding a solution for themselves.
  2. There were already suggestions from the team around how to tweak the board. They were already taking on ownership of their information radiator.
  3. It was VERY visible that work-in-progress was piling up on one of the key stories – and that there were in progress stories or tasks that were not currently being worked on by anyone.

The key take-aways?

  • Don’t be afraid to try something new.
  • Be ready for failure – ideas won’t always work the first time round, but that’s how one learns.
  • Persevere: if at first you don’t succeed; try, try again.
  • And once it’s initiated, let it go – ultimately the team needs to own the change.

What changes have you struggled then succeeded to make in your team recently? What techniques eventually led to your success?

Learning about Kanban

Posted: March 6, 2014 in Kanban
Tags: , ,

One of the teams I’m newly responsible for is called the “Kanban team”. This made me a bit nervous when I joined as my knowledge of Kanban was completely limited to some reading I did when trying to find a better way to visualise work while a team I was Scrum Master of at my previous company was going through a Lean Start-up phase. The Kanban team appeared to be functioning and was getting stuff done, but I found the board completely confusing and there didn’t seem any easy way to understand inefficiencies. My first task was, obviously, to try to find out a little more about Kanban and understand its principles, and I did this through conversations with colleagues who had been on the training and a lot of Google searches!

The first ‘retro’ I had with the team, I highlighted the main principles of Kanban, which are:

  1. Make workflow visible
  2. Limit work in progress (WIP)
  3. Measure lead time

We agreed that although the workflow was visible (via the board), we were not currently limiting WIP nor were we able to track our lead/cycle times. The first exercise was to review the workflow itself, which we approached with a ‘blank canvas’ approach, mapping the steps various items would go through to eventual release. This team is responsible for maintaining the system on a day-to-day basis, as well as building smaller features, which means some work is very ad hoc and other work is more structured and ‘plannable’.

The second session I presented a proposed version of the board (which was basically the existing board plus some additional columns) plus some suggested WIP limits for us to argue about. After much debate, we eventually agreed on a board that had similar columns to the existing board and was flipped (so that work items bubbled up the vertical rather than along the horizontal axis). The team agreed to track WIP at a ‘story’ rather than task level (although tasks were still added to the board for visibility), and we agreed on some WIP limits. It was a tiring session but it was nice to see the team take some ownership, although it took them at least a week to adjust to the new board once we got going.

Since then, we’ve made some minor changes. I posted up some policies (exit criteria) based on info we had, but we still need time to review and flesh them out (particularly our Definition of Done). I was also trying to track cycle time by tracking when stories moved, but this was proving difficult and time-consuming and prevented the team from moving items backwards (which is something they wanted to do), so we bought a date stamp (like they used to use in libraries) and agreed to stamp stories at three points in the process:

  1. When the story/item hits the board
  2. When it moves into the build phase (starting with design)
  3. When it’s tested and ready for release (done)

We haven’t been tracking tasks long enough to have any useful data yet, so I’ll have to see how this goes. The main thing I have noticed is that the team is still struggling with the concepts of lean, so my next big session will be to a play a game with them (similar to the airplane game) to try to demonstrate how the pull system is supposed to work. I’m hoping that they will then have an ‘a-ha’ moment and we can start focusing on improving our process. Think of it as a change management exercise 🙂

Useful links:

  • I found this comparison of Kanban and Scrum really useful as I could work from my existing knowledge.
  • I liked some of the task board ideas in this article.
  • And, in case you don’t know what it is, here’s more on the Airplane Game.