Designing Agile Project Organization

We're scaling programs/projects, as an SAP implementation is not typically only the implementation of one sub area (for example, Order Management in SAP S/4HANA).

This means that alignment is required across multiple process areas and applications being implemented at the same time.

Scaled Scrum is an approach to implementing Scrum in large, complex projects involving multiple teams working on the same product. It extends the Scrum principles to a larger scale while preserving the core values and goals of the original Scrum framework. Scaled Scrum projects have unique characteristics that distinguish them from single-team Scrum projects. Understanding these characteristics is essential for effective project management and successful product delivery.

• Multiple Scrum Teams: A Scaled Scrum project involves multiple Scrum Teams working in parallel. These teams work collaboratively towards a shared goal. Each team maintains its independence but must also coordinate with other teams to ensure alignment and consistency across the entire project.

• Coordinated Sprints: In a Scaled Scrum project, all teams operate on the same sprint schedule. This simultaneous sprint execution allows for coordinated planning, review, and retrospective meetings, fostering better synchronization, integration, and communication across teams.
• Integrated Product Backlog: Scaled Scrum projects feature an integrated product backlog. While each team may have its individual backlog, there's a single overarching product backlog that guides the work of all teams. This ensures that all teams align with the project's overall objectives.
• Scrum of Scrums: To manage interteam dependencies and coordinate efforts, Scaled Scrum projects often employ a Scrum of Scrums approach. This is a meeting where representatives from each team discuss progress, obstacles, and coordination issues.
• Shared Definition of Done: In Scaled Scrum, all teams agree on a shared definition of Done. This shared understanding ensures consistency and quality across teams and maintains the integrity of the final product.
• Larger Scope and Complexity: Scaled Scrum projects usually have a larger scope and complexity than single-team Scrum projects. They often involve larger codebases, more stakeholders, and more complex integration and coordination efforts.
• Greater Emphasis on Integration and Coordination: Due to the large number of teams and the complexity of the product, there's a greater emphasis on integration and coordination in Scaled Scrum projects. Regular integration helps detect issues early and reduces the risk of late-stage integration problems. Scaled Scrum is an approach to implementing Scrum in large, complex projects involving multiple teams working on the same product. It extends the Scrum principles to a larger scale while preserving the core values and goals of the original Scrum framework. Scaled Scrum projects have unique characteristics that distinguish them from single-team Scrum projects. Understanding these characteristics is essential for effective project management and successful product delivery.

Further needs and characteristics of larger teams are listed in the figure.

This is an example of how a large program would structure itself. The top layer is the Project Management Workstream.

The middle layer is the Application Design and Configuration Workstream, which is built up by multiple Scrum Teams. The teams are preferably split according to the end-to-end processes that they're organized against.

The lower layers are the other Workstreams (which have an integration and overall alignment focus with the Scrum Teams from the Application Design and Configuration workstream).

The following guidelines will help to establish a global Agile program or large project.

• Start Small and Build Gradually: Starting with a small core team to set up the project structure and identify the initial product backlog is a good approach. This team can work on defining the project vision, scope, and initial backlog. Once these are established, more team members can be onboarded gradually as the project progresses.

• Identify Leads and Coaches: As more members are added and scrum teams are built, it's important to identify leads and coaches who can guide the teams. These individuals can help maintain the Agile principles and practices, and provide direction and support.
• Maintain Agile Principles: Even as the project grows in scale and complexity, it's crucial to stick to the Agile principles. This includes maintaining the Scrum framework in a Scrum of Scrums setting where multiple Scrum Teams are working on different aspects of the project.
• Introduce a Product Manager: A Product Manager, or a team of Workstream leads and Chief Product Owners, can help to focus on the overall planning activities. They can coordinate between different teams, manage the product backlog, and ensure that the project is progressing towards its goals.
• Identify and Staff System Teams: System teams focus on integration aspects like architecture, functions, technology, and organizational change management. These teams can help to ensure that the different components of the project work well together and meet the project requirements.
• Use a Hierarchical Product Backlog: A hierarchical Product Backlog that has multiple Product Owners and is decomposed into team Backlogs can be useful in managing the work. This allows for better visibility and control over the work being done.
• Pilot Project: Starting with a pilot project can be a great way to demonstrate Agile success. This can help to gain buy-in from stakeholders and also provide a learning opportunity for the team before they embark on larger, more complex projects.
• Invest in Training and Coaching: It's important to ensure that the team members are well-versed in Agile principles and Scrum practices. Agile Coaches and Scrum Masters can provide training and guidance to the team members to help them work effectively in an Agile environment.
• Regular Reviews and Retrospectives: Regular reviews and retrospectives can help to identify any issues or challenges and make the necessary adjustments. This is a key part of the Agile approach and helps to ensure continuous improvement.
• Communication and Collaboration: In a global project, good communication and collaboration are key. Tools and practices should be in place to facilitate effective communication across different time zones and cultures.
• Respect for Cultural Differences: When working on global projects, it's important to respect and understand cultural differences. This can help to build a more inclusive and effective team.
• Embrace Change: Agile is all about embracing change. The team should be prepared to adapt and make changes as necessary to meet the project goals. Remember, it's important to tailor these principles to the specific needs and context of your project. Agile isn’t a one-size-fits-all approach, so feel free to adapt and adjust these principles as necessary.

In midsize and large projects, each Scrum Team has a dedicated Scrum Master (or in some situations, they may share a Scrum Master across teams.). A Scrum Master shouldn’t have more than three teams, depending on their availability and the team's maturity.

Each team works with one Product Owner, reporting to the Chief Product Owner who's overlooking a large process or business area.

