On the horizontal level: The team members are of course the main pillar of the board. Everyone of the team should get his or her space to show the running and accomplished work
Kanban in Action
Kanban boards are mostly used in agile software development settings as for example SCRUM. With this method a software team is organized without concrete leading functions. The team organizes itself with specific tools and defined meetings and rules. One tool is the board where the team organizes its shared work packages to accomplish the overall sprint goals. But Kanban boards are not limited to agile software teams, it could be used in production lines, service departments, house construction projets and nearly infinte other use cases. At my company - the Trodat Trotec Group - I introduced the Kanban board method to the entire IT department.
The challenge there was quite specific, so I had to build the method from scratch to adapt it to the concrete requirements of our IT department. This is one of the major advantages of Kanban boards, they are quite flexible and could be adapted right to the context. The IT department was gone through a major change due to the new Chief Information Officer. As a result, the "old" team has to face a lot of new colleagues and unfortunatley also some fluctuation in their team. When new colleagues were entering the "old" team, they were not only new names to remember, but also new mindsets, work methods, processes and of course new team dynamics. Uncertainty and fear were the results and tension in the new team.
To address this, a Kanban board seemed a good choice, because one of the main mechanisms is to provide transparency in who is doing what and why. Another advantage is, that it forges the common team spirit on an unconscious level. The basic layout of the first Kanban draft was as follows:
On the vertical level: The team members can show on colored post-its on what they are working on at the moment, what is currently in testing or review, and what is already done. Later on, the status "on hold" was added, because it appeared that many work packages were stopped by other departments or business decisions. It was helpful to visualize this state too.
On the main board: The work packages of the team members have different colors. The color coding is necessary to differentiate between larger projects, minor change requests or incidents, internal activities for the department and all other work packages that could not be assigned to a color. This type is tracked, because it is never good if team members work on stuff that has no official project, change number etc.
As in the IT department we work in various sections as ERP, eCommerce, Infrastructure, Business Intelligence, Digital Collaboration and so on. So, some work is not interested for all team members. Further, the team members have very different timelines and deadlines in their projects. Thus, the mode of meeting together to discuss every team members' work packages was not on a daily (as usual in SCRUM settings), but on a weekly basis. Each Monday the team gathers around the Kanban board (a standard pinboard) and discusses for maximum half an hour the work of last week and the work to come for the current week. Each team member has about two minutes time. Discussions and questions are allowed, but when it comes to detailed talks between some members of the team they are delayed to after the Kanban board meeting.
The Kanban board and the Kanban meeting are "live" for half a year now. The format is respected by each team member and supports the entire team to understand all activities of the IT department. It should be noted that a critical success factor for keeping a Kanban board alive is a regular facilitator that organizes the meetings. Punctuality, time tracking and steering discussions are necessary items to have a fast and efficient meeting.
Gallery
References
Real-World Kanban: Do Less, Accomplish More with Lean Thinking, Mattias Skarin, 2015
Feedback
Back to top