New Practical Scaled Agile Framework – The CIPSA Framework Guide

In the earlier post, I informed about a new Practical Scaled Agile framework and associated certification – Certified In Practical Scaled Agile (CIPSA). 

Today, I’m pleased to announce the public availability of the CIPSA Guide to Scaling Scrum or Kanban Teams with the MS Project Agile software. You can download the guide for free, read and use it.

Purpose of the CIPSA Guide

Building a large-scale product or service is complex work and involves multiple teams. Worldwide, a large number of scaled agile frameworks are available, but not a single one of them considers taking a practical, hands-on approach using software tools.

The Practical Scaled Agile (PSA) framework is built-upon the widely used Lean-Agile approaches such as Scrum or Kanban. The Lean-Agile approaches are documented in respective guides and beyond the scope of this guide. 

Certified in Practical Scaled Agile (CIPSA) is the direct certification associated with Practical Scaled Agile (PSA) framework. Hence, going forward, I’ll call it CIPSA (sip-sa) Framework. 

A CIPSA professional will have a deeper and much clearer understanding of CIPSA framework as the person would know in and out the Practical Scaled Agile using the software tool of MS Project Agile.   

This guide contains the definition of CIPSA framework. Each element of the framework serves a specific part in order to help teams and organizations scale the benefits of two popular Lean-Agile approaches: Scrum and Kanban.

This framework has two objectives:

• Scaling using either Scrum or Kanban at the team level and understanding various scaling aspects. 
• Strong emphasis with hands-on demonstration with software tools such as MS Project Agile. In fact, in the annexures you can find a number of real-world snapshots. 

A number of Scaled Agile practitioners and authors at ManagementYogi.com contributed to the development of the CIPSA framework. In particular, Satya Narayan Dash would like to thank John P S Oliver, Lakshmi Narayan Dash and others at ManagementYogi for their contributions in the development of this guide.

CIPSA Definition

Certified In Practical Scaled Agile (CIPSA) is a framework, in which a set of Lean-Agile teams with interdependencies operate together to build products or solutions for complex problems using hands-on software tools such as MS Project Agile. In this framework either Scrum or Kanban can be applied at the team level and it can be scaled to multiple teams.

With the CIPSA framework and as a CIPSA professional, one can scale multiple teams to deliver a single large product or service. In it, the Chief Product Owner manages a Single Product Backlog with individual Team Product Owners focused on individual Team Sprint Backlog or Kanban Backlog. 

This guide outlines various events, artifacts, commitments and accountabilities of the CIPSA framework. With scaling, multiple teams work on a single Product Backlog to build and deliver an Integrated Increment. The delivery can be within or at the end an Iteration (Sprint) as in Scrum or a cadence-based Release as in Kanban.

The CIPSA Guide 

The CIPSA Framework Guide (20 pages) is embedded in this page. It’s free to view, download and read. To view, just scroll using the vertical bar to go through the guide.

You can directly download the CIPSA Guide from the below link:

Download the CIPSA Framework Guide

No sign-in is required to download.

Video: Understanding the CIPSA framework Guide

The below video explains the guide and how to proceed with the guide, along with the contents. It's brief video, less than five minutes.

Final Words

This new Practical Scaled Agile Framework is radically different from others because it’s highly focused on practical applicability, hands-on usage while scaling and in-depth practical demonstration. All these will be part of the upcoming CIPSA Certification Course.

Below are some of the snippets taken from the above CIPSA Guide. 

The cross-team refined Product Backlog with MS Project Agile software is shown below. 

The multi-team, multi-Sprint view for the entire CIPSA Team is shown below. 

The CIPSA Sprint Burndown Chart for the entire CIPSA Team is shown below. Individual team level Burndown Chart can also be drawn and it's informed as part of the CIPSA Guide. 

You can check them all the available linked and downloadable document. Go on, it’s free to download and read. A CIPSA professional (CIPSA Certified) will know in and out of Scrum at Scale and Kanban at Scale using the CIPSA Framework and MS Project Agile software.

I welcome your feedback and inputs on the CIPSA Framework. It'll help many other Scaled Agile Practitioners. 

References

[1] New Practical Scaled Agile Framework: The CIPSA Framework Guide (FREE Download), By Satya Narayan Dash and ManagementYogi.com

[2] Article: Kanban at Scale Managing Multiple Kanban Teams and Boards with MS Project Agile, By Satya Narayan Dash, first published at MPUG.com 