The Solution Architect is typically a shared role in all projects and is called upon by the Product Owners and Scrum Teams as needed to provide general architectural guidelines.

The Project Manager manages the relationship with project stakeholders and oversees the overall project timeline, scope, and budget.

The Project Manager is responsible for delivering the contract and carries the accountability for the delivery of the committed scope.

SAP Activate is all about scaling as it defines all the relevant workstreams and activities during an implementation.

Within the Application Design and Configuration workstream, you'll find the Scrum Teams as depicted in the figure Scaling Agile – Governance in Large (and Mid-Sized) Agile Projects.

The other workstreams are thereby transversal workstreams that focus on the alignment and integration across the project/ program.

Product Owners play a crucial role in Agile development methodologies, such as Scrum. They're responsible for maximizing the value of the product and of the work delivered by the Development Team. They do this by managing the Product Backlog, which contains all the features, functions, and enhancements that need to be made to the product. The Product Owner's responsibilities can be grouped into three levels – strategic, tactical, and operational:

• Strategic: At the strategic level, the Product Owner is responsible for defining the vision for the Product. This includes understanding the market, the customer, and the business strategy, and using this understanding to create a product roadmap. The Product Owner also needs to communicate this vision to the stakeholders and the development team. In relation to Conway's law, the Product Owner must ensure that the product vision aligns with the organization's communication structure. If the organization is divided into many different departments or teams, the Product Owner must make sure that these entities work together effectively to achieve the product vision.
• Tactical: At the tactical level, the Product Owner is responsible for managing the Product Backlog. This includes prioritizing the items in the Backlog based on their value to the business and to the customer, and making sure that the development team understands what needs to be done. According to Conway's law, the way the Product Backlog is managed should mirror the organization's communication structure. For example, if the organization is divided into teams that each specialize in a different area, the Product Backlog should be divided into similar areas.
• Operational: At the operational level, the Product Owner is responsible for making sure that the Development Team has everything they need to complete its work. This includes answering questions, removing obstacles, and making decisions about the product. Again, according to Conway's law, the operational activities of the Product Owner should align with the organization's communication structure. If the organization is divided into teams that each specialize in a different area, the Product Owner should work closely with each team to ensure that they have what they need to do their work.

  In conclusion, the Product Owner plays a key role at all three levels: strategic, tactical, and operational. Conway's law suggests that the way the Product Owner performs these roles should align with the organization's communication structure. This can help to ensure that the Product is developed in the most effective and efficient way possible.

A Scrum of Scrums meeting is a coordination meeting in a scaled Agile context. It's a technique used when multiple Scrum Teams are working on the same project and need to coordinate their work. In this meeting, representatives (usually the Scrum Masters, but it could be any members as long as they have enough understanding of the team's work) from each Scrum Team get together to discuss their work. They share what their team has been working on, what they're going to work on, and any obstacles that are in their way. This helps ensure that all teams are aligned, aware of what the other teams are doing, and can help each other remove impediments. The Scrum of Scrums is different from a daily standup or daily Scrum meeting in several ways:

• Level of detail: In a daily Scrum meeting, the team discusses the specifics of what they'll be working on for that day and any blockers they’re facing. In the Scrum of Scrums, the discussion is at a higher level, discussing progress, dependencies, or obstacles at the team level rather than the individual level.
• Participants: A daily Scrum meeting involves all members of a single Scrum Team. The Scrum of Scrums involves representatives from multiple teams.
• Frequency: While daily Scrum meetings are held every day, the Scrum of Scrums may not be held as frequently. It could be held daily, but it's often held less frequently, such as twice a week or once a week, depending on the needs of the organization.
• Purpose: The purpose of the daily Scrum is to synchronize activities and create a plan for the next 24 hours. The Scrum of Scrums, on the other hand, is focused on coordinating and integrating the work of multiple Scrum Teams. In summary, while the daily Scrum focuses on the coordination of work within a single team, the Scrum of Scrums is used to coordinate work across multiple teams.

Besides the Scrum of Scrums, which is very operational on the teams level, further scaling events are helpful to coordinate vision and goals.

The Product Owner Meeting (Board) is supposed to get all Product Owners together and align on the requirements in case there are potential dependencies. They're setting common goals for Waves and Sprints to ensure that value can be delivered jointly and the teams aren’t pulled into different directions.

Scrum Masters are getting together as well, exchanging on their team progress, common issues and maturities of the teams, and their impediments. Together with the Chief Scrum Master, they're working on strategies to improve the teams and to ensure that the project keeps flowing.

Last but not least, the Scrum of Scrums follow up might be required depending on the outcome of the Scrum of Scrums to realign with the teams, Product Owner, and Architect to solve issues, communicate on the decisions taken with the other teams, and to update the task board.

Theory and Practice aren't always aligned for different reasons.

Therefore, the following figure and links below provide some experiences and lessons learned on popular scaling frameworks.

Scaled Agile Framework (SAFe): https://blogs.sap.com/2019/05/28/using-sap-activate-in-scaled-agile-environment/

The Nexus™ Guide: https://www.scruminc.com/scrum-incs-scrum-at-scale-framework

Scrum at Scale™ Frameworkhttps://www.scrum.org/resources/nexus-guide

Spotify Model: https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/

Large-Scale Scrum: https://less.works/

In the Agile world, there are several scaling frameworks being used by Customer organizations.

SAP Activate is considering them but is mainly based on the less complex Scrum-of-Scrums approach.

Still, it's important to understand the most common scaling frameworks and their implication, as an SAP Activate project might need to be embedded into such an environment.