ManagementYogi’s Scaled Agile (CIPSA) Certification: Multiple Kanban Teams and Kanban Boards with MSP Agile (2)

In the earlier part, we learned:

• Need of Scaling in an Organization.
• Importance of CIPSA Certification, worlds's only Practical Scaled Agile certification.
• Our Scaled Scenario (Multiple Kanban Teams).
• Scaling the Kanban Teams (using MS Project Agile).

This is the second and concluding part. You can read the earlier part here.

[Part - 1]

--

Scale the Kanban Filters

Our next step is to build custom filters, which will be associated with separate Kanban team boards. These custom filters will have the custom flags enabled for them. The below figure is for Team A Task Board and named as Team A Task Board Tasks Filter.

To create the filter, go to View tab > Data group > Filter > More Filters… command. If you are in the Sheet views for this Scaled Kanban Project, you can select the “Highlight Filter” drop-down list as the default filter option would be disabled.

For the Team A Task Board Tasks shown above:

• Show on Board is enabled.
• Summary (summary tasks) is disabled.
• Team task custom field has the condition fulfilled.

If you want, you can enable the ‘Show in menu’ highlighted above.

Similarly, create two more filters for Team B and Team C as Team B Task Board Tasks filter and Team C Task Board Tasks filter, respectively. You can use the Copy command in the More Filters dialog box to quickly create the filters. After you create all the filters, it can be seen as follows.   

If you have selected the ‘Show in menu’ checkbox while creating the custom filters and it’s a good idea to do so, you can see all the filters under Custom part of the list of available filters. 

Scale the Kanban Tables *** UPDATED ***

In this step, we will create three custom tables and these tables will be applied to the board views that we are going to create. We will learn the steps to create the custom views shortly. To create the tables, go to View tab > Data group > Tables > More Tables… command.  From there create a new table. The below figure is for the Team A Task Board Tasks Table.

As shown:

• The fields are ID, Indicators, % Complete, Work and Board Status.
• If you have used the Copy command to take the elements from the already available Task Board Tasks table (applied to the Task Board view), then remove the Sprint field.

Similarly, create two more tables for Team B and Team C, which are Team B Task Board Tasks Table and Team C Task Board Tasks Table, respectively. Post creation, you will have the tables available under the custom part of Tables drop-down menu. 

Again, though I’ve used the Task Board Sheet view above, you can use either Backlog Sheet or Task Board Sheet view for a Scaled Kanban project. This I’ve explained in my course: Mastering MS Project Agile.

Scale the Kanban Boards

In our final step, we are going to create the Task Board Views for all the teams. To do so, go to View tab > Task Views group > More Views… command. From there, create a new Single View (not a Combination View) from the View Definition dialog box. 

• The view name is Team A Task Board.
• The screen used for this view is the Task Board.
• The filter applied is Team A Task Board Tasks Filter.

Similarly, create two more Task Board views. For Team B, it’ll be Team B Task Board view and for Team C, it’ll be Team C Task Board view. Next, when you assign resources to the tasks and apply the view, the following one comes up, which is for Team C.

Did you notice Team name (Team C) has been highlighted in the cards above? That’s another advantage you can have in Scaled Kanban Projects with MS Project Agile!

For more detailed tracking in sheet views, one can create individual sheet views (e.g., Team A Task Board Sheet view) for each team. Such views can be created in a similar manner as we have created the board views.

Demonstration: Scaled Kanban – Hands-on, Practical

Let’s have a demonstration of what we have learned so far with our practical scaled approach using Kanban to deliver a product or service. The below video [duration: 6m:50s] demonstrates scaling with MS Project Agile. Do not forget to go full-screen HD mode and to plug-in your earphones.

The content of this video has been taken from the Certified In Practical Scaled Agile (CIPSA) course.

Conclusion *** UPDATED ***

Pause for a moment…

Go back 900 years in time and imagine what it would have taken to build something like the Konark Sun Temple with over a thousand craftsmen. The planning, scheduling, tracking and completion would have been a colossal task. But they succeeded.

Remember the 12-year-old kid that we began with?

After completing his work, the young boy jumped into the nearby big ocean giving up his life to protect the reputation of others! Other craftsmen didn’t have the know-how of the final placement of the ‘kalasha’, meaning temple top. But the kid knew and made the supreme sacrifice for his team.

In today’s world, however, with right learning content, certifications and project management software, one can have the know-hows and expertise. As the project manager and hence the leader of your team, many times you plan for and lead multiple Kanban teams, which can be distributed and/or dispersed.

Knowing how to scale definitely helps. As we just learned, MS Project with its Kanban features is eminently capable of scaling to a number of Kanban teams. You can confidently build products or services using the CIPSA Framework, which is based upon Scrum or Kanban features  in MS Project Agile and deliver them at scale in a practical, hands-on manner.

[Part - 1]

This series is concluded.

--

