The ‘black mountain’ forced in,
broke Konark’s iron gates,
Drank the water of Mahanadi river,
and ate from the golden plates.
– Narrated by my parents in Odia, loosely translated into English
Growing up, from the above paraphrased poem, I learned of the destruction of Konark Sun Temple in Odisha, India by “Kala-Pahada” (meaning Black Mountain), a person presumably named so for his black deeds. But what inspired and stuck with me is not the destruction of Konark (Kona meaning corner, Arka meaning sun), but its construction.
Destruction is easy, construction is not. Destruction takes minutes, sometimes seconds, but great construction demands tough love, sometimes despair of not knowing the path, but still pursuing the mission. It’s painful, yet beautiful.
The construction of 228-foot-tall Konark sun temple in 13th century was done by 1,200 craftsmen toiling for 12 years to build the monument. A 12-year-old boy, with his knowledge over existing Odia construction manuscripts, gave the final touch to the construction.
Now, any large construction such as the stoneware in Konark, or software as built by engineers, will require scaling. It’s inevitable. This article is about the scaling of teams using the Kanban framework. In this article, we will learn how to build multiple Kanban Boards with the MS Project Agile software tool and how to use these boards across multiple Kanban teams.
To simplify scaling, which is inherently complex, we are going to use the CIPSA framework. The recently launched Certified In Practical Scaled Agile (CIPSA) course uses this framework to manage both Scaled Scrum and Scaled Kanban Projects. Proceeding further with this article, we will use the concepts and examples used in the CIPSA certification course for Scaled Kanban projects.
Our Scaled Scenario – Multiple Kanban Teams
We have three separate teams – Team A, Team B, and Team C – working on different Kanban work items for a Home Renovation Project. All the work items are part of a single Kanban Backlog. However, the team visualizations are different. It’s shown below with various teams working on respective items.
The below video [duration: 5m:25s] prepared in support of this article explains more on the foundational aspects of scaling using Kanban. To get the most out of this article, watch the video before reading the rest of this article. For the best experience, go full-screen HD mode and plug-in your earphones.
The initial plan created for this Scaled Kanban Project is shown below in Task Board Sheet view. Backlog Sheet or Gantt Chart views can also be used to visualize the plan. (click on the image to enlarge)
Each team wants their work to be managed separately to avoid issues with overlapping, resource assignment and tracking. However, there can be dependencies among the work items.
Hence, for each team, we will have individual boards – Team A Task (or Kanban) Board, Team B Task Board, and Team C Task Board. As we have separate boards, we need to have separate filters to segregate the team-specific tasks. Each task added into the overall project plan will have custom fields associated, e.g., if the tasks are for Team A, then they will have associated custom fields.
With this background, let’s proceed and learn how these boards can be used separately by individual teams, Kanban Flow Masters (equivalent to Scrum Masters in Scrum) and Kanban Service Request Managers (equivalent to Product Owners in Scrum) to manage and track the work items.
Scale the Kanban Teams *** UPDATED ***
In our first step, we will create a Team custom field, taking the text custom field for tasks. You can create this field by going to Backlog Sheet (Task Board Sheet) tools > Format tab > Columns group > Custom Fields command > Task custom fields. It also can be done from the Gantt Chart tools.
As shown, we have taken the Text 1 task custom field and renamed it as Team. This custom field will now have a lookup table. The lookup table can be seen by clicking on the Lookup… command button, highlighted above. In the lookup table, will have four values:
- Team A, for tasks assigned to Team A.
- Team B, for tasks assigned to Team B.
- Team C, for tasks assigned to Team B.
- Unknown, for tasks not yet assigned. This will be the default value.
After you have populated the lookup table, it will appear as shown below. Do note that the default one has been highlighted in blue.
The custom field created must be associated with tasks, e.g., Team A field value will be for tasks which will be executed by Team A. Similarly, for others.
I could have used individual custom Boolean flags for three teams, but then it’s not very efficient. What happens when you have three, five, or nine teams? Are you going to add nine flags? You get the idea!
So, next we will associate these fields with the individual tasks of the Scaled Kanban Project. To associate, simply add the Team custom field as one of the columns in the view and choose the respective team, as depicted below.
While I’ve used the Backlog Sheet, you can use any other views such as Task Board Sheet, Task Board, or Gantt Chart view. The custom field won’t be available by default as a column in the tabular part of the view, hence you have to add the related column in order to associate.
Note: There will be other scaling involved with respect to the teams. The above one is with respect to the tasks, not the resources.
--
In the concluding part, we will see the following:
- Scaling of the Filters
- Scaling of the Tables
- Scaling of the Boards
- Another video demonstration – hands-on, practical
Finally, we will conclude with the importance of using a hands-on, practical certification for Scaled Agile and a CIPSA certified professional.
References
[1] *NEW* Certification Course: Certified In Practical Scaled Agile (CIPSA)
[2] New Practical Scaled Agile Framework – The CIPSA Framework Guide
[3] Understanding the CIPSA Scrum Framework – Practical, Hands-on Scrum at Scale
[4] Understanding the CIPSA Kanban Framework – Practical, Hands-on Kanban at Scale
[5] The CIPSA Framework Clock - A Unique Way
