Overview

In this section, we outline a guide for Product Owners and product teams that are considering to scale so that the Product Vision and Goals can be achieved at the desired speed and quality.

Here, we focus on the common scenario of growing from 1 Agile (Scrum) team to multiple teams, and adopting the Large-Scale Scrum framework to scale their agile practices for delivering value to customers.

The need to scale

As a product grows to meet the organisation and customer needs, there comes a point where the Product Roadmap, associated outcomes and time-to-market requires more than 1 Agile team to realise. Ideally, we start with 1 to 2 Agile teams, then gradually add more Agile teams. This allows the agile practices to scale more organically and is more sustainable for the teams to deliver value consistently.

When scaling happens organically, the teams learn progressively the effective and efficient ways to collaborate. The existing agile practices can be adequately adapted to support the product development rate. This helps to better achieve the desired outcomes while fulfilling commitments related to quality, time and budget.

Some products may be relatively more complex and large from the start, such as enterprise solutions or platforms. Based on the organisation’s past experiences and estimation of what’s achievable for a team and timeframe, it may be necessary to start with more than 1 Agile team.

Considerations of scaling Agile teams and practices

When scaling in agile to deliver a large, complex product, regardless of the sourcing archetype - be it insourced, co-sourced or outsourced, it’s essential to be clear about the following “What” and “Why” before starting on the “How”:

• What is the challenge or opportunity the product aims address
• What might the product increments or releases be; What are the corresponding goals and outcomes to achieve, within what timeframe
• Why is it not possible for 1 Agile team to achieve these product goals and outcomes in the timeframe
• What is the cost of changing to operate in a scaled setup vs the benefits, e.g. growing from 1 Scrum team to multiple Scrum teams
• What are the impacted business areas and processes
• What are the needed technical expertise and skills

A more structured approach to considering the need to scale and designing the change can be started by conducting a service design and co-creating the “To-Be” service blueprint. This can help teams to make considerations and understand the overall system better when, rather than making guesses based on gut feel on the impacted business areas, process and technical expertise and skills needed.

Adopting Large-Scrum Scale - Step 1: Consider your motivation behind adopting LeSS

Scrum is the most popular framework adopted by GovTech product and project teams. As such, this may be more a natural progression to adopt Large-Scale Scrum (LeSS) as the scaling agile framework of choice.

Before proceeding to transition from a Scrum to LeSS framework, it is essential to consider a few key factors:

1. Be clear about the scaling problem the team wants to solve by changing frameworks.

   • Spend time identifying specific inefficiencies or limitations within the current Scrum framework that you hope to address through the transition.
   • Start to identify the problem (or opportunity) statement and the desired outcomes. This can also be written as a hypothesis.

2. Consider if the benefits of change exceed the cost of change.

   • Making changes to the way you work is a substantial decision that requires thorough evaluation. It should never be made merely due to trendiness (“Everyone else is doing it”).
   • Although LeSS offers improved adaptability and further drives continuous improvements, implementing it effectively requires significant adjustments in organisation structure and team dynamics. The cost of such changes might not be palatable to your organisation.
   • List the cost of changes, and quantify it where possible.

3. Assess if modifications within the existing framework can yield comparable outcomes before committing to a major overhaul.

   • Explore alternative frameworks like Scrum of Scrums, which allows for easier scalability from the foundational Scrum methodology. Having a comprehensive understanding of all your options ensures that the transition aligns with the organization’s goals and optimizes operational efficiency without unnecessary disruption.
   • Do a comparision of the benefits and costs of change to help with decision-making.

Step 2: Change Management

Transitioning from SCRUM to LeSS requires a strategic approach to ensure smooth adoption and sustained success. While stakeholder buy-in on an organisation level is important, support from team members is pivotal in this journey.

Starting with the following steps can help to achieve this.

1. Engage Tech Leads and Opinion Leaders - Initiate discussions with tech leads and influential figures within teams. Their support acts as a catalyst for acceptance among peers. Leverage their insights and endorsement to pave the way for a seamless transition.

2. Educate and Collaborate

• Provide comprehensive briefings on LeSS, elucidating its principles and methodology to team members.
• Encourage open dialogue, inviting team members to voice potential concerns and identify implementation hurdles.
• When agreeing to adopt LeSS and start with practices, set a collaborative tone by involving team members to identify an optimal implementation date.

3. Identify the Enabling Factors

• Make a visible list of or map the business processes and associated systems required to support each business process. E.g. Service Journey, Service Blueprint, Value Stream Map
• Identify the skillsets needed, for both business and IT, and whether most team members are equipped

4. Formulate Working Groups within the team

• Establish specialized working groups dedicated to addressing identified issues. Tasked with devising solutions and strategies, these groups foster a sense of ownership and empowerment among team members.
• Prioritize transparency and inclusivity in these endeavors. E.g. regular cross-sharing of information from work groups to give inputs and validation points

5. Conduct Tabletop Exercises

• Utilize tabletop exercises as a practical tool for simulating LeSS operations. Guide team members through hypothetical scenarios, allowing them to visualize workflows and interactions within the new framework.
• Encourage active participation and constructive feedback during the tabletop exercises to refine operational blueprints.
• Draw up the team structure and identify the key typical skills each team should have. Validate the structure by simulating a key journey from conceptualisation to deployment, maintenenace and support.
• For specialised skills that are ocassionally needed by the team, have a plan on whether to cater for this within the team or to seek externally from other parts of the organisation. Weigh the pros and cons of both approaches.

6. Execute with Confidence

• Proceed with implementation once consensus and confidence permeate the team.
• Ensure that every member feels adequately prepared and equipped for the transition.
• Maintain open lines of communication throughout the process, addressing concerns promptly and proactively. E.g. Regular review and retrospective session so all in the team has a platform for giving inputs

Adhering to these starting steps helps to foster a collaborative environment conducive to embracing LeSS.

Remember that effective communication, inclusive decision-making, and proactive engagement are the cornerstones of successful change management!

Step 3: Implementation

You can learn about LeSS ceremonies in detail at https://less.works.

An common practical dilemma most teams face is deciding who to attend the LeSS-specific ceremonies. Here are some observations and suggestions.

Sprint Planning Part 1, Overall Retrospectives, Overall Refinement

• Representatives attend only
  • Pros: Likely to be an efficient session
  • Cons: Less transparent and open, not all representatives may be well equipped with the overview and depth needed for an effective ceremony
• Everyone attend
  • Pros: Lower communication overheads, supports transparency and openness
  • Cons: Potentially a long ceremony or some might not find it relevant and start to lose interest
• Representatives and Observers (stakeholders, team members who are keen) attend
  • Pros: Balances efficiency and transparency
  • Cons: A compromised approach. Observers may not be able to sufficiently value-add.

Sprint Review

• A sprint bazaar approach where stations are grouped by theme and participants can rotate, say, every 20min minutes or not at all.
• Participants (Stakholders, team members) can roam around the stations to review the product increment and ask questions as needed.
• Conduct product demos showcasing the end-to-end actions and results, besides running through each user story.

** Refinement

To consider adopting 1 of the 2 formats below:

Format 1

1. Identify the user stories of a similar theme and allocate to a station, theme by theme (A theme could consists of more than 1 related user journeys).
2. Allocate those who are familiar with the stories to the specific sta.tions
3. Mix everyone up and split them to the different stations. a. Ensure there is a mix of teams and roles.
4. Rotate the members between the stations.

Format 2

1. Identify stories of a similar theme and assign them to stations, theme by theme (A theme could consists of more than 1 related user journeys).
2. Allocate those who are familiar with the stories to the specific stations. 3 Allow everyone to select which station they want to go to.

For both formats, ensure there is more than 1 round of rotation so each station is reviewed by more than 1 group of people attending. This enables more comprehensive review of the product increment.

Step 4: Review and retrospect

At the Overall Retrospective, take the chance to gather inputs on how the LeSS setup is working for everyone. This helps to identify improvements early and the opportunity to kill what’s repeatedly not working.

At least once every 2-3 months, gather in an open forum where team members and stakeholders can attend to review and reflect specifically on how effective and efficient the scaling approach has been.

• Use information radiators to substantiate impact, gaps and suggestions for improvements
• Examine and openly discuss risks and issues with the scaling approach

Pivot, persevere, experiment or kill decisions can then be made jointly as a team with the Product Owner and key stakeholders.