Showing posts with label Kaban at Scale. Show all posts
Showing posts with label Kaban at Scale. Show all posts

Wednesday, July 16, 2025

Practical Scaled Agile (CIPSA) Certification: The Principal Flow Master (PFM) – What It Is and What It’s Not!

 

In the CIPSA Kanban (not Scrum!) Framework, one key primary role is that of the Principal Flow Master (PFM). Very few Scaled Agile frameworks, if any, support team-level Kanban. CIPSA is unique not only in its practical, hands-on, tool-driven approach but also in its support of Kanban.

As the PFM role is new and not available in most Scaled Agile approaches, it is often misunderstood. Note that this role is unique to CIPSA certification.

In this post, we will learn more about the PFM role and how it differs from the individual team-level Flow Master. In addition, we will explore what this person actually does. This post explains “what it is and what it is not” to bring more clarity.

To read all articles of this series use this link: What It's and What It's Not series for CIPSA.

Among many, following are a few.

Principal Flow Master – What It Is and What It’s Not

1. Not a Manager, but an Enabler: The Principal Flow Master is not the manager of flow for the CIPSA team. The Principal Flow Master enables the flow for the CIPSA team.

This role of the PFM is not about command and control, but about creating the conditions for flow to happen naturally for the CIPSA Kanban team. 

2. Not Intra-, but Inter-team: The Principal Flow Master is not concerned about intra-team bottlenecks. The Principal Flow Master is focused on inter-team bottlenecks (in flow).

The focus of the PFM is on how teams interact, not how they operate individually. The PFM looks for inter-team bottlenecks and works to remove them. 

3. Not Team Metrics, but Product Flow: The Principal Flow Master does not track the individual Kanban team Increments. The Principal Flow Master tracks the overall product work and progress.

The PFM does not micro-manage team Increment or team-metrics, and indeed, he or she plays no role in that! The goal is to maintain visibility into the flow of value at the product or system level.

4. Not Local Fixes, but Systemic Resolution: The Principal Flow Master does not check for the issues and impediments within individual teams. The Principal Flow Master ensures resolutions of cross-team issues and removal of cross-team impediments.

It’s well-known in management that local issues are best handled by the team itself. The Principal Flow Master, on the other hand, focuses on complex, multi-team issues that block the CIPSA Team’s overall flow.

5. Not Individual Team Risks, but Cross-team Risks: The Principal Flow Master is not concerned about individual risks arising within individual teams. The Principal Flow Master is focused on cross-team risks.

Cross-cutting risks can impact multiple areas and jeopardize delivery. It’s the job of the PFM to manage the. By managing them, the CIPSA Team can have smoother coordination and predictability.

6. Not Setter, but Facilitator of WIP Limits: The Principal Flow Master does not set the work in progress (WIP) limits. The Principal Flow Master supports the team in deciding the WIP. 

WIP can be set for the workflow states in the CIPSA Kanban Board. The CIPSA Team is trusted to self-regulate their capacity. The PFM’s role is to facilitate, not impose it.

Principal Flow Master – Summary Table

The following table contrasts common misconceptions with the true nature of the role of PFM, highlighting key differences in focus and approach. 


Live Video Explanation

For the PFM role, I've prepared the below video [duration - 13m: 30s]. I've also explained the false pride in having "branded" certification. A certification should be useful to you. Watch the video alongside this article for a better learning experience. Plug-in your headphones and go full-screen HD.


Conclusion

The Principal Flow Master (PFM) plays a facilitative and enabling role, rather than a directive or managerial one. The PFM’s focus is not on managing individual teams or resolving team-specific issues, but on fostering cross-team alignment, enabling flow, and removing bottlenecks that hinder the CIPSA team’s ability to deliver.

Just as the Principal Scrum Master (PSM) is a key role in CIPSA Scrum (see here), the PFM is also a vital and indispensable role in CIPSA Kanban. Like the PSM, the PFM is a leader who servers the CIPSA Kanban team. However, unlike the Scruma@Scale+CIPSA mindset for the PSM, the thinking here for the PFM must be rooted in Kanban@Scale+CIPSA mindset.