This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away 5 years ago on June 11, 2019. He, along with my mother, Mrs. Bidyut Prava Dash, first narrated the story of Konark Sun Temple to me.

The temple still stands today, nearly 900 years later and is considered to be one of the seven wonders of India. Next to Sanskrit, Odia has the highest number of ancient manuscripts, including construction, among all Indian languages.

--

This article was first published by MPUG.com on 11th June, 2024. This is a refined version.

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

ManagementYogi’s Scaled Agile (CIPSA) Certification: Multiple Kanban Teams and Kanban Boards with MSP Agile (1)

  

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.

This is series [Part - 2]

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. 

[Part - 2]

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

ManagementYogi's Scaled Agile (CIPSA) Certification: Differences – Product Backlog, CIPSA Sprint Backlog and Team Sprint Backlog

Recently, I wrote an article demonstrating Product Backlog, CIPSA Sprint Backlog and Team Sprint Backlog. I also listed out a few differences. In this article, we learn more on these differences for projects using Scrum at Scale and the CIPSA Framework.

I’d strongly recommend that you read the article first here. Alternative link is here.

Now more differences between these backlogs. There can be other differences and by no means these are exhaustive. 

Difference – 1: Creation

The Product Backlog is a single one and stands on its own. The CIPSA Sprint Backlog is prepared from the Product Backlog. The Team Sprint Backlog is prepared from the CIPSA Sprint Backlog.

Difference – 2: Content

The Product Backlog will have the product backlog items. Some of the product backlog items – the high-order ones – will be part of the CIPSA Sprint Backlog. The Team Sprint Backlog will have mostly the tasks which will be executed in the upcoming Sprint.

Difference – 3: Goals

The Product Backlog will have the Product Goal, whereas the CIPS Sprint Backlog will have a CIPSA Sprint Goal. Finally, the Team Sprint Backlog will have the Team Sprint Goal.

Alignment: Related to the goals, we have alignment. The Team Sprint Goal is in alignment with the CIPSA Sprint Goal, whereas the CIPSA Sprint Goal is in alignment with the Product Goal. 

Difference – 4: Dependencies

We don’t note usually note the dependencies in the Product Backlog because is dynamically changing. The inter-team dependencies are usually noted in the CIPSA Sprint Backlog, but the intra-team dependencies will be part of the Team Sprint Backlog.  

Difference – 5: Events and Meta-Events

The Product Backlog doesn’t contain any meta-events. The CIPSA Sprint Backlog will contain meta-events such as CIPSA Sprint Planning, CIPSA Daily Scrums, among others. The Team Sprint Backlog contains team-level Scrum events such as Team Sprint Planning, Team Sprint Retrospectives, among others.

Difference – 6: Ownership

The Product Backlog is owned by the Chief Product Owner (CPO). The CIPSA Sprint Backlog is owned by the entire CIPSA Scrum Team. On the other hand, the Team Sprint Backlogs are owned by the individual Scrum Teams’ Product Owners. 

Difference – 7: Increments 

The CIPSA Integrated Increment comes from the CIPSA Sprint backlog. The individual Team Increments come from the Team Sprint Backlogs. With every integrated increment, we move closer to the Product Goal, which is part of the Product Backlog.

Difference – 8: Lifecycles

Product Backlog is a live document and continuously updated. The CIPSA Sprint Backlog will be for a Sprint and when the Sprint is over, it’s discarded. The Team Sprint Backlog will for a Sprint and when the Sprint is over, it’s discarded.

Difference – 9: Refinement

The Product Backlog is cross-team refined. The CIPSA Sprint Backlog is not cross-team refined. It’s final! Similarly, the Team Sprint Backlog is also not refined. However, there are possibilities of scope changes during the Sprint for both the CIPSA Sprint Backlog and Team Sprint Backlogs. 

Difference – 10: Super- or Sub-sets

The sum of the CIPSA Backlog (considering multiple Sprints) will be a subset of the Product Backlog. The sum of Individual Team Sprint Backlogs will constitute a subset CIPSA Sprint Backlog.

In other words, you can say that the Product Backlog is the super-set, but without the tasks, events, meta-events and other line items. 

The Team Sprint Backlog is the subset of CIPSA Sprint Backlog, but with additional line items. The CIPSA Sprint Backlog is the subset of the Product Backlog with its own line items.

Conclusion

The CIPSA Scrum Framework uses the underlying CIPSA Framework. It’s world’s only Practical Scaled Agile Framework. 

Instead of focusing on theory, theory and more theory, with the CIPSA Certification, you learn how to actually build these backlogs, find out the dependencies, load the resources, solve the overallocations, create a variety of charts or reports, among many others. 

As always, the best time to learn and get certified is now! 

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] The CIPSA Framework Clock - A Unique Way

[5] Scrum at Scale: Product Backlog, CIPSA Sprint Backlog and Team Sprint Backlog with MS Project Agile