CAS-SA1 Training

New certification

Certified Agile Skills – Scaling 1 (CAS-S1) training

Our Certified Agile Skills – Scaling 1 (CAS-S1) training class is a brand new Scrum Alliance certification. There’s an unprecedented demand for companies to deliver more in the  contemporary business landscape. CAS-Scaling 1 provides a solid foundation to ramp up the results of your agile efforts and take production to the next level. Scaling agile requires focused collaboration, coherent objectives, and appropriate change management practices to ensure that the flexibility and responsiveness that make agile effective on a team level can be sustained on a much larger scale.

  • Duration: 16h
  • Delivery: Remote / Face-to-face
  • Certifications: CAS-S1 Certification (Scrum Alliance)


In CAS-S1 you will learn different approaches that need to be taken when working agile with multiple teams. Unlike prescriptive scaling frameworks, the course will equip you with the skills and knowledge to identify principle-informed patterns that apply to your organization’s unique and evolving context.

The class is presented in a highly interactive and collaborative format with elements of lecture, classroom discussion, exercises, games and simulations, smoothly blended throughout the class. We will approach the class at a sustainable pace and endeavor to take breaks often, to allow our brain to stay focused and our body to recharge when necessary. 

Upon completion of the class, students will receive a CAS-S1 Scaling certification.

Who should attend CAS-Scaling 1?

This course is ideal for change agents—managers, executives, coaches, and anyone participating in scaling within an organization who needs adaptable guidance and a tailored approach to the core aspects of scaling.

The CAS-S1 course is right for:

  • Managers guiding the change
  • Executives who believe in the change
  • Agilists who embody the change

You can supercharge your skills even if you’re in the middle of an evolving scaling transformation or have never attempted scaling. This course is designed to meet you and your organization wherever you are in your journey to expand the benefits of agile teams.

Training topics

  • What is Scaling and Why is it Necessary?
  • Approaches to Scaling (Principles-led, Practice-led, Pattern-led)
  • Principles of Organic Scaling
  • Introduction to Complexity and System Thinking
  • Value Delivery and Unnecessary Synchronizations
  • Organizational Culture and Decentralized Control
  • Scaling Patterns
  • Change Management in Scaling
  • The Role of Agile Coaches in Scaling
  • Scaling Case Study Deconstruction

Included in the training

  • Certificate for Certified Agile Skills – Scaling (CAS-S1) + two-year membership to the Scrum Alliance
  • Slack channel to continue collaborating with your classmates after the class and access trainers to ask questions
  • Option to join the agile42 Community and get access to a number of free learning resources, like books, articles and videos
  • Life-long warranty on the course: e-mail access to the trainers

Why train with agile42?

  • Experience: Over the years, agile42 has delivered Scrum & Agile training to thousands of professionals worldwide. Our instructors have decades of experience using and coaching Scrum in hundreds of organizations large and small.
  • Excellent ratings: We consistently receive excellent ratings from our participants. 
  • Techniques: In all of our classes, we use techniques from Accelerated Learning and in particular principles and concepts from Training from the Back of the Room.
  • Engaging: Our courses are highly interactive and fun – not a PowerPoint assault, and our participants stay engaged throughout the class, learn by doing, and have fun along the way. When learners talk and teach, they learn. – Sharon Bowman
  • Practical and Memorable: Participants learn through hands-on exercises, creating high knowledge retention.
  • Sustainable: We are contributing to a greener planet by decreasing our carbon footprint by not having people travel to the venue, and less paper usage in terms of flipcharts and post-it notes.
Mitchell F., Program Management Consultant

Your virtual environment

In order to ensure a collaborative, engaging and fun environment even virtually, we are going to use a number of digital platforms.

  1. We will use Zoom as a video conferencing platform. You can access Zoom through your browser or download the desktop application. We recommend you access through a PC/laptop with a webcam and mic or headphones.
  2. We will use Slack as an additional messaging channel. You will get an invitation to our class Slack channel. If you do not have a Slack account, please go to and create one using the same mail address you used to register to the training. If you already have a Slack account with another email address and you want to use that one, let us know.
  3. We will use Miro as an online whiteboard for digital collaboration. You will soon also get an invite to access the platform. The access is included in the training fee you paid, so it will be free of charge for the 2 days of the training.

You will receive further information and specific instructions before the training.

Michael M., Senior Project Manager

Upcoming training

low angle photography of cranes on top of building

Scaling Scrum to the Organisation

Here be dragons!