The above list of “what it’s and what it’s not” is a partial and brief one. 

  • Want to learn more with hands-on practical software tools?
  • Want to know how the PFM is assigned and part of the Flow Master group?
  • Want to visualize the workflow across the Integrated Kanban Board at Scale?
  • Want to build the Cumulative Flow Diagram (CFD) at Scale?
  • Want to resolve overallocations for Kanban at Scale?
  • Want to determine the Work in Progress Limit (WIP) at Scale?

To gain in-depth knowledge on all the above and more, consider being a CIPSA! You’ll learn Kanban at Scale in a hands-on manner with direct usage of software tool. The course is thoroughly practical and highly economical.  


CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not - CIPSA

CIPSA Sample Videos and Questions:

[1] CIPSA Sample Video List (Choose a Video)
[2] CIPSA Video Playlist (Complete Playlist)




Sunday, June 01, 2025

Practical Scaled Agile (CIPSA) Certification: The CIPSA Team – What It Is and What It’s Not!


The concept of the CIPSA Team is new, but it's explained as part of the CIPSA Framework Guide. You'll also get a complete hands-on  demonstration of it in the CIPSA certification course. The guide defines the CIPSA Team as follows:

“The CIPSA Team is the sum of all individual teams. This team consists of the CPO, PSM (or PFM), POs, SMs (or FMs), and most important of all, the developers, who are generalizing specialists.” 

The guide is available for free download – no sign-in required. Download here.

In this article, I'll explain more clearly the aspects of the CIPSA Team. An in-depth explanation with hands-on demonstration is part of the CIPSA Certification course. You’ll learn practically with software tool:

  • How to have resources for the CIPSA Team. 
  • How to segregate and distribute resources across individual Scrum or Kanban Teams.
  • How to organize resources into various groups (very important for reporting).
  • How to create and apply custom groups for the resources.
  • How to assign and move various resources efficiently.
  • How to resolve overallocations in the CIPSA team.
  • How to track individual Scrum or Kanban teams as well as the entire CIPSA team, among others.
Learn more here. With this course, you will have mastery over scaling using Agile approaches.

There are many important differentiations. The following are some of them. To read all articles of this series use this link: What It's and What It's Not series for CIPSA.

CIPSA Team – What It’s and What It’s Not!

1. Not Many Teams, but One Team: The CIPSA Team is not just a sum of individual Scrum or Kanban teams. The CIPSA Team is a single, cohesive unit.

The CIPSA Team isn’t just a group of separate Scrum or Kanban teams working in parallel. It acts as a unified, cohesive team aligned toward a common purpose and goal. See the next point!

2. Not CIPSA Sprint Goal, but Product Goal: The CIPSA Team's final goal is not the CIPSA Sprint Goal. The CIPSA Team's final goal is the Product Goal.

While individual Scrum teams may focus on respective Team Sprint Goals, the CIPSA Team is aligned with the overarching Product Goal - not the CIPSA Sprint Goal. This ensures long-term value delivery.

Similarly, for CIPSA Kanban, it'll be Product Goal, not CIPSA (Kanban) Goal or individual Team Goals.

3. Not Task-Focused, but Goal-Focused: The CIPSA Team is not task-oriented. The CIPSA Team is goal oriented. 

Considering the CIPSA Scrum framework, the short-term goal for the CIPSA Scrum Team is the CIPSA Sprint Goal and for long-term it's the Product Goal.

The focus of the CIPSA team is not on completing tasks for the sake of activity. Rather, the CIPSA team focuses on achieving meaningful Product Goals. Remember there can be more than one product goals.

4. Not Untested, but Tested Value: The CIPSA Team's Integrated Increment is not untested. The CIPSA Integrated Increment is tested, integrated, valuable, and usable.

Work delivered by the CIPSA Team is not just an assembled output. The CIPSA Integrated Increment tested, integrated and valuable from the customer’s point of view.

5. Not Role-Bound, but Collaborative: The CIPSA Team is not bound by job descriptions. The CIPSA Team is collaborative and utilizes practices like swarming and mobbing.

