Start Small, Scale Up

Introduction

In recent years, the software development industry has been trying to move towards the Scrum and Agile way of working. They have started moving away from project centric development to product centric development. As the software systems get more complex and the development process becomes more chaotic, organizations are trying to move towards an empirical process to cater to the ever changing needs. Inspect, Adapt, and Iterate thus became the mantra for the software development industry.

Figure 1: Inspect, Adapt and Iterate

Scrum - an efficient approach at team level

Scrum processes have become popular in the last decade and organizations are easily able to adapt to its principles and methods for a single scrum team with approximately 5 to 9 members. They conveniently plan their backlogs across iterations, and develop and demonstrate the working software at the end of an iteration to the relevant stakeholders.

Figure 2: Scrum Cycle

This works well for a single team, where the Product Owner and the cross functional team are at the same location. They are able to transform themselves into a simple agile workspace with few whiteboards to track their progress, thereby perfectly implementing scrum to the word.

Need for Scaling

As Leading SAFe^® says "Because better systems make the world a better place", current digital world demands highly complex systems. It is increasingly difficult for the current IT systems and teams to keep pace with the growing demands and deliver expected value at the right time

Figure 3: The irony!

Increase in the number of teams and their distribution posts the following challenges:

• Very little visibility across the teams
• Under-estimated story points for the iteration or over-committed stories
• Managing distributed teams spread across locations
• Unclear dependencies among teams
• Poor team morale or self-management among team members

Thus, beyond just scaling, there is also an imminent need to make teams self-empowering, so they can deliver the best products and value to the end customers.

Scaling Approach

Though the core values of Agile are relatively simple and easy to use and work perfectly fine for single scrum teams, many organizations fail to transform to a completely Agile model.

Failure in Agile Adoption

Figure 4: Why Agile Fails?

Most IT enterprises view the Agile process as a simple change in the way they work, rather than considering Agile as a cultural change. These enterprises must realize that to succeed in a perfect Agile transformation, they need to revisit or reconsider changing some very fundamental aspects of how their IT teams work. The recommended way forward in achieving this transformation is captured here:

• Organizations should start moving slowly by considering a single team, working on short sprints, identifying the techniques, and then growing and evolving their teams.
• By performing scrum at a single team level, the organizations can identify their strength and weakness.
• The team can practise being self-organized, understand the best estimation techniques applicable for their business, plan their work into shorter iterations, and collaborate among themselves.
• When the single scrum team is successful in showcasing the value realized through Agile, the organization can slowly split the existing team into two teams in the same location by adding new members, thereby enabling the spread of learning between the teams.
• When co-located teams get familiar with the ceremonies and artifacts, spreading the same approach to geographies becomes easier.
• This way the large organizations with multiple teams located in different regions can transform to the Agile way of working in a more systematic and efficient way without any compromise on their business

Aspects of Scaling

Scaling is more commonly used in the Agile product world and it deals mainly with teams working in a single cadence to provide a single working software. But does scaling really stop with multiplying teams for a single system? Can scaling a single team to multiple teams provide the necessary output?

Definitely No. Scaling to deliver a complex software product not only involves teams, but it also involves planning and managing the requirements, and thereafter catering to the multiple systems that interact with each other to provide the working software.

For an effective Agile transformation by large organizations, there are various aspects of scaling that need to be considered. These include:

1. Scaling Teams
2. Scaling Roles
3. Scaling Requirements
4. Scaling Time-Boxes
5. Scaling horizontally from Demand to Deploy

1. Scaling Teams

The first level of scaling for any large organization is to expand their agile adoption and extend the scrum processes from a single team to multiple teams. Multiple teams need to work in synchronization and with the same cadence to deliver quality products with high value to the business.

Figure 5: Scaling from single to multi teams

For scaling from individual to enterprise level, let us understand:

• Agile teams perform best when co-located. However, teams are usually geographically separated owing to the business needs. These teams work towards a common set of goals. This splitting of the teams is the key to achieving modularity in working and also to reduce dependencies.
• Teams should ensure that the rhythm or delivery cadence and the objective are collectively met.
• Teams should be able to plan their work into different iterations with multi-team dependencies spread across the geographies.
• Collaboration is key in agile, so teams should invest on effective and continuous collaborative platforms to deliver best quality products.

2. Scaling Roles

Scrum talks about three main roles - The Team, Product Owner, and Scrum Master. These roles would suffice for a single team to plan and deliver their work. Involvement of more teams would mean addition of more roles to ensure seamless coordination.

Figure 6: 3 Scrum Roles

There are several roles prescribed by popular frameworks that can be adapted and used by organizations based on their business needs and organizational structure. These include, Business Owner, Portfolio Owners, Program Owners, Product Owners, Scrum Masters, Agile Coaches