The greatest challenges to adopting Agile at scale are organisational. Therefore any scaled implementation needs careful attention to communication, culture and change management. As CIO and agile consultant Marius de Beer observes: “When you scale, you scale everything. The good and the bad.” I suggest that you accept that there is no “silver bullet” solution to doing Scrum (or any form of Agile) at scale. With this mindset I suggest you read broadly what others have done and are doing. I especially recommend the Larman and Vodde books as well as Henrik Kniberg’s papers and presentations.

If you are a novice and are serious about helping your organisation get better, find and hire an Agile coach who has a verifiable pedigree in applying Agile at the scale you need. This will shorten your learning curve and lessen the pain!

Lastly, be prepared for a multi-year journey towards organisational agility. Whilst I have seen tremendous improvements within just a few months, serious “sticky” change, especially at scale, will take a long time: think five to ten years. The good news is that it can be a lot of fun with rewards all along the way.

Conway’s Law

Conway’s Law states:

“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.” [Conway 1968]

Conway’s Law is never more evident than in distributed teams and organisations. Teams that are not collocated experience the greatest communication challenges by definition. How teams and their communication is structured has a major impact on how well they design and execute their products. I encourage managers to defer to their team members in designing effective structures!

Some scaling techniques

The following sections will give you a short overview of a few scaling approaches and my opinion of each.

Multi-team sprinting

Henrik Kniberg has led this approach [Kniberg 2008]. The main idea is to create a single, unified Product Backlog, form multiple Scrum-sized teams and run synchronised Sprints with a joint Sprint Goal. This means Sprint Planning and Reviews are done jointly by all teams together. Daily Scrums are done team by team. These are complemented by some means of inter-team synchronisation, often a Scrum of Scrums. Retrospectives can be done jointly, team by team or in other affinity groupings. I vary this to achieve cross-learning. Facilitation of large meetings requires good skills. I use large-group techniques and multiple facilitators.

My opinion: I have applied this pattern in many organisational units with 12 to 50+ team members working on single and multiple products, with one or multiple customers. The results have exceeded my own and my clients’ expectations.

The Spotify journey

Henrik Kniberg and Anders Ivarsson have published an interesting paper on scaling at Spotify [Kniberg & Ivarsson 2012]. These authors all have deep experience in doing Agile at scale and have extracted the essence of what works (and what does not) into useful principles and patterns.

The figure shows a snapshot of Spotify’s organisational design and language.


My opinion: The Spotify story is inspirational to many practitioners (including me) who are trying hard to build agile organisations. It is a fountain of good ideas and thinking. It is not a recipe you can apply to your situation.


At the other end of the scale Dean Leffingwell has developed the SAFe model for Agile at scale [Leffingwell 2012]. The model contains concepts that some may find useful, such as the Release Train, but also contains a lot of “process voodoo” that will not be required in most cases.

Sophisticated models such as SAFe approach the scaling problem from the perspective of providing a menu of all the possible constructs that might be needed in any conceivable scenario. The result is a confusingly complicated framework that requires an expert process practitioner (or coach) to optimise it for your specific needs. Anyone with experience of the Rational Unified Process (RUP) will recognise this.

Moreover, SAFe attempts to codify what is inherently a complex problem requiring unique and nuanced solutions that will be different for every environment. Critics will recognise this as an attempt to describe simple/complicated solutions for complex problems (see our earlier article on the Cynefin framework for an understanding of complexity). On the other hand supporters claim that SAFe enables them to begin conversations with conservative PMO managers who were previously unwilling to discuss Agile methods.

My opinion: SAFe offers an appealing diagram for those who still believe that problems of project management are solvable by applying sufficient process and governance. I think SAFe heightens the risk of just applying “lipstick to the pig” and not dealing with the fundamental changes that are required in every organisation I have worked with.


The formal definition of DAD from its authors is: “The Disciplined Agile Delivery (DAD) decision process framework is a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value delivery lifecycle, is goal-driven, is enterprise aware, and is scalable.” [Ambler and Lines 2012]

DAD describes a “full agile delivery lifecycle” as comprising three phases: Inception, Construction and Transition. This is derived from the RUP. The DAD description goes on to describe three lifecycle variants: the “Agile/Basic DAD Lifecycle: Extending Scrum”, the “Advanced/Lean DAD Lifecycle” and the “Continuous Delivery DAD Lifecycle”. DAD’s authors appear to have repackaged Scrum and elements of Kanban.

DAD also adds more roles, both within the team (notably an Architect role), defining five primary and five secondary roles, as shown in the figure reproduced from the DAD web site.