Team members in the CIPSA team aren’t limited by rigid job roles. They collaborate freely using practices like swarming and mobbing to solve problems. Swarming and mobbing are Agile practices and can be used at scale.

6. Not Managed, but Self-Managing: The CIPSA Team is not managed by the Principal Scrum Master or Principal Flow Master. The CIPSA Team is self-managing. 

The team doesn’t rely on top-down control. It organizes itself with support and with facilitation by the Principal Scrum Master (PSM) or Principal Flow Master (PFM).

7. Not Short-Term, but Long-Term: The CIPSA Team is not a short-term team. The CIPSA Team is long-term.

This is not a temporary setup that gets disbanded after a goal, i.e., the CIPSA Goal. That may happen in a traditional project, which can be temporary. The CIPSA Team is a stable, long-term team focused on continuous product delivery. It exists to meet the Product Goal – one at a time.

CIPSA Team – Table Representation

Now, we can have the above points represented in a table. It’s easier to read and remember. 


Concluding Remarks

The CIPSA Team itself is the soul of the CIPSA framework. It’s the team that breaks the features down into tasks and execute those tasks. Without the team, there is no CIPSA Integrated Increment – one that finally matters to the customer or user.

As a CIPSA-certified professional, or an aspiring one and a Practical Scaled Agile Practitioner (PSA) you need to know the above fundamentals about the CIPSA Team. 

This article touches upon and highlights a few aspects of CIPSA Team. To dive deeper and gain practical, real-world expertise, becoming a CIPSA professional is your next step. It’s a great way to get the most value from your investment.


CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not Series - CIPSA

CIPSA Sample Videos:

[1] CIPSA Sample Video List (Choose a video to play)
[2] CIPSA Video Playlist (Complete playlist - play all)

CIPSA Sample Questions:



Sunday, May 25, 2025

Practical Scaled Agile (CIPSA) Certification: CIPSA Integrated Increment – What It Is and What It’s Not


As the CIPSA Certification and Framework were getting prepared with inputs and feedback from many Practical Scaled Agile practitioners, one of the key reviewers asked:

“There are key artifacts in the CIPSA Framework. In your view, however, which is the most important one, and who owns it?”

The most important artifact is the CIPSA Integrated Increment. No other artifact can replace it or even come close. I’ve emphasized this in the CIPSA certification course. See here to know more.

When applying Agile at scale with the CIPSA Framework, it’s essential to clearly understand the concept of the Integrated Increment. Unlike team-level Scrum or Kanban, where individual increments are delivered, the Integrated Increment is a different concept at scale. 

I believe the following points will help. These are applicable for Scrum at Scale or Kanban at Scale with CIPSA, though in some points CIPSA Scrum is used. 

Next, let’s go through the points for the CIPSA Integrated IncrementTo read all articles of this series use this link: What It's and What It's Not series for CIPSA.


CIPSA Integrated Increment – What It’s and What It’s Not

1. Not Optional, but Required: The CIPSA Integrated Increment is not optional in a Sprint (or Release). At least one CIPSA Integrated Increment has to be given every Sprint (or Release)

At least one CIPSA Integrated Increment has to be given every Sprint (or Release). It is a mandatory outcome that ensures continuous delivery every Sprint (or Release). If you skip this delivery, it’ll undermine the goal of transparency and progress.

Note: Release is for Kanban at Scale with CIPSA.

2. Not Accepted, but Done: The CIPSA Integrated Increment is not about meeting acceptance criteria. A CIPSA Integrated Increment is borne when it meets the DoD.

The CIPSA Integrated Increment is borne when it meets the Definition of Done (DoD). CIPSA team's work completion is based on meeting the shared DoD, not the Chief Product Owner's (CPO) approval. This ensures consistency and quality.

For Kanban, again, it’s not the Chief Service Request Manager’s (CSRM) approval. 

3. Not at Sprint (or Release) End, but Anytime: The CIPSA Integrated Increment is not delivered only at a Sprint’s (or Release) end. It can be given before. 