[3] Article: Scrum at Scale: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile, By Satya Narayan Dash, first published at MPUG.com

New Practical Scaled Agile Framework – The CIPSA Framework

I’m pleased to announce the availability of ManagementYogi's Practical Scaled Agile Framework. The  Certified In Practical Scaled Agile (CIPSA) certification course is based on this framework. With CIPSA (sip-sa), you can scale to multiple Scrum or Kanban teams and deliver complex products or solutions.

It's the only framework and certification in the world, which informs how to scale with software tool(s). It's practical and hands-on. No other framework and/or certification course in the world provides it!

The Practical Scaled Agile framework has been under development since March of this year. It has gone through multiple iterations, a number of prototypes with reviews and article publication before it’s made public today. 

Why Non-Practical, Scaled Agile Frameworks are Ineffective?

Worldwide, a number of Scaled Agile frameworks are available. Unfortunately, not a single one of them informs how to do scaling in a practical, hands-on manner with software tool(s). This, indeed, is a big problem. Many Scaled Agile Practitioners, with whom I frequently interact, really don't know how to do scaling in the real-world as they are certified in theories.

For example, considering multiple Scrum teams sprinting together or multiple Kanban teams working together on a Product Backlog, a number of questions come-up:

1. How do you to manage so many Sprints across multiple Scrum teams?
2. How do you synchronize multiple Sprints in a cross-team environment?
3. If Kanban is used at the team level, how would you scale?
4. Can you track multiple teams (say five Scrum or Kanban teams) together at scale?
5. Is it possible to see burndown/burnup charts for the entire scaled team and individual teams?

With ManagementYogi's Practical Scaled Agile framework, the answers to all the above questions are in affirmative – yes all of them! In addition, you can manage all the teams using a single software tool, which in our case is MS Project Agile. You can also manage assignment, planning, tracking, stands-ups, retros and reviews at scale. 

With this background, let me introduce the framework used for the Certified In Practical Scaled Agile (CIPSA) course. As our Practical Scaled Agile framework is directly associated with the CIPSA certification, going forward, I’ll call it CIPSA framework.

The CIPSA Framework

The CIPSA framework extends the team level Scrum or Kanban, helps to solve dependencies and enables collaboration and cross-team management. It extends them in the following ways. 

CIPSA Artifacts: All individual teams use a single and same Product Backlog. The Product Backlog items are visible to all the teams, but items are distributed across the teams. This backlog goes through refinement so that the individual teams can know which items to work upon in the next Sprint (Scrum) or Release (Kanban).

A CIPSA Backlog is built during the CIPSA Planning event and it's the sum of all work done by individual teams for the upcoming Sprint or Release. 

The third artifact is the CIPSA Integrated Increment, which is the sum of all integrated work from all teams and is given at the end of (or during) the Sprint or Release.

CIPSA Events: There are multiple events in the CIPSA framework, namely, CIPSA Backlog Refinement, CIPSA Planning, CIPSA Daily Stand-up, CIPSA Review and CIPSA Retrospective. Each of these events plays a critical role in managing Agile at scale. 

CIPSA Roles: There are two primarily roles in CIPSA complementing the accountabilities at the individual team level. They are Chief Product Owner and Principal Scrum Master (Scrum) or Principal Flow Master (Kanban).

At the individual Team level, there will be Product Owner, Scrum Master (or Flow Master) and Developers, some of whom play a major role in integration work. There is no separate integration team because developers are encouraged to be generalizing-specialists.

The CIPSA Framework – Graphical

The CIPSA framework is shown in the below figure. It shows the CIPSA artifacts and CIPSA events at scale. It also shows the artifacts and events at an individual team level, in dotted rectangles and circle.

The CIPSA Framework – Interactions

There is a single Product Backlog with ordered items and it’s continuously refined with cross-team members as part of the Cross-Team Backlog Refinement meta-event. The Product Backlog with the Product Goal is presented in the CIPSA Planning meta-event by the Chief Product Owner to the CIPSA team. In this meeting, a CIPSA Backlog is created with the Product Backlog items that can be delivered by multiple teams in the upcoming Sprint (Scrum) or Release (Kanban). In other words, the “what” part is decided here.

Post CIPSA Planning meeting, for each team, an individual Team Planning event takes place. The Product Backlog items taken for the respective team is broken down into individual tasks, which results in Team Backlog. A Team Backlog is available for every team. In other words, the “how” part is decided here. 

