Agile Development Teams: Scope and Scale with Mike Cohn

Summary

In this episode of 'Software Conversations', the discussion revolves around scaling agile methodologies to large teams, contrary to the common perception that agile only works for small teams. The speaker emphasizes that agile can be effectively applied to large projects with hundreds of people by employing a hierarchical structure with a 'chief product owner' at the top, cascading down to various product owners for different components. The episode also touches on the importance of cross-functional communication and the challenges of estimating and planning in agile projects, advocating for relative sizing and velocity-based predictions for project duration.

Takeaways

• 😀 Agile methodologies can be applied to large teams and projects, not just small teams as often depicted in literature.
• 🔍 Large-scale agile projects may involve multiple teams, potentially hundreds, working in coordination rather than a single massive team.
• 👤 The role of a 'chief product owner' or equivalent is crucial for maintaining the overall vision and guiding the project at a high level.
• 🏢 In large enterprises, agile can be scaled by having a hierarchy of product owners for different components of the project, similar to how Microsoft might manage different parts of Office suite.
• 🔄 Agile scaling involves both vertical alignment of teams and horizontal communication across teams to prevent silos and ensure knowledge sharing.
• 💬 Encouraging communication among large groups, such as 400 programmers, can be achieved through formal and informal means, tailored to the project.
• 📈 Agile estimating involves relative sizing of tasks compared to one another rather than absolute time estimates, using units like story points.
• 🚀 Agile planning starts with estimating the size of tasks and then considering the team's pace to derive a duration, similar to estimating a real-world trip.
• 🔢 Teams use abstract units for estimating (e.g., story points, gummy bears, Cheez-Its) to establish relative sizes of tasks within a project.
• 🔮 For projects that require upfront estimates without the benefit of an existing team's velocity, more complex techniques are needed, which may be detailed in the books mentioned.
• 🌐 The script suggests that scaling agile to very large projects is challenging but possible with the right structures, like chief product owners and cross-functional teaming.

Q & A

What is the common misconception about agile teams according to the transcript?

The common misconception is that agile teams are only effective with small teams, like the original XP team at Chrysler, and that larger teams of 50-200 people in Fortune 500 companies are a precursor to failure.

How does the speaker describe the scaling of agile methodologies to larger teams?

The speaker explains that agile scales up well, with large projects involving multiple teams that coordinate their work rather than a single large team. The concept involves a hierarchy that understands the vision, with a 'chief product owner' at the top passing the vision down to sub-teams.

What is the role of a 'chief product owner' in a large agile project?

A 'chief product owner' has the overall vision for the project and is responsible for passing that vision down to sub-teams, ensuring alignment and coordination across the various teams working on different aspects of the project.

How does the speaker use Microsoft Office as an example to illustrate the agile scaling process?

The speaker uses Microsoft Office as an example to show how a visionary might have a vision for the entire suite, with 'product owners' for individual applications like PowerPoint, Excel, and Word, each with their own vision for their respective products.

What is the importance of cross-functional communication in large agile teams?

Cross-functional communication is crucial for ensuring that different teams, such as client-side and server-side developers, are aware of each other's work and can coordinate effectively, avoiding silos and promoting standard practices across the board.

What does the speaker suggest as a method for estimating software projects in an agile context?

The speaker suggests estimating software projects by first estimating the size of the task and then considering the pace at which the task can be completed, similar to estimating real-world activities like driving a certain distance at a certain speed.

How should agile teams estimate the size of tasks in relation to each other?

Agile teams should use relative estimates to determine the size of tasks in comparison to others, using abstract units that are meaningful in terms of relative size but not specific time units.

What is the purpose of using abstract units like 'Cheez-Its' or 'gummy bears' in agile estimation?

These abstract units serve as a way to provide relative estimates that are easy to understand and compare, without being tied to specific time units, which can be misleading or difficult to estimate accurately at the outset of a project.

How can teams gain predictability in their agile projects after starting work?

Teams can gain predictability by observing their pace of work after starting the project, using the actual progress made to estimate how long the remaining work will take, thus providing a more accurate forecast of project duration.

What is the challenge when estimating before the team has started working on a project?

Estimating before the team has started working on a project is challenging because there is less information about the team's pace and capabilities, which requires more complex estimation techniques that may be detailed in the speaker's book.

What are the three things that teams need from the company according to the first article on scrum?

According to the first article on scrum, teams need money, moral support, and guidance from the company to be successful in their agile processes.