Key Moments
How To Plan Projects With Distributed Teams
Google TalksKey Moments
Agile planning for large, distributed teams requires multiple levels beyond short sprints, incorporating vision, roadmaps, and release plans to maintain focus and manage complexity. Flying teams together for release planning, even from different continents, is crucial despite the cost.
Key Insights
Agile rhythm, established through time-boxed iterations and daily stand-ups, creates patterns that reduce cognitive load and keep teams focused.
For projects spanning months or involving multiple teams, a multi-level planning approach is necessary, moving beyond the typical two-week sprint.
Release planning, especially for distributed teams, is most effective when all involved members are physically present, with benefits outweighing travel costs.
The product backlog serves as a living change management system, with higher priority features receiving more detail and investment.
Daily stand-ups in distributed teams can be conducted via video link or conference call, with team leads and product owners coordinating across locations.
Retrospectives are best conducted with co-located teams to foster honesty and open communication, as they are difficult to facilitate effectively remotely.
The power of rhythm in agile projects
Agile methodologies thrive on establishing a predictable 'rhythm,' which includes time-boxed iterations (sprints typically lasting two to four weeks) and daily stand-up meetings. This consistent cadence helps team members internalize their workflow, eliminating the need to constantly remember what they should be doing. Whether it's attending a release meeting, planning session, or focusing on testing as a release nears, the established rhythm provides a natural structure. This predictability is key to efficient agile execution, allowing teams to focus on delivery rather than process management. The core of this rhythm is the daily stand-up, a brief meeting at the same time and place each day, where team members report on their progress and any impediments.
Expanding planning beyond the sprint
While short sprints (e.g., two weeks) are effective for detailed work, they can lead to scope creep and a loss of long-term focus for larger projects (three to 16 months) involving multiple teams. To address this, a multi-level planning approach is introduced, based on the concept of 'five levels of planning.' This hierarchical structure provides clarity and direction by looking further ahead than the immediate sprint. At the highest level is the 'vision,' a long-term goal for the product, such as where Adwords should be in the next six months. This is followed by a 'roadmap,' which outlines the product's direction over six to 12 months, typically created by product owners and architects. As a project progresses and gains approval, more detailed 'release plans' (for every three to four months) are created, followed by 'sprint plans' for the immediate iteration, and finally, the 'daily stand-ups' for micro-level coordination.
Vision and roadmap creation
The vision statement, a high-level aspiration for the product, can be defined using methods like the 'elevator statement' (a concise pitch covering product, target market, uniqueness, and competitive difference) or a 'product box' exercise, where teams visualize the product as if it were on a shelf, detailing features and benefits. Metaphors can also be used to describe the system's overall function and goals. Once a vision is established and approved, the product owner, often with input from architects and team members, begins developing a roadmap. This roadmap outlines major features and releases planned for the next six to 12 months. It serves as a guide, providing clarity on the overall direction and key milestones for the entire product, ensuring that development efforts align with strategic objectives. The product owner is typically the individual accountable for the product's success and receives the bonus for it.
Release planning: bringing distributed teams together
As projects move into detailed planning for releases (typically every three to four months), bringing all team members together is paramount, especially for distributed teams. The speaker advocates for physically gathering all involved parties, even those from different continents, for release planning sessions. This involves activities like writing stories on post-it notes and arranging them on a wall, allowing the entire group to collaboratively define the release plan by moving stories into the appropriate iterations, considering dependencies and technical feasibility. While flying people in for release planning is costly, the benefits of enhanced collaboration, problem-solving, and team building far outweigh the expenses. For larger gatherings, multiple breakout rooms can be used, but the core principle is to have everyone present and actively participating in decision-making. This face-to-face interaction is crucial for identifying risks and dependencies that might be missed in virtual settings.
Iteration and daily planning
Once the release plan is set, teams focus on iteration planning and daily coordination. Features are broken down into smaller, manageable stories that fit within a sprint. The product backlog is a dynamic list of all desired features, prioritized and detailed as they approach development. For smaller, individual teams, daily stand-ups can occur organically around a whiteboard or coffee machine. For distributed teams, these meetings are conducted via video conference or phone calls, with team leads and product owners from different locations coordinating efforts. The focus remains on the three standard questions: what was done yesterday, what will be done today, and what are the impediments. This daily check-in ensures continuous alignment and problem-solving across teams, even with significant time differences.
The role of the product backlog and estimation
The product backlog is the central repository for all work to be done. Features are prioritized, and as they move closer to development, they are broken down into smaller user stories and given more detail. Epics, or large chunks of work, are initially placeholders with rough estimates. As an epic is decomposed into smaller stories, the detail and accuracy of estimations increase. For instance, a story planned for the next iteration might be three to five days in size, while an epic far in the future could be a man-year in size. Comparative estimation techniques, such as story points or t-shirt sizes, are used at all levels. The process of decomposing epics into smaller stories inherently improves estimation accuracy, allowing teams to progressively confirm their estimates and commit to delivery.
Inspection and adaptation: demos and retrospectives
At the end of each iteration, teams hold a demo to showcase their completed work to stakeholders, creating a feedback loop for product owners and other interested parties. If multiple teams are involved, individual demos are often consolidated into a single, larger demonstration to provide a holistic view of progress. Following the demo, teams conduct a retrospective. This is a critical meeting for inspecting how the team worked together, identifying what went well, what could be improved, and learning from any missed deadlines or unexpected successes. While demos can be facilitated remotely, retrospectives are best conducted with co-located teams. The candid communication and honesty required for effective retrospectives are difficult to achieve across video links or phone calls, making face-to-face interaction essential for genuine team improvement.
Handling changes and tool selection
Agile planning embraces change. If a demo reveals that the project is off track, the product owner can direct a change in priorities or direction for the next sprint, even if it deviates from the release plan. Significant changes might necessitate a step back to re-evaluate the entire release plan. The process allows for flexibility, and adjustments are made continuously. For tools, the speaker emphasizes using physical tools like post-it notes and whiteboards for collaborative planning, especially when teams are co-located, as they encourage active participation. For distributed teams or for reporting to management, digital tools like spreadsheets or specialized project management software (e.g., Rally) are recommended to track progress, test results, and burn-down charts in real-time.
Mentioned in This Episode
●Products
●Companies
●Books
●Concepts
●People Referenced
Agile Project Planning Cheat Sheet
Practical takeaways from this episode
Do This
Avoid This
Common Questions
Rhythm in agile projects refers to establishing consistent patterns and time-boxed events, such as daily stand-ups and bi-weekly sprints. This creates predictability and reduces the cognitive load on team members, allowing them to focus on their tasks rather than remembering processes.
Topics
Mentioned in this video
An agile software development framework that aims to produce high-quality software and emphasizes teamwork and feedback.
A technique for describing product features from an end-user perspective, often used in agile development.
A popular agile framework that involves time-boxed iterations, daily stand-ups, and potentially shippable product increments.
More from GoogleTalksArchive
View all 88 summaries
58 minEverything is Miscellaneous
54 minStatistical Aspects of Data Mining (Stats 202) Day 7
45 minKey Phrase Indexing With Controlled Vocabularies
63 minMysteries of the Human Genome
Ask anything from this episode.
Save it, chat with it, and connect it to Claude or ChatGPT. Get cited answers from the actual content — and build your own knowledge base of every podcast and video you care about.
Get Started Free