dad-roles4 (1)

My opinion: Scott Ambler has many useful things to say about Agile methods and practices. Nevertheless I find the DAD description less practical and helpful than starting with either Scrum or Kanban and iterating towards a better set of processes for your teams and organisation.


Craig Larman and Bas Vodde have both been working with Agile methods at larger scale and for longer than most other practitioners. They have resisted the temptation to derive a one-size-fits-all set of practices. What they have done is to document tools and practices that they have applied in different situations as a guide to what you might try and what you might wish to avoid.

The output of their work is named LeSS, an initialism for “Large Scale Scrum”. These have been documented comprehensively in two books: Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum” [Larman and Vodde 2008] and Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum” [Larman and Vodde 2010].

The figure below shows the LeSS model for scaling up to ten teams or 100 people. LeSS contains a corresponding model for scaling to hundreds of teams and thousands of people.


Larman’s Laws of Organisational Behaviour

Larman warns that organisational change is hard and that it is best to start with changing structure. He states the following “laws” from his observation of organisations over decades [Larman 2013]:

    1. Organisations are implicitly optimised to avoid changing the status quo: middle- and first-level manager and “specialist” positions & power structures


    1. As a corollary to (1), any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo


    1. As a corollary to (1), any significant change initiative will be derided as “purist”, “theoretical”, and “needing customisation for local concerns”—which deflects from addressing weaknesses and manager/specialist status quo


    1. Culture follows structure, i.e. if you want to really change culture, you have to start with changing structure, because culture does not really change otherwise. That’s why deep systems of thought such as organizational learning are not very sticky or impactful by themselves, and why systems such as Scrum (that have a strong focus on structural change at the start) tend to more quickly impact culture.

Ouch! The truth hurts.

My opinion: I like Larman and Vodde’s approach to this topic. I suggest you study their books carefully and try some experiments. Watch for more from them.

My own scaling approach

A helpful aphorism to bear in mind is “scale principles not practices”.

I offer below some principles and related practices I have drawn from Don Reinertsen’s Principles of Product Development Flow [Reinertsen 2009], from Larman and Vodde’s books, from conversations with other agile coaches, and from my own experiences with applying Scrum at scale with my own consulting clients during the past eight years. Understand that this is only scratching the surface of what it means to apply Agile at scale.

Scrum Scaling Principles & Practices

Minimise cross-dependency between teams, so
Form feature teams rather than component teams, and
Ensure each team is cross-functional.

Stick to the “right” team size, no matter what, so
Merge multiple products into one backlog feeding a single team, or
Let a single backlog feed multiple teams.

Reduce skill silos and dependencies within teams, so
Grow T-shaped people

Employ small batches to reduce cycle time, reduce variability and increase efficiency, so
Avoid large work items in Sprints, and
Use a regular cadence for all Sprint meetings.

Shorten queuing times for the waiting work, so
Feed multiple, synchronised teams from a single backlog.

Exploit scale economies of multiple teams, so
Synchronise sprints for multiple teams.

Retain slack to achieve flow, so
Allow teams to pull from the backlog, based on their observed capacity, and
Challenge teams to finish early as least as often as they finish late.

Keep feedback loops short, so
Ensure all teams’ outputs are tested and integrated into the Increment every Sprint, and
Work to eliminate constructs like “integration” or “hardening” sprints.

Optimise the whole, so
Measure outcomes at the highest possible level, and
Let teams seek on their own local solutions.

Pay attention to quality, so
Ensure “technical debt” is reducing, not increasing, and
Fix errors as soon as they are found.

Pay attention to communication, so
Institute formal meetings to synchronise teams.

Pay attention to learning, so
Form communities of practice for different disciplines to share learning, and
Hold large group retrospectives on a longer cadence (e.g. for releases).


Ambler, Scott M. and  Lines, Mark (2012). Disciplined Agile Delivery: A Practitioners’ Guide to Agile Software Delivery in the Enterprise. IBM Press.

Kniberg, Henrik (2008). Multi-Team Sprint Planning.

Kniberg, Henrik and Ivarsson, Anders (2012). Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds.

Larman, Craig and Vodde, Bas (2008). Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley Professional.

Larman, Craig and Vodde, Bas (2010). Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Addison-Wesley Professional.

Larman, Craig (2013). Larman’s Laws of Organizational Behavior.’s_Laws_of_Organizational_Behavior

Leffingwell, Dean (2013). Scaled Agile Framework.

Reinertsen, Donald G. (2009). The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing.