Agile Training and Coaching

A holistic and pragmatic way to scaling agile

Scrum@Scale (or Scrum at Scale) is one of the newer Agile frameworks, introduced in 2014 by Jeff Sutherland, creator of the Scrum methodology and one of the signatories of the Agile Manifesto. It addresses complexities and impediments of multiple Scrum teams working with the Scrum guide to deliver value to their customers, and is designed to scale across the entire organization.

Key Purpose
& Core Principles

Scrum@Scale

A simple and lightweight framework

The purpose of Scrum@Scale is to offer a simple and lightweight framework to scale Scrum with as little bureaucracy as possible. It is one of the least prescriptive of the scaled Agile methodologies, emphasizing the typical challenges related to scaling, as well as suggestions for how to address these.

Scrum@Scale seeks to ‘radically simplify scaling by using Scrum to scale Scrum’. The core principle of Scrum@Scale is the known and clear responsibility split between the Product Owner and the Scrum Master. The Product Owner is responsible for the content (the ‘what’), while the Scrum Master is responsible for facilitating the process (the ‘how’). By highlighting this jurisdiction, Scrum@Scale seeks to eliminate conflict and waste.

An Introduction to Key Elements

Roles

Scrum@Scale places significant emphasis on the separate jurisdictions of the Product Owner and the Scrum Master. Therefore, the framework introduces to separate cycles for the roles, with two touchpoints: Product Release Feedback and Team Level Process.

Product Owner Cycle

The Product Owner Cycle revolves around what product or solution will be created and the activities needed to support and promote this. The further responsibilities of the role correspond to the standard Scrum definitions. Scrum@Scale groups Product Owners into Product Owner Teams that map to the Scrum of Scrum teams. These Product Owner Teams meet at a daily Meta Scrum ceremony, led by a Chief Product Owner, in order to coordinate as needed and discuss high-level strategy.

The Scrum Master Cycle

The Scrum Master Cycle revolves around building the products or solutions that have been identified by the Product Owner. Like with the Product Owner role, the individual Scrum teams have the same roles, activities, ceremonies and artefacts as in traditional scrum. Scrum@Scale groups scrum teams into Scrum of Scrums (SoS) which carry a joint responsibility for producing a common product increment. They participate in joint agile ceremonies such as backlog refinement, retrospectives, and a Scaled Daily Scrum with the objective of coordinating teams and removing impediments.

Scaling the cycles

If further scaling is needed, the overall responsible leader is the Executive Action Team (EAT). The Scrum of Scrum teams gather in a Scrum of Scrum of Scrums (SoSoS), and so on. Likewise, the Product Owners scale in a similar way depending on the context. The highest level of Product Owner scaling is the Executive Meta Scrum (EMT), prioritizing in a company-wide setting.

Get Started With Scrum@Scale

When implementing Scrum@Scale, the first activity is to install an Executive Action Team (EAT), a small set of teams using scrum at a small scale, in order to, at an early stage, start resolving any organizational bureaucracy or existing development practices that hinders agile. This model is then used as reference for scaling scrum to other teams and departments. The EAT must therefore have political and financial support throughout the organization, with capability of changing organizational policies and practices.

In doubt which agile framework to choose?​

Agile Portfolio Management

A holistic & pragmatic way to scaling agile​

Disciplined Agile Delivery (DAD) builds on top of known Agile and Scrum frameworks, taking a pragmatic approach while placing emphasis on the many different parts of an organization that are involved in delivering software.

In terms of scaling, DAD differs between tactical agility at scale and strategic agility at scale. While tactical agility addresses individual team scaling, strategic agility scales through the application of Agile and Lean strategy holistically throughout the enterprise by expanding the framework to different areas of the organization.

Key Purpose
& Core Principles

Disciplined Agile Delivery
(DAD)

A goal-driven approach

The key purpose of DAD is to increase overall business agility in a simple way. Arguing that every situation is unique, DAD promotes pragmatism and an approach of adopting the Agile processes to the specific needs of the company and product. DAD offers a lot of “Bang for the Bucks” and fast deployment.

Within the DAD framework, a goal-driven approach is applied to create and adapt Agile processes. According to the methodology, each team will meet 21 key processes during their lifecycle, and for each of these processes, the team must make a number of decisions of how to structure that process.

As shown on the image below, each of the decision points provide suggested techniques or practices meant to be used for implementing the decision in the organization.

An Introduction to Key Elements

Roles

DAD builds on top of Scrum to provide a more extensive role catalogue in order to address the entire solution delivery lifecycle. The team roles are broken down into two categories; primary (working on the project on a constant basis) and secondary roles (introduced temporarily e.g. in relation to scaling).

DAD defines 5 primary roles. Stakeholders are the people who will use your team’s product or solution, e.g. end-users or customers. Team members are the people in the team executing the planned work, such as developers or testers. The team lead works as a servant leader for the team, resembling a Scrum Master, as he or she facilitates progress by removing impediments and empowering the team. The Product Owner is the representant for the stakeholders and is responsible for prioritizing and maintaining the list of activities to be carried out by the team. Finally, the architecture owner is responsible for enterprise alignment of the solution architecture, mitigating risks with a deep technical or domain knowledge.

In addition to the 5 primary roles, DAD also defines 5 secondary roles. Specialists are people joining the team temporarily to contribute with their specific knowledge. Domain experts are people with technical domain expertise who can help out the team on challenges within their areas, e.g. legal advisors. Technical experts help out the more generalized team members at key points in the life cycle of the solution or product. Independent testers work to validate the work of the testers in the team in specific cases where it is necessary e.g. due to very complex systems. Finally, the integrator helps the team to integrate their product or solution within the holistic system, and is responsible for managing dependencies to other products or solutions.

Delivery Lifecycle

DAD provides a suggestion for 6 different full delivery lifecycles, accounting for different work styles, agile maturity in the company, and other conditions that might influence the needs for a specific type of delivery lifecycle:

  • The Agile Lifecycle: A Scrum-based Project Lifecycle
  • The Lean Lifecycle: A Kanban-based Project Lifecycle
  • The Continuous Delivery: Agile Lifecycle
  • The Continuous Delivery: Lean Lifecycle
  • The Exploratory (Lean Startup) Lifecycle
  • The Program Lifecycle for a Team of Teams

The basic assumption is that companies need to factor in full delivery lifecycles beyond the development and release part typically covered by agile and scrum. This includes the early stages of vision definition and approval, as well as the support and retirement phases following releases.

In doubt which agile framework to choose?​

Roles and responsibilities

Applying Scrum in a large-scale context

Large Scale Scrum (LeSS) focuses on how to apply principles and elements of Scrum in a large-scale context without overcomplicating processes or installing unnecessary bureaucracy. It is a ‘barely sufficient methodology’, revolving around many cross-functional, full-stack teams working together on their common goal and shared responsibility of delivering one shippable product – a complete end-to-end solution intended for real customers.

Key Purpose
& Core Principles

Large Scale Scrum
(LeSS)

Less is more

The key purpose of LeSS is to have many Scrum teams working together with as few processes and procedures as possible. As the name implies, the goal is to make the way of working and scaling as simple as possible.

Like SAFe, LeSS has defined a number of principles to guide the work within the framework:

  1. Large-Scale Scrum is Scrum
  2. Empirical process control
  3. Transparency
  4. More with less
  5. Whole-product focus
  6. Customer-centric
  7. Continuous improvement towards perfection
  8. Systems thinking
  9. Lean thinking
  10. Queuing theory

An Introduction to Key Elements

Roles

Keeping it simple, LeSS revolves around two main roles – Product Owner working with 2-8 teams and Scrum Masters working with 1-3 teams – with role descriptions stemming from standard scrum. The exception is that LeSS prefers to move the responsibility of refining the product backlog items from the Product Owner to the teams, which must be cross-functional and contain a combination of business domain knowledge and technical excellence. This means that a key prerequisite for success is that the teams are empowered to be able to directly interact with the customers.

All teams share a unified product backlog which they work on in synchronized sprints lasting 1-4 weeks. At the end of the sprint, the teams jointly deliver a product increment.

Ceremonies

In terms of ceremonies, LeSS places key emphasis on planning, product backlog refinement, and the sprint review and retrospective.

Planning is split into two parts; the first part where selected team representatives meet with the Product Owner and commit to selected product backlog items as well as discuss cross-team collaboration during the coming sprint. In the second part, the teams gather separately to plan the sprint and refine the sprint backlog.

Product Backlog Refinement is continuously done throughout the sprint in order to ensure that the product backlog items are ready for sprint planning, e.g. by splitting big items, detailing items, and estimating effort.

The end of sprint focuses on 3 activities: 1) The sprint review, where the team and customers review the sprint outcome together, 2) the retrospective, where improvement areas are identified and successes are celebrated in each team, and 3) the overall retrospective, where all teams, Product Owners, and Scrum Masters get together to inspect and adapt practices to gain improved efficiency. 

In doubt which agile framework to choose?​

Top-down vs Buttom-up

Either way takes time. But at different times

As agile ways of work have made their way into many types of organisations, methods of implementing agile have been tested. There is no right way. There is always pros and cons and what to choose depends mostly on the culture of your organisation, the leadership style, the culture and many other factors.

Both approaches can work overall, both top-down and bottom-up agile transformations have equal chances of success as a starting point. The key is learning and adjusting to find the right balance that is appropriate to your organisation.

Two ways, or a hybrid?

Top Down

Risky business?

The top-down agile transformation tend to be planned for the entire organization at once. Such transformations take much longer to prepare  and to create traction. One year at a minimum would probably be required, often more.

During that period, a comprehensive org redesign is planned and performed. Then the organisation is prepared for the implementation of an Agile Operating Model – what ever the basis is (SAFE, DAD, Scrum of Scrums).

One major benefit of using this approach is, that it naturally requires top management to communication the “why” and the vision of such a transformation. And organisations tend to listen to and follow leaders. There are other cons to this approach, however there are risks as well. One of the major risks are, that if not orchestrated carefully you might “forget” to ask those who are closest to the work to be involved as influential stakeholders, making the adoption less likely to succeed. 

The three major pros 

  1. Creates more momentum as the wholeorganisation is involved in a big-bang style event, and if executed the right way delivers enterprise-wide results. 
  2. Less uncertainty about when and how the change will be implemented 
  3. Adequate funding for training, coaching is agreed upfront

And the equally major Cons 

  1. Longer preparation require adequate resourcing and a disciplined approach to be successful
  2. Could be led by those who are not closest to the work and therefore might not know the best route forward for transformation
  3. “Command and control” which is counterproductive to the nature of agile transformation could be an outcome

The buttom up

Single teams, units or projects can start the journey and become the example of success for the rest of the organisation to follow. When individual teams are empowered to make decisions based on experience and current data, there is a
high probability they are the right decisions.

Organisations that use this approach often state that this constant improvement approach allows them to decrease the risk of the transformation, however, at the expense of duration of the entire journey for the organisation – and with the risk of different teams using different cadence, agile model and culture, which makes it more difficult to align later.  

The three major pros 

  1. Those who are closest to the work have deciding influence
  2. Adoption is generally more likely to remain due to personal ownership
  3. Transformation is faster – at least at the team level
  4. Most effective for smaller organisations

And the eqally major cons

  1. Those who are closest to the work have deciding influence
  2. Adoption is generally more likely to remain due to personal ownership
  3. Transformation is faster – at least at the team level
  4. Most effective for smaller organisations

Want to know more about which approach to use?