Check our Agile Scaling Frameworks topic for more information on the roles.

When scaling roles:

• With co-located teams, the Product Owner or Scrum Master can be shared between the teams as they would have better visibility across the teams, while distributed teams demand more roles to bridge the gap as the product owner is located away from the team.
• There are teams located in different geographies and there needs to be a proxy person owning the product backlogs on the site where the team is located. This proxy Product Owner will coordinate with other proxy owners in other locations and sync up for the updates and changes.
• There can be Release Train Engineers or even Scrum Masters at each location coordinating with the business.
• There can be one Ultimate Product Owner who stays in the customer location along with the business stakeholders and the Product Management team could stay with the main product owner so that they would be able to coordinate between locations.

3. Scaling Requirements

Along with a higher number of team and increased complexity, there comes a need to look into the backlog items at various levels and maintain a hierarchical structure which will help the teams and management have a cumulative rolled-up view of the progress and thus recognize the value realized through implementing these backlogs. At an organizational level, the backlogs will be defined at a very high level; these will then be classified, refined, and cascaded down to become measurable individual tasks or action items that will undergo required iterations.

In order to scale requirements:

• Typically organizations define business goals or objectives which align towards achieving the committed business value.
• These business objectives are further fine-tuned to initiatives at the portfolio level which will be taken up by the programs or the projects to be implemented.
• The vision, objectives and initiatives are strategically decided by the business owner along with the program managers.
• Program level initiatives are broken down into product functionality as Features. These features are planned into release time-boxes to be made available in the working software.
• Further the teams plan the features across multiple iterations inside the release time-box as Stories, which are then broken down into implementable tasks and assigned to each member of the team.

The systematic hierarchical segregation of the backlogs based on the components of the system, the product areas, or even based on the skillset available with the teams in different locations, would give an organization a holistic view of the entire systems and sub-systems and also help track the team's progress towards attaining the ultimate goal or vision.

4. Scaling Time-Boxes

Any organization, big or small, would have a vision towards which they would work. The vision is a long term plan spanning across multiple years and this indicates the direction towards which the organization is moving.

Figure 7: Time-boxed Releases

Starting from strategizing the program or the product right until the working software is released to the market, multiple levels of planning is required for any organization.

To scale time-boxes:

• With the vision defined, program or product teams plan long term release time-boxes that can span several months or even years based on the organizational business needs.
• This roadmap definition is at a very high level and there is a likelihood of it changing over a period of time to accommodate changing business needs.
• The programs will then have a detailed plan for immediate release timeline. The team envisions the product capabilities that they would be able to deliver at the end of the timeline with the available team capacity and other resources.
• The teams then break the large time-boxes into short iterations and plan their work.
• Planning and tracking needs to be coordinated and synchronized at all levels to realise the benefits of Agile.
• All these activities need to be synchronized with multiple layers of groups of people without compromising the time-box, which is the key parameter for reaching the markets at the right time.

5. Scaling horizontally from demand to deploy

The concept of scaling most often brings to mind the vertical scaling, that is scaling of single teams to multiple teams, scaling up of requirements, or even the planning of activities.

However, there is one more aspect of scaling to be considered, which is, horizontal scaling. This denotes scaling of aspects including identifying the market needs and the product capabilities that will provide higher business value and give the organization a competitive edge over market trends, as well as help deliver the same to the market at the right time

Figure 8: From Ideas to Delivery

As it goes, this entire end-to-end life cycle is not easy to manage. Starting from the mind-set of the people, to the tools and the adoption of Agile practices, every aspect needs to be considered for every stage of this life cycle. A typical lifecycle involves:

• Ideating a new thought process and identifying a justifiable business plan and value for the idea
• Capturing the necessary capabilities and features to realize the committed business value
• Grooming these feature lists to implementable stories and tasks
• Ensuring the quality of features available in working software
• Continuously integrating the developed code and deploying them in the necessary environments at appropriate time
• Repeating these in an iterative process through inspect and adapt

Figure 9: A typical product increment lifecycle

In a nutshell, for an organization as a whole to successfully adopt the Agile way of working, considering these aspects of scaling would definitely help achieve the required shift and thereby allow them to realize their business values.

References

https://insights.sei.cmu.edu/sei_blog/2017/02/five-perspectives-on-scaling-agile.html https://techbeacon.com/5-proven-techniques-scaling-agile-enterprise https://techbeacon.com/5-tips-scaling-agile-enterprise-environment https://www.infoq.com/articles/agile-fails-enterprise
https://dzone.com/articles/top-8-reasons-why-agile-fails-in-large-enterprises