A physical Kanban board for many teams

As part of our ongoing "Show Us Your Agile Cards" campaign Joern Bock, the VP of AOE, the leading provider of Enterprise Open Source web solutions, gave us a sneak peak of an impressive board and shared some Kanban experience behind it.

A few words of comment from Joern:

The board in the picture is a Kanban board as we used it back in 2010. We were trying to solve the problem of scaling and load-balancing via Kanban at that time and the board was being used by about 20-30 developers, representing several teams. We had separate lanes for all support issues and dedicated, project-related lanes. Specific tickets were being marked by the needed experience, such as front-end, deployment, TYPO3 etc. (we did a lot of TYPO3 back then).

The board represents a typical Kanban following the simple rules „from top to bottom and from right to left“. But we had a handful of special rules as well. For instance, there was no limit per column (state) as it would be expected in a typical Kanban. We had a limit per column and lane – you can spot the little red numbers in the image. Depending on the number of people who where assigned to a project or lane we could modify the limits. Another little thing we introduced was that every ticket had a sticker indicating the number of the week during which it had appeared in our backlog. This way we had a simplified cycle time for every ticket visible on the board.

We also established a process which we refered to as pre-backlog management. Every PO working with the board had his own project-related pre-backlog. Once a week we had a meeting called backlog grooming. During this meeting all of the involved POs would decide which ticket would make it onto the „real“ board backlog, basing on the ticket's business value. For that we had a first iterations-kind-of backlog system: there was a backlog A and backlog B and we were switching between the backlogs every 10 working days. The PO grooming happened only on the „non-active“ backlog. At the same time the "active" backlog would be secured against grooming, so that the dev guys would have a chance to empty it. As an exception, the POs would be allowed to switch backlog A and B tickets before the official "non-active" & "active" backlog switching only if the tickets were of the same size. It may sound complicated, but worked for us.

In the past six years we had implemented Scrum and Kanban is hardly used in development teams at AOE anymore. This board dates back to 2010 and is a significant part of our experience gathered along the way from waterfall model to agile using Kanban and Scrum.

Joern Bock is the VP of AOE, focused on Project Management. Since the early 1990s, Joern has been involved in the creation, design and organization of interactive media projects. At AOE he has been largely responsible for the global project management operations. To this end, he is instrumental in continuously driving the use of agile development methods, such as Kanban, Scrum or Lean as part of an agile organization and a living agile corporate culture.

AOE, headquartered in Germany, is a leading service provider of Open Source Enterprise web solutions.

Join the community & give us some insight into how YOU combine digital tools and paper to make work easy and fun.

Try Agile cards from the Atlassian Marketplace

Share your pro tips and get cool swag for you and your team. Or simply follow us on Twitter to hear about how other teams use Agile Cards.

We use cookies to give you the best experience on our website. If you continue browsing, you consent to the use of cookies.

Ok, got it!