Tech.IT Forward #4 - Topic 4: Effective Scaling Scrum Team

This is the recap from Theta's talks, please refer the full video here

Scaling Scrum Challenges

Scaling a Scrum team presents several challenges:

1. Limited Capacity for Specialization: A single team stretched across multiple areas, limiting their ability to develop specialized skills or knowledge.

Example: A Scrum team responsible for both data analytics and user interface design finds it challenging to develop deep expertise in either area. As a result, they struggle to implement advanced data visualization techniques or optimize the user experience effectively.

2. Coordination Issues: When multiple functions or features rely on the same team, it becomes challenging to coordinate, slowing down progress on dependent tasks.

Example: A team working on both the authentication system and the reporting module faces coordination issues. When the authentication system requires urgent updates, it diverts resources away from the reporting module, causing delays in its development.

3. Large and Complex Products: A single Scrum team can quickly become overwhelmed if they are responsible for a large or complex product.

Example: A Scrum team tasked with developing an enterprise resource planning (ERP) system, which includes modules for finance, human resources, and supply chain management, becomes overwhelmed by the product's complexity, leading to missed deadlines and incomplete features.

4. Burnout Risk: Team members may experience fatigue and stress as they try to keep the commitment, leading to burnout, reduced motivation, and potentially higher turnover.

Example: Team members consistently work overtime to meet sprint goals for a high-stakes project. Over time, this leads to fatigue and stress, resulting in burnout, decreased motivation, and some team members considering leaving the company.

5. Increasing Cognitive Load: As the team tries to tackle too many tasks, it becomes harder to prioritize effectively, impacting focus on core features and quality.

Example: The team is tasked with implementing new features, fixing bugs, and integrating third-party services simultaneously. This increased cognitive load makes it difficult to prioritize tasks, leading to a lack of focus on core features and a decline in product quality.

6. Lower Quality Output: With too much on their plate, teams may rush through tasks or cut corners, increasing the risk of defects and reducing the overall product quality.

Example: Under pressure to deliver multiple features quickly, the team skips thorough testing and code reviews. This results in a higher incidence of bugs and defects in the final product, affecting customer satisfaction and requiring additional time for fixes.

7. Dependency Delays: As different parts of the product require work from a single team, internal dependencies become difficult to manage, causing bottlenecks.

Example: The team is responsible for both the mobile app and the server-side API. Delays in API development create bottlenecks, as the mobile app team cannot proceed without the necessary backend support, leading to overall project delays.

Team Structure & Boundaries

Scaling Scrum Team

For transformation from 1 big team to multiple team, we should reduce the risk when trying something new to avoid any impact to our current product. The new team (2nd one) maybe a pilot team that could be expanded members and transfer more sub-domain later along with a stable team that keeps current business roadmap.

The scaling should be based on Team Boundaries & sub-domains of business perspective with technical skills & working experiences of members

Scaling Product Owner

Instead of having team-specific product owners, a product owner team (PO team) had been created to accommodate the large number of teams and the globally distributed structure of the organization. With multiple development teams we will have multiple PO accordingly, to organize and scale PO we could apply proxy PO (PPO) will the chief PO (CPO) as manager.

Roles

• Product Owner Team (PO Team):

  • Communicate the overarching vision for the product & make it visible to everyone in the organization

  • Build alignment with key stakeholders to secure support for backlog implementation

  • Generate a single, prioritized backlog; ensuring that duplication of work is avoided

  • Work with the Scrum of Scrums Master to create a minimally uniform “Definition of Done” that applies to all team

  • Eliminate dependencies raised by the teams

  • Generate a coordinated Roadmap and Release Plan

  • Monitor metrics that give insight into the product and the market

• The Chief Product Owner (CPO):

  • Manage the whole product and discuss with PPOs about features, breaking down requirements and assign to the development team

  • Acted as an arbiter between the development organization and the stakeholders external to the development organization.

  • Responsible for maintaining and prioritizing the product backlog on the feature level. The size of features varied considerably from a single team for a couple of months to a year for ten teams.

Assignment

• Depend on the complexity of features, 1 PPO could handle multiple development teams with small features or multiple PPOs will handle the same big/complex feature.

• The PPOs rotated between teams when features were completed.

Team Process & Workflow

• We still keep the same artifacts (product backlog, DoR/DoD, Jira, Quality standard) for all scrum teams

• We scale some meetings that align with multiple scrum team