The CIPSA Integrated Increment can be given before the end of the Sprint or Release. However, delivery can occur at any point during the Sprint (or Release) as soon as it's done. This enables feedback and better validation.

4. Not Team Review, but CIPSA Review: The CIPSA Integrated Increment is not validated in individual reviews. It’s done as part of the CIPSA Review.

The CIPSA Integrated Increment is reviewed in the CIPSA Sprint Review 0r CIPSA Review for Kanban. CIPSA Sprint Review happens at the system level, not in individual team reviews. This ensures integrated value is validated collectively. 

5. Not Isolated, but Integrated: The CIPSA Integrated Increment is not an isolated work item. The CIPSA Integrated Increment is the sum of all.

The CIPSA Integrated Increment is the sum of all integrated work coming individual Scrum teams (or Kanban teams). It's not valuable in isolation, rather it must represent a cohesive, working whole. 

Such an integration ensures cross-team functionalities are truly captured.

6. Not multi-Sprint (or Release), but Per Sprint (or Release): The CIPSA Integrated Increment does not come from multiple Sprints. It has to be delivered at least once in a Sprint (or Release).

The CIPSA Integrated Increment has to be delivered at least once in a Sprint. It must be delivered within a single Sprint, not across multiple ones. Unlike many frameworks, where an increment is given after multiple Sprints, the CIPSA Integrate Increment has to be delivered at least once in a Sprint. This is a key distinction. 

This enforces regular integration and early problem detection, if any. For Kanban at Scale, it must be given per Release. 

CIPSA Integrated Increment – Summary Table

To quickly and easily recall the key points, you can refer to the table below. It summarizes the main aspects of the CIPSA Integrated Increment. 

Concluding Words

Remember the first question from a reviewer that we started with?

The CIPSA Integrated Increment is most important artifact because of the principles of Agile manifesto. In fact, the first principle is:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

You can replace software with product or service. When you go through the principles of the Agile Manifesto, the consistent focus on the delivery of the product or service. 

This article articulates only a few of the points related to CIPSA Integrated Increment. If you want to learn in-depth and in a practical, hands-on manner, consider becoming a CIPSA professional. 

You’ll find the best possible return on your investment. The course comes with a full money-back guarantee. See here to know about the guarantee.


CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not Series - CIPSA

CIPSA Sample Videos:

CIPSA Sample Questions:


Wednesday, May 21, 2025

Practical Scaled Agile (CIPSA) Certification: What CIPSA Scaled Kanban Is and What It’s Not!


The Certified In Practical Scaled Agile (CIPSA) framework and certification are not only radically different from other frameworks, but it also supports Scaled Kanban. Like Scaled Scrum with CIPSA, Kanban at Scale with CIPSA takes a direct, hands-on, and practical approach to scaling. Indeed, it's one of very few scaled agile frameworks, which truly supports Kanban. See here

The CIPSA Kanban Framework is unique and completely different, there can be certain mis-interpretations about this framework. This post informs – what CIPSA Scaled Kanban is and what it’s not. 

Some of the below differences can be applicable for the CIPSA Scrum Framework.

Now, let's see the unique aspects of Kanban at Scale with CIPSA, one-by-one. To read all articles of this series use this link: What It's and What It's Not series for CIPSA.

CIPSA Scaled Kanban – What It's and What It's Not!

1. Not Speed, but Flow: CIPSA Scaled Kanban is not about working faster. CIPSA Scaled Kanban is about managing flow effectively and efficiently across multiple teams.

CIPSA Scaled Kanban doesn’t mean pulling all the work items and rushing you work at every opportunity. It focuses on smooth, predictable flow across teams to maximize delivery efficiency.

2. Not Sprint, but Release: CIPSA Scaled Kanban is not about Sprint(s). CIPSA Scaled Kanban is about Release(s) based on a cadence.

CIPSA Scaled Kanban doesn’t rely on fixed-length iterations like Sprints as in Scrum. Rather, it enables flexible releases aligned to cadence and flow readiness. Cadence is set by the execution of the meta-events in CIPSA Scale Kanban.

3. Not Static, but Dynamic: CIPSA Scaled Kanban is not about static boards. CIPSA Scaled Kanban is about dynamic, evolving systems with dynamic board reflecting actual value streams.