Next, each team begins to work on the respective Team Backlog. A CIPSA Daily Stand-up meeting happens everyday with cross-team members to synchronize the work, identify cross-team dependencies, issues and risks. The CIPSA Daily Stand-up is preceded by Individual Daily Stand-ups for the individual teams. 

In the CIPSA Review meta-event, a CIPSA Integrated Increment is presented for the entire CIPSA team and needed stakeholders. As the focus is on CIPSA Integrated Increment, CIPSA Review meeting replaces the individual Team Reviews. 

In the last meta-event of CIPSA Retrospective, the CIPSA team reflects on the effectiveness of the CIPSA team as a whole and determines the improvements that can be taken-up. The CIPSA Retrospective is preceded by Team Retrospectives, which are specific to the individual teams. 

The below video [duration: 7m] explains more on this new CIPSA Framework. 

 

Conclusion

As you’d have noticed, at the team level in CIPSA, one can use either Scrum or Kanban, while most Agile at Scale frameworks take only one. Also, quite a few scaled Agile frameworks employ a large number of artifacts (also events or ceremonies and roles), which are in violation of one of the four values of Agile Manifesto: 

"Working software or product over comprehensive documentation."

Above all, not a single Scaled Agile framework informs how to do scaling in a practical, hands-on manner. 

As we just saw with the figure and explained interactions, the CIPSA framework is simple to follow and you can employ it in your organization or teams. And you can do the entire scaling with the hands-on software tool of MS Project Agile.  

The CIPSA framework is free to use. However, when you use this framework or the concepts from this framework, I’d expect you to give due credit.

The detailed CIPSA framework guide is now available (August 30, 2024). The guide is free to download and use. The new CIPSA Certification Course is based on this framework.

References

[1] *NEW* Certification Course: Certified In Practical Scaled Agile (CIPSA), By ManagementYogi.com

[2] New Practical Scaled Agile Framework: The CIPSA Framework Guide (FREE Download), By Satya Narayan Dash and ManagementYogi.com

[3] Article: Kanban at Scale Managing Multiple Kanban Teams and Boards with MS Project Agile, By Satya Narayan Dash, first published at MPUG.com 

[4] Article: Scrum at Scale: Multiple Teams and Synchronized Scaled Sprints with MS Project Agile, By Satya Narayan Dash, first published at MPUG.com

Building and Using A Practical Portfolio Benefits-Realization Plan with MS Project (Part - 2)

In the earlier part, we understood the fundamentals and importance of a Portfolio Benefits-Realization Plan. We also took a number of steps to build this plan. In this part, we will conclude and give a finishing touch to the plan, followed-up with a video and concluding remarks.

This series: Part – 1

Step – 6: Segregation of Components and Strategic Objectives

As the portfolio components are all blue color-coded, the distinction among components in the graphical side of the plan is not very clearclear. Hence, our next step is to segregate the components with the help of additional custom fields. For our plan, we will have three Boolean custom fields:

• IsProgram: A Boolean flag indicating the component is a program.
• IsOps: A Boolean flag indicating the component is an operation.
• IsStrObj: A Boolean flag indicating the organizational strategic objective. 

Again, to create these custom fields, go to Gantt Chart Tools > Format tab > Columns group > Custom Fields command and add three Boolean flags as shown below. 

Next, we need have to change the conditions associated with these three flags. Whenever a new portfolio component or a new strategic objective is added, the respective bar in the Gantt Chart view will display the requisite color.  For this, go to Gantt Chart tools > Bar Styles group > Format drop down menu and choose the Bar Styles command. We will add the following tasks with respective conditions:

• Program Task: N It’ll be a normal, active task with the ‘isProgram’ flag applied.
• Ops Task: NIt’ll be a normal, active task with the ‘isOps’ flag applied.
• Strategic Obj task: NIt’ll be a normal, active task with the ‘isStrObj’ flag applied.

To add these new tasks, simply use the functionalities available in the Bar Styles dialog box such as Insert Row, Cut Row, and Paste Row.  

As shown above, we have four task types, including the default task type for the component projects represented with a blue bar.

Next, we willhave to apply them in the Gantt Chart view in the following manner:

• Set ‘isProgram’ field “Yes” for the component programs.
• Set ‘isOps’ field “Yes” for the component operations.
• Set isStrObj’ field “Yes” for the strategic objectives.

When you have all the respective fields set for the component projects, programs, operations as well as the strategic objectives, we will have the following view.  

As shown, the component programs (e.g., Program 1), component projects (e.g., Project 3), and component operations (e.g., Operational Work 1) are shown in green, blue, orange colors, respectively. On the other hand, the strategy and objective (e.g., Organizational Strategy and Objective I) is shown with red color coding.

As you present this bBenefits-realization plan or share with your stakeholders, you may want to just show the minimal fields. Additionally, based on your need, you can also add the component names in the graphical side of the Gantt Chart view. This is depicted in the below figure. 

As shown above, we now have complete Portfolio Benefits Realization as documented in PMI’s Standard for Portfolio Management. If you have business proposals (or cases) as another portfolio component class, you can exactly follow the same previous steps with a new custom Boolean flag, conditions,  and a separate color.

Video – Demonstration of Portfolio Benefits-Realization Plan 
*** NEW ***

I’ve put together a video depicting a portfolio benefits-realization plan. In addition, I've some more explanation with respect to this plan. My video [duration: 4m:26s] shows all the components in the plan, which we recently learned in the article. They are demonstrated with different color coding for the individual components.

Conclusion

Finally, you might be wondering,  can someone add the benefits accrued from the components into the portfolio benefits-realization plan? 

Yes, you can! But do ensure the linking and dependencies are properly managed. 

However, the PMI-SPfM puts the portfolio components, benefits, and strategic objectives, along with the benefits realization based on schedule and number of other parameters in a separate portfolio report called portfolio performance variance report. As you manage your portfolios, along with key deliverables such as portfolio roadmap, portfolio reports play a significant role. Hence, while doing portfolio management and sharing the status with your stakeholders, you can use both the portfolio benefits-realization plan and the portfolio performance variance report.

Many perceive and/or believe that MS Project software tool can’t be used to create a Portfolio Benefits-Realization Plan! As we just learned, you can certainlydefinitely build one and dynamically change the plan as per your needs. 

This series is concluded. I welcome your thoughts, reviews, and feedback in the comment section below.

This series: Part – 1

--

This article was first published by MPUG.com on 5th December, 2023. The current one has been updated with content and video.

References

[1] NEW Book - I Want To Be A PfMP, The Plain and Simple Way, by Satya Narayan Dash

[2] Article – Benefits Realization Management for Projects, by Satya Narayan Dash

[3] The Standard for Portfolio Management, by Project Management Institute (PMI)

Building and Using A Practical Portfolio Benefits-Realization Plan with MS Project (Part - 1)

Bugs smell, features tell, benefits sell.

-    From the book, I Want To Be A PfMP, the Plain and Simple Way

Portfolios fundamentally exist in an organization to achieve organizational strategies and objectives. One or more strategic objectives of an organization flow into the portfolio strategic plan. After the identification, categorization, evaluation, prioritization, and authorization of portfolio components, their execution begins and benefits are delivered. This, which in turn, helps in achieving the organization’s strategic objectives.

But then following questions come -up:

• How do you ensure strategies are fulfilled in order to meet the strategic goals?
• How do you find out that the portfolio components authorized earlier are actually delivering the benefits?
• How to plan for, measure, and monitor the organization’s (business) value achievement?

The answers to above questions lie with portfolio benefits management. The Standard for Portfolio Management (SPfM®), clubs benefit management under Portfolio Performance Management. Benefits and their subsequent realization are extremely important in portfolio management. And as the opening quote tells, it's only benefit that sells! 

In this article, we will understand portfolio benefits, the benefits dependency map, and above all, how to build a benefits-realization plan with the MS Project software tool. The portfolio benefits-realization plan will be based on the template provided by SPfM from Project Management Institute (PMI®).

This series: Part – 2

Portfolio Benefits

Portfolio benefits are first identified during the definition stage of the portfolio and documented in the portfolio strategic plan (PfSP). These benefits will flow into the Portfolio Performance Management Plan (PfPMP) and are documented in the Benefits Realization section of the PfPMP. 

Benefits can be qualitative or quantitative, tangible or intangible, financial or non-financial, short- or long-term. Irrespective of the type of portfolio benefits, they need to be clearly defined and documented in the PfPMP.

The portfolio benefits actually come from the portfolio components. These benefits are aggregated at the portfolio level. The benefits in turn help achieve the strategic objectives of the organization. To understand it graphically, you need to be aware of another fundamental concept, the benefits dependency map (BDM).

Benefits Dependency Map

A simplified benefits dependency map is shown below.  

As shown in the above BDM, moving from left to right of the map, we have organizational vision (and mission) translated to strategic objectives. These objectives, in turn, translate to benefits, and then to outcome to outputs (or results). In other words, moving from left to right we are asking – “How the strategic objectives are finally executed to give results/outcomes/output”? On the other hand, moving from right to left we are asking – “Why this portfolio component (e.g., project), which is giving this result (or service or product) is undertaken in the first place?” 

As you can see, we are moving from strategic objectives at the level of portfolio to benefits at the level of portfolio components. With these fundamentals, let’s see how to build the benefits-realization plan. 

A Practical Benefits-realization plan

We will take a step-by-step approach to build the Portfolio Benefits-realization plan with MS Project software. Along the way, we will do a few customizations and apply them to the software tool. 

Step – 1: Add A ‘Portfolio’ Custom Field 

To add a custom fieldle, go to Gantt Chart Tools > Format tab > Columns group > Custom Fields command and add a Text custom field “Portfolio”. Under this custom field we will have various portfolios undertaken by the portfolio manager. 

Next, add three portfolios under this custom field – Portfolio I, Portfolio II and Portfolio III. For each portfolio we will have a number of components and we will add them shortly.  

Step – 2: Rename ‘Task Name’ Column to ‘Portfolio Component’ *** UPIDATED ***

Before adding the components, rename the Task Name the column to Portfolio Components. This can be done by right clicking on the Task Name column and choosing Field Settings option.

When you have both the Portfolio custom field showing having the above three portfolios and the renamed column of Portfolio Component, you will have the following figure. 

For the time being, do not worry about the start and finish dates for the portfolios. Abecause after we add the portfolio components and strategic objectives, we will get those dates. 

Step – 3: Add the Portfolio Components and Strategic Objectives

In our next step, we will add the portfolio components and the strategic business objectives, which will be met when the benefits delivered by portfolio components are realized. 

To add the portfolio components, fyou just have to fill -up the line entries under the Portfolio Components column with respective component projects, programs, operations, and strategic objectives. This is very much like adding the task names in a normal MS Project plan. After you add the entries, you will have the following plan.    

This is the first -cut of our Portfolio Benefits-Rrealization Pplan, which we are going to refine as we proceed. As shown above, for Portfolio I:

• There are three component projects - Project 1, Project 2, and Project 3 - and also Component Program 1.
• Organizational Strategy and Objective I will succeed the completion of the project and program components. 

Similarly, we have components, including operations, for other portfolios such as Portfolio II and Portfolio III in the evolving plan. 

Step – 4 (mini one): Ensure Proper Timescale

Did you notice on the right side of the above figure that the timescale has changed?! This is important because, without proper timescale adjustment, you won’t be able to visualize the long running portfolio components such as a program or a long-term project. 

In our case, I’ve used the below timescale customization.  

As shown above, we have:

• Two tiers – Middle Tier and Bottom Tier.
• For the middle tier, Units used is Years, whereas for the Bottom Tier, Units used is Quarter.
• The Preview is shown belowbelow, and the exact same view is available in the previous figure.

Step – 5: Build the Dependencies

Now that we have the right time-scaling, we must ensure the dependencies between the portfolio components and the strategic objectives which will be met when they are complete. 

After you add the dependencies, the view will come as shown below. For an in-depthTo understanding of know in-details about dependencies, lead, and lag, , you can use this course.

 

Interpreting the above figure and dependencies, one can say:

• Component Program 1 has finish-to-finish (FF) dependency with Component Project 1 and Component Project 2. 
• Organizational Strategy and Objective I has FF dependency with Component Project 3 and Component Program 1. 
• Organizational Strategy and Objective I also has FF dependency with Component Project 3 and Component Program 1.

In other words, you can say that Organizational Strategy and Objective I will be achieved when component Project 1, Project 2, Project 3, and Program 1 are completed and associated benefits are realized. This is important to understand.

Similarly, as you can see in the above plan, other organizational strategic objectives are associated with other portfolio component projects, programs,  and operations.

In the next part, we will follow few more steps such as seggregating the components based on their classes or categories. We will conclude with a video demonstration.

This series: Part – 2

References

[1] NEW Book - I Want To Be A PfMP, The Plain and Simple Way, by Satya Narayan Dash

[2] Article - Strategic Alignment of Project (Portfolio Components), by Satya Narayan Dash

[3] Article – Benefits Realization Management for Projects, by Satya Narayan Dash