Based on the experiences of professionals who have taken the CIPSA course, the following lessons highlight the imperatives, mindset, and practices every aspiring CIPSA must embrace to succeed in real-world scaled Agile delivery.
I interact with them frequently and keenly listen to them. And I learn from them.
Following are some of the lessons for aspiring CIPSAs.
--
1. Never, ever and under no circumstances think only at the team level.
A CIPSA must always see the bigger team, i.e., the CIPSA team, at scale. It is not about the individual Scrum or Kanban teams. To know more on CIPSA team, see here.
Scaled delivery succeeds only when teams understand how their work contributes to the larger product outcome. Thinking only at the team level leads to local optimization, local efficiency, but global ineffectiveness and inefficiency.
2. Never, ever and under no circumstances learn scaling without hands-on approach and software tools.
There is a plethora of Scaled Agile approaches, worldwide. However, not one – I repeat, not even one – tells how to scaling in a practical, hands-on manner.
Nobody has truly learned anything by reading theoretical content. To learn, you have to do it hands-on. Agility scales through practice, not theory.
You don’t scale by adopting a framework. You scale by doing the work.
3. Never, ever and under no circumstances maintain multiple product backlogs for the same product.
One product demands one backlog. Vision at any time is only one and it’s part of the backlog. Multiple Scrum or Kanban teams under the CIPSA Team must move toward one shared vision.
When teams maintain separate backlogs at the product level, priorities diverge, coordination collapses, and above all, nothing can really get accomplished. The single backlog ensures that all teams pull from the same prioritized source of work.
However, do note that there can be individual team backlogs. All these team backlogs will constitute the CIPSA Backlog – be it CIPSA Sprint Backlog (see here) or CIPSA Kanban Backlog (see here).
4. Never, ever and under no circumstances ignore cross-team dependencies.
Dependencies are inevitable in scaled environments. In fact, you - as the Principal Scrum Master or Chief Product Owner must know these dependencies.
The responsibility of a CIPSA is to identify, visualize, and manage them proactively. Hidden dependencies often become the biggest delivery risks and stifle the delivery of CIPSA Integrated Increment (see here).
5. Never, ever and under no circumstances refine work (backlog refinement) in isolation.
Backlog refinement in a scaled environment must involve multiple teams when work overlaps. It’s a dedicated meta-event for the CIPSA team and happens periodically. Without this event, the CIPSA Backlog can’t be properly prepared in the CIPSA Planning meta-event.
Collaborative refinement ensures that teams understand upcoming work, dependencies, and integration points.
6. Never, ever and under no circumstances allow events to happen without synchronization.
Scaled Agile delivery depends on synchronized events, e.g., in CIPSA Scaled Scrum, the Sprints are synchronized across teams. See here for an in-depth understanding on Sprint synchronization for multiple-teams.
With it, all teams stay aligned and dependencies are managed effectively. Even if individual teams are performing well, lack of synchronization can cause misalignment, delays, and integration issues. Under no circumstance should a CIPSA allow teams to operate their events in silos when their work contributes to a shared product increment.
7. Never, ever and under no circumstances deliver work that cannot be integrated or cannot deliver an Integrated Increment.
The purpose of scaling Agile is not parallel development. It’s about integrated delivery. The end goal in every Sprint or Release is to have a CIPSA Integrated Increment.
You, as a CIPSA, must ensure that increments from multiple teams combine into a cohesive product increment.
8. Never, ever and under no circumstances allow lack of transparency across teams.
Visibility is the lifeblood of scaled agility. CIPSA team-level metrics should be shared clearly. Dashboard should be visible to all. Progress tracking to be on information radiators and entire team should be able to see it.
This ensures transparency for all team members and stakeholders.
9. Never, ever and under no circumstances avoid CIPSA retrospectives.
The CIPSA framework has meta-events such as CIPSA Planning, CIPSA Retrospectives etc. I’ve consistently maintained that retrospectives and follow-up actions based on these retrospectives are of paramount importance. See here on the importance of retrospective.
Some of the most critical improvements lie between teams rather than within the teams. Cross-team retrospectives help address systemic issues affecting collaboration, coordination, and flow – the latter in CIPSA Scaled Kanban. See here.
In fact, in the early stages of scaling, it’s CIPSA retrospectives that will bring the most value to your team.
10. Never, ever and under no circumstances choose a “branded” framework over practical result.
The philosophy behind CIPSA emphasizes practical implementation. It’s a framework with ample guidance on how to proceed with hands-on software tools and scaling.
Through explanation has been given on the implementation part taking real-world projects. This enables you to learn in the most effective way.
What good is a “brand” if you can’t apply your learning in a hands-on manner from Day-1?
What good is a “brand” if you’ve paid loads of money, but have no real-world, practical use?
--
In conclusion, I’ll say the following.
Many organizations proudly claim they have “Scaled Agile” and doing “Agile Transformation,” yet what they often have is a collection of independent Agile teams moving in different directions in Brownian motion.
I’ve asked many Scaled Agile Practitioners who have been certified on “branded frameworks”:
- Can you show me a Scaled Backlog?
- Can you show the cross-team dependencies in a Scaled Agile Team?
- Can you show how you conduct the Meta-Events and how to track them?
- Can you create an integrated Burn-down/up chart for the entire team?
- And many more practical ones.
They don’t know and can’t demonstrate. And it’s certainly not their fault.
They’ve just got a “branded certification” to show to their employers. They’ve flocked to it due to end-less marketing, promos and sometimes even film-actors parroting it! But it has no real-life value, no practical use other than “some branded tags”.
Some believe that simply adding more Scrum or Kanban teams automatically leads to scalable delivery. It does not! Some others assume that coordination will somehow emerge organically once teams adopt Agile practices. The ground reality is far different and harsher.
My experience in multi-team Agile environments in early last decade, learning from professionals who use my courses, and above all the professionals pursuing the Certified In Practical Scaled Agile (CIPSA) course teach me the following:
True learning, implementation, and delivery happen in a practical, hands-on manner. No other methods come close. The best companies in the world understand this and ask their engineers to do it hands-on from the very beginning.
If you are serious about understanding how Agile truly works at scale, there is no better way to learn than by immersing yourself in the CIPSA course.
👉 [Enroll Today] Pay via PayPal/Bank transfer. Email: managementyogi@gmail.com. Enroll in 24hrs.
CIPSA Certification:
No comments:
Post a Comment
Sign- or Log-in and put your name while asking queries in comments. Any comment is welcome - comments, review or criticism. But off-topic, abusive, defamatory comments will be moderated or may be removed.