Boards are living systems that evolve to reflect real, changing value streams while using the CIPSA Scaled Kanban framework. Hence, when you with CIPSA Scaled Kanban approach, it’s not limited to static Kanban boards that rarely change.

4. Not Ceremony, but (Right) Metrics: CIPSA Scaled Kanban is not driven by ceremonies. CIPSA Scaled Kanban is driven by flow metrics and just-in-time (JIT) demand.

While Scrum is semi-JIT approach, Kanban is a full-JIT approach. Work is pulled based on flow metrics and just-in-time demand, not scheduled rituals. CIPSA Scaled Kanban is not rigidly dependent on recurring ceremonies to drive progress. 

5. Not Output, but Throughput: CIPSA Scaled Kanban is not about maximizing output. CIPSA Scaled Kanban is about optimizing throughput (a Kanban metric) and cycle time (another metric) for customer value.

The aim in CIPSA Scaled Kanban is to improve the key Kanban metrics—like throughput and cycle time. The goal is to deliver true value. It’s not about churning out as many tasks as possible.

6. Not Batch-Planning, but JIT Pulling: CIPSA Scaled Kanban is not about batch planning with timeboxes. CIPSA Scaled Kanban is about flow-based-planning and just-in-time pulling of work items.

With CIPSA Scaled Kanban, work is planned and pulled as needed, supporting continuous flow and agility. Remember, as I said earlier, Kanban is a full JIT approach. You don’t plan large batches of work into fixed timeboxes.

7. Not Iterations, but Flow: CIPSA Scaled Kanban is not about iterations or Sprints - it's not based on them. CIPSA Scaled Kanban is about continuous delivery with real-time progress visualization.

Instead of fixed iterations like Sprints, CIPSA Scaled Kanban enables real-time progress and delivery, with work flowing continuously.

8. Not Complexity, but Simplicity: CIPSA Scaled Kanban is not about complexity. CIPSA Scaled Kanban scales to any complex domain where flow and coordination critical.

The CIPSA framework is very simple, so also the CIPSA Scaled Kanban. It's not at complex, but easy to adapt and adopt. It scales simply and effectively across any complex domain where coordination matters.

9. Not Team-Cadence, but Rhythm at Scale: CIPSA Scaled Kanban is not just about team-level cadence. CIPSA Scaled Kanban synchronizes rhythm across teams through scaled meta-events based on cadence.

CIPSA Scaled Kanban synchronizes cadence across teams via meta-events for alignment. It doesn’t stop at individual team rhythms or workflows.

10. Not Tool-Dependent, but Tool-Agnostic: CIPSA Scaled Kanban is not dependent solely on MS Project Agile software tool. CIPSA Scaled Kanban can work any capable software tool that supports Kanban scaling features.

Table Representation

For CIPSA Scaled Kanban, one can put the "what it's not and what it's" into a table. It'll come as shown below. It's also easier to remember considering Kanban at Scale.



Conclusion

CIPSA Scaled Kanban works with any robust software that supports scaled Kanban features and functionalities. It’s not locked into one tool like MS Project Agile. Any software supporting scaling features can be used.

CIPSA Scaled Kanban is not merely a scaled-up version of team-level Kanban. Rather, it's a thoughtfully designed flow-based framework built for delivering value across complex, multi-team environments. As I’ve written earlier (see here), it's minimal in nature, but has maximum impact.

CIPSA Scaled Kanban promotes continuous delivery, cross-team alignment and adaptive planning. These make it a practical and scalable solution for any domain where flow, coordination and customer value truly matter.

The CIPSA Framework Guide is free to download and use

For in-depth understanding with detailed hands-on practical, consider becoming a CIPSATo refer to the FAQs, click here.

CIPSA – What It's and What It's Not Series:

All Articles in What It's and What It's Not Series - CIPSA

CIPSA Sample Videos:

[1] CIPSA Sample Video List (Choose a video to play)
[2] CIPSA Video Playlist (Complete playlist - play all)

CIPSA Sample Questions: