Agile Webinar: Managing Distributed Teams
•
26 gostaram•4,476 visualizações
Transitioning to Scrum is not easy, and for many, distributed teams are the most difficult to manage. In trying to make Scrum work with a geographically dispersed team, increasing efficiency requires adjustments to processes and effective communication and collaboration. This webinar will provide guidance for proper planning and managing, in order to get your distributed teams working smoothly throughout the scrum processes. Dr. Kevin Thompson, cPrime’s Agile Practice Lead, will address key issues such as: • How to have scrum meetings for distributed teams (daily scrum, sprint planning, sprint review, retrospective) • How to cope with time-zone differences • How to cope with language differences • Best practices for collaborating in a distributed team • Best practices for tools that mitigate distributed team impact
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (20)
Semelhante a Agile Webinar: Managing Distributed Teams
Semelhante a Agile Webinar: Managing Distributed Teams (20)
Mais de cPrime | Project Management | Agile | Consulting | Staffing | Training
Mais de cPrime | Project Management | Agile | Consulting | Staffing | Training (10)
Último
Último (20)
Agile Webinar: Managing Distributed Teams
- 1. Managing Distributed Teams Instructor: Kevin Thompson, Ph.D., PMP, ACP, CSP 4100 E. Third Ave, Suite 205, Foster City, CA 94404 | 650-931-1651 | www.cprime.com The leader in training and consulting for project management and agile development
- 2. What is an Agile Process? In principle: Any process that adheres to the principles of the Agile Manifesto “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.” Manifesto for Agile Software Development, www.agilemanifesto.org The concepts arose in software project management, BUT… Change “software” to “products” or “deliverables” to apply more generally Copyright 2011, cPrime Inc. 2
- 3. Principles behind the Agile Manifesto 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10.Simplicity--the art of maximizing the amount of work not done--is essential. 11.The best architectures, requirements, and designs emerge from self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Copyright 2011, cPrime Inc. 3
- 4. Principles behind the Agile Manifesto 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10.Simplicity--the art of maximizing the amount of work not done--is essential. 11.The best architectures, requirements, and designs emerge from self-organizing teams. 12.At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Copyright 2011, cPrime Inc. 4
- 5. Adaptive Spectrum Drives Process Selection All processes have their “sweet spots” Based on scope, effort uncertainty PREDICTIVE REACTIVE Predictive Predictive Adaptive Reactive Processes Plan-Driven Scrum Kanban Waterfall XP • Emphasize SDLC CBPM The Agile Zone Efficiency • Perform poorly Adaptive processes Reactive processes when uncertainty • Emphasize adaptability to • Don’t require planning is high rapid change • Handle unpredictable work • Enable detailed planning well Copyright 2011, cPrime Inc. 5
- 6. Feedback Loops are Critical for Agile Processes Copyright 2011, cPrime Inc. 6
- 7. What Processes are Agile? In practice, these: In practice, not these: • Scrum • Waterfall • Extreme Programming (XP) • Software Development • Kanban Lifecycle (SDLC) • Commitment-Based Project • Rational Unified Process Management (CBPM) (RUP) • Others • Information Technology DSDM, FDD, Crystal Infrastructure Library (ITIL) Is PMBOK Agile? Could be: It’s a collection of practices (tools & techniques), not a process definition Not necessarily: Contains no explicitly agile content (up through V4) Copyright 2011, cPrime Inc. 7
- 8. Three Views of How Work Gets Done • Plan-Driven • Often phase-oriented, delivers results at the end SDLC, Waterfall, RUP, PERT, Critical Chain, Prince2 • Agile with Planning • Planning and execution are epicyclic, repeated at different scales for nested time horizons Scrum, XP, CBPM • Agile without Planning • Processes unpredictable requests efficiently, for types of work where planning is not possible or required Kanban 8 Copyright 2011, cPrime Inc.
- 9. Linear Plan-Driven: Project Lifecycle Initiating Closing Processes Processes define, deliver, authorize Planning & Executing review, shut initial scope Processes alternate to down completion Copyright 2011, cPrime Inc. 9
- 10. Agile with Planning: Project Lifecycle Inception Termination phase phase shuts prepares for down start of Scrum process Implementation phase plans, executes, and delivers for multiple time scales Copyright 2011, cPrime Inc. 10
- 11. Unplanned Agile Project: Kanban Lifecycle Work items arrive in a steady stream, are prioritized daily Kanban (Signboard): Literally, a signal indicating that an action should be performed Copyright 2011, cPrime Inc. 11
- 12. Agile Essentials Adaptability • Expects the unexpected and adjusts gracefully • “Inspect and Adapt” Collaboration • Team members self-organize Members define, allocate tasks Continuous Improvement • Self improvement through reflection, learning from past experience • Stable Team membership increases domain knowledge and productivity over time 12 Copyright 2011, cPrime Inc.
- 13. Scrum: Our Reference Process Scrum • Arose in software engineering • Not tied to any subject domain • Planning is iterative • Execution is iterative Copyright 2011, cPrime Inc. 13
- 14. Select Process: Scrum Summary Product Owner provides ranked requirements, as short narrative descriptions (“Stories”), or bug-fix requests. Set of unscheduled requirements is the “Product Backlog.” Each requirement is a Product Backlog Item (PBI). Small Teams (3—9 people) work in short “Sprints” (2—4 weeks) to implement stories in rank order. • Requirements frozen when Sprint starts—no change requests allowed! Teams self-organize to best apply member skill sets (coding, test development, testing, etc.). • ScrumMaster does not assign tasks • SM focuses on planning, tracking, mentoring, and issue resolution Schedule rules: Don’t extend Sprint to finish incomplete Stories 14 Copyright 2011, cPrime Inc.
- 15. The Defining Characteristics of Scrum • Three roles Three artifacts • Team • Product Backlog • ScrumMaster • Sprint Backlog • Product Owner • Burndown chart Five Time Boxes • Sprint • Sprint Planning • Daily Scrum Meeting • Sprint Review (Demo) Meeting • Retrospective Meeting Copyright 2011, cPrime Inc. 15
- 16. The Time Boxes of Scrum Sprint Planning Meeting: < 8 hrs Plan work to be done in Sprint Sprint: 2—4 weeks Daily Stand-Up Meeting: 15 min Review status and issues Implement requirements in rank order Sprint Review Meeting: 1 hour Product Owner reviews deliverables Retrospective Meeting: 1 hour Learn from experience Copyright 2011, cPrime Inc. 16
- 17. Sample Two-Week Sprint 17 Copyright 2011, cPrime Inc.
- 18. Sprint (Each Day’s Major Activities) Purpose: Implement PBIs in Sprint Backlog • ScrumMaster monitors work, facilitates issue resolution • Team members swarm to implement PBIs in rank order • Ask Product Owner to clarify requirements • Ask ScrumMaster to resolve issues the Team cannot resolve • Team members update status of each task • On starting, finishing, revising “to-do” effort, … • Team members don’t start PBIs they can’t finish in Sprint • Maintain discipline of finishing what is started! 18 Copyright 2011, cPrime Inc.
- 19. Sprint Planning Meeting Purpose: Assign PBIs to Sprint Backlog • ScrumMaster facilitates, enforces selected time box • E.g., 1 hour, if Team has reviewed PBIs carefully in advance Agenda • For each Product Backlog Item (PBI), in rank order 1. ScrumMaster reads PBI to Team 2. Team discusses, asks Product Owner to clarify details 3. ScrumMaster facilitates & records Planning Poker estimation 4. ScrumMaster adds PBI to Sprint Backlog 5. Planning is finished when Sprint Backlog is filled to capacity After: • Team creates Task Breakdowns for Sprint Backlog items Revise scope of Sprint Backlog based on Task estimates 19 Copyright 2011, cPrime Inc.
- 20. Daily Scrum Meeting Purpose: Promote common understanding of Sprint status, and identify issues to be resolved • ScrumMaster facilitates, enforces 15-minute time box • Team members, ScrumMaster, Product Owner attend Agenda 1. ScrumMaster shows burndown chart, describes progress 2. Each Team member describes What I’ve done since the last Daily Stand-Up meeting What I plan to do before the next Daily Stand-Up meeting What issues I’m facing that I need help to resolve In meeting: • Decide who will collaborate to resolve each issue after the meeting (“sidebar discussions”) 20 Copyright 2011, cPrime Inc.
- 21. Sprint Review Meeting • Purpose: Confirm acceptability of implementations • ScrumMaster facilitates, enforces selected time box Agenda 1. Team demonstrates finished PBIs to the Product Owner • Team members decide who will do the demonstrations. One person does all; round-robin style; etc. 2. Product Owner provides final decision on whether implementations are acceptable for release • If not, then they are not released Should be rare, since PO monitors & evaluates throughout Sprint. After: • Product Owner writes Stories for changes to implementations 21 Copyright 2011, cPrime Inc.
- 22. Retrospective Meeting Purpose: Learn from experience, and improve • ScrumMaster facilitates, records, enforces time box • Say, 60 minutes total: 30 for recording, 30 for discussion Agenda 1. Review status of work items from previous Retrospective 2. Team members, Product Owner, ScrumMaster answer What went well, that we should do again? What needs improvement? What specific improvements should we make? 3. Specify follow-up actions 1. Prioritize improvements 2. Select top few to address 3. Select owners to drive improvements 22 Copyright 2011, cPrime Inc.
- 23. Agile Collaboration by Swarming How many people can work on Story #1? They swarm on #1. How many people can work on Story #2? They swarm on #2. How many people can … Copyright 2011, cPrime Inc. 23
- 24. Agile Manifesto Principles Affected by Geographic Distribution Business people and developers must work together daily throughout the project. The most efficient and effective method of conveying information to and within a development team is face- to-face conversation. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Copyright 2011, cPrime Inc. 24
- 25. Why Co-Location is Preferred • Members work together easily throughout day • Proximity encourages interaction • Information propagates rapidly • Communication is Osmotic • Members absorb information from questions, answers in background • Members can chime in if they have something to contribute • Agile projects favor in-person communication over documentation • Co-location encourages and enables good communication • Distribution impairs it, requires more documentation 25 Copyright 2011, cPrime Inc.
- 26. Distributed Teams: Best Case • Scrum Teams are distributed • Scrum Team members are co-located per Team • Compared to total co- location • Intra-Team communication is the same • Cross-Team communication somewhat more difficult, but not hard • Cross-Team work synced via “Scrum of Scrums” meetings 26 Copyright 2011, cPrime Inc.
- 27. How to Implement Cross-Team Requirements • Synchronize with “Scrum of Scrums” meetings • Purpose: Identify & address cross-Team issues • Frequency: As needed (daily, weekly,… ) • Participants: • One from each team Team Member, ScrumMaster • Facilitator • Agenda: • Each person describes What my Team is doing that may affect other Teams What issues my Team needs help to resolve • Resolve issues in meeting, if possible • Identify follow-up actions and owners Diagram by Clinton Keith, www.gamasutra.com Copyright 2011, cPrime Inc. 27
- 28. Distributed Teams: Other Cases • Members of Scrum Team are distributed • Compared to co- location • Communication latency increases with fragmentation, time-zone separation • Productivity decreases • Non-overlapping time zones make collaboration 28 Copyright 2011, cPrime Inc. difficult
- 29. Best Practices for Meetings Working Sprint Daily Sprint Retro- Comment Time Planning Stand-Up Review spective Full overlap All attend All attend All attend All attend Co-located Full overlap All attend All attend All attend All attend Distributed Partial All attend All attend All attend All attend overlap Adjacent All attend All attend All attend All attend Far apart All attend Sub-groups, Rotate Sub-groups, One SM SMPs meet. demo to PO SMPs meet. proxy (SMP) SMPs, SM among sub- SMPs, SM per sub- provide all groups provide all group findings to findings to full Team. full Team. Full Team Sub-group meets twice nearest to / week PO demos Copyright 2011, cPrime Inc. 29
- 30. Distributed Agile Case Study: S Corp. • Three Teams • ScrumMaster in CA • Product Owner in PA • 1/3 Team members in CA • 1/3 Team members on East Coast • 1/3 Team members in Shanghai, China • Adaptations • One proxy for ScrumMaster in Shanghai • 15 min Daily Stand-Ups Twice-weekly 30-60 minute meeting/Team • Sprint Planning meetings One for US, one for Shanghai • Sprint Retrospectives One for US, one for Shanghai • ScrumMaster in all meetings 30 Copyright 2011, cPrime Inc.
- 31. Distributed Agile Case Study: Z Corp. • SixTeams • ScrumMaster in CA • 3 Product Owners in CA • 1/6 Team members in CA • 5/6 Team members in Beijing, China • Adaptations • One proxy for ScrumMaster in Beijing • Six 15 min Daily Stand-Ups Sun-Thur, 8-10 PM PST • Sprint Planning meetings One per Team, staggered so POs can attend all, with POs facilitating • Task Breakdowns Drafted in Beijing, reviewed in CA • Sprint Retrospectives One for all in CA, one for all in Beijing • ScrumMaster in all meetings 31 Copyright 2011, cPrime Inc.
- 32. Case Study: Xebia Corp (Jeff Sutherland) • Three Distributed Teams • Across The Netherlands & India (3 hrs separation) • One Product Owner • Three ScrumMasters • Adaptations • Start small, then grow • Start co-located team, members from all locations • Later seed distributed teams with experienced members • All Scrum meetings Video-conferenced via Skype, except for… • Sprint Review meeting Held in The Netherlands 32 Copyright 2011, cPrime Inc.
- 33. Best Practices for Engaging & Aligning People 1. Start small and co-located • Members come from all locations • Work together for 3 Sprints 2. Spread the wealth • Seed new Teams in other locations with seasoned members 3. Understand cultural differences • ScrumMasters provide safe environment, encouragement to enable people from hierarchical cultures to adjust to Agile culture of egalitarian collaboration 4. Build personal relationships face to face • Encourage travel to other offices • Socialize with the visitors 5. Use video in all meetings 33 Copyright 2011, cPrime Inc.
- 34. Closing Thoughts • Distributed Agile projects are not desirable • Distributed Agile projects are possible • Technology and common sense adaptations reduce but do not eliminate pain 34 Copyright 2011, cPrime Inc.
- 35. The Most Important Thing to Remember The process exists to help the people succeed “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Individuals Processes Interactions Tools 35 Copyright 2011, cPrime Inc.
Notas do Editor
- ** Notebook Question 1Describe balance between left side (soft skills) and right side (hard skills). The Manifesto says the left takes precedence, but we need both.Going all the way to the left works for the “three people in a garage startup company,” which has zero to one customers, but leads to chaos and gridlock when we try to scale up.Going all the way to the leads to cumbersome, slow-moving, documentation-heavy projects that take a very long time to deliver the wrong thing.
- Highlighted principles are impacted by geographic distribution.
- Highlighted principles are impacted by geographic distribution.
- ** Notebook Question 7This slide shows typical feedback loops for a Scrum process, involving internal people who work together to make things, and external people (stakeholders, customers) who want things made. The terminology is from Scrum, but the concepts are common to Agile processes in general.Internal PeopleIn a Scrum process, the Product Owner writes requirements, the Team members implement requirements and test the implementation.External PeopleStakeholders and customers want things made.Feedback LoopsTop Level: Work is done in iterations, not in a long, continuous process. Every few iterations, the Product Owner meets with Customers and Stakeholders to show what has been accomplished and what is planned, and get feedback regarding how well the completed or planned work aligns with their needs. Middle Level: Requirements specifications are called Stories, and are implemented and tested by the Team members. At the end of each Iteration, the Team members demonstrate completed Stories to the Product Owner, for approval or decision that re-work is required.Bottom Level: In real time, as needed, Team members call on the Product Owner for guidance about requirements, to ensure that deliverables will meet the Product Owner’s expectations.
- ** Notebook Question 8-10
- SDLC: Software Development Lifecycle. An “umbrella terms” for plan-driven approaches to software projects.Waterfall: The classic phase-oriented model described by Winston Royce in 1970. For software projects.RUP: Rational Unified Process. A comprehensive framework for building iterative phase-oriented SDLCs.PERT: Dependency-oriented planning. For any kind of project.Critical Chain: Resource-oriented planning. For any kind of project.Prince2: A process framework that addresses process stages at a relatively high level. It leaves a lot of freedom for customization at the tactical level. For any kind of project.Scrum and XP are discussed in detail in following slides.CBPM (Commitment Based Project Management) is an agile process optimized for hardware projects, and used in microelectronic component design.Kanban is discussed in detail in following slides.
- This is the classic PMI view of how a process works for a project. Process Groups may or may not represent sequential phases. They may, in the simplest case, but in complex projects may overlap, alternate, or both.
- Epicyclic:Consisting of nested cycles. Scrum, XP, and CBPM are epicyclic. These processes are used for environments where uncertainty about requirements and effort is high, and especially when useful production capabilities can be delivered incrementally.Summarize different phases and cycles.Inception: Includes startup work that must be done before the specified process can start. Inception occurs when starting a new product or service from scratch. It is not a part of the (iterative) work of creating multiple releases of a product over time. Vision: Define concept for product.Roadmap: Long term plan, for one to a few years. Includes major milestones at a summary level, and spans multiple Releases or Projects.Release or Project:A medium-term (weeks to months) span of time, at the end of which results are delivered to customers. Includes fine- to medium-grainedy specifications of product functionality.Iteration: A short term (1-6 weeks) period spent developing functionality, for which all requirements are fine-grained and directly implementable in this span of time without further decomposition.Day: A single day may have any activities, as required, and involves fluid and dynamic collaboration among Team members to get work done.Termination: This refers to all activities associated with shutting down a Project. It is the same thing as the PMI Closing Process Group.====Note: Inception and Termination are rare occurrences in agile / Scrum projects, because the default mode of working is to continue adding capabilities and deliverables to an existing set, not to start and finish distinct projects frequently.
- Kanban omits planning, and focuses on prioritization, tracking, and optimizing throughput. It is commonly employed in production support, Information Technology departments, hospital Emergency Rooms (as “triage”), and in any environment where work items are not known in advance.Kanban originated in manufacturing, and was adapted for software development. “Kanban” is a Japanese word meaning “signboard,” and in manufacturing refers to a signal indicating that some action should be performed. The use of signals to request action is consistent with the “pull” nature of projects or processes in which Kanban is generally employed.A Kanban project has no phases associated with starting or ending a project. All work is handled the same way, as tasks that flow through states.
- Adaptability: “Inspect and Adapt” is a Scrum motto. It means that we do not rely on or invent process solutions to all problems. Instead, we use process solutions when they make sense, but emphasize looking at where we are right now, and identifying the best way to proceed.Collaboration: Teams should have all skills needed to implement work, from customer-facing aspects on down. Team members self-organize by owning the responsibility to (A) define tasks needed to implement requirements, and (B) deciding which Team members will do which tasks, in what order, and how, with the goal of minimizing implementation time.Continuous Improvement: For teams to become highly productive, they need stable membership over time, and a commitment to improvement. Stable teams will gradually gain or lose members, but will not be formed or disbanded frequently. Teams may be disbanded for good reasons, but resource managers should plan for Teams to last at least six months, and preferably longer.Teams learn how to improve all the time, informally, but the formal mechanism for continuous improvement is the Retrospective meeting (which is discussed later), which occurs at the end of every iteration. The Retrospective meeting captures information about what did or didn’t work well in the last iteration. Then Team members select top items requiring improvement, and decide who will work on them. The next Retrospective meeting will start with a review of how the last set of improvements worked out (or didn’t), before capturing more information about the most recent iteration.
- Most agile processes include planning, but not all. The most popular agile process is Scrum, which is an iterative process that divides the calendar into short iterations called Sprints. In each Sprint, a Team starts and finishes implementation and testing of several small requirements. Scrum is not tied to any industry, and can be used for any project for which its characteristics are well-suited.Scrum is used in environments where plan-driven processes are inappropriate, because they have high uncertainty around requirements and effort which make plan-driven schedules unreliable. Instead of defining scope and estimating schedule, Scrum defines schedule (such as a Sprint) and estimates the scope that fits into it. Scrum optimizes risk mitigation (through completing work quickly) over efficiency.A Scrum process does not have planning and execution phases. Planning (for future Sprints) is done in parallel with implementation work (in the present Sprint).
- ** Notebook Question 6
- Key Points:Activities recur at fixed intervals on the calendar, e.g. every two weeks for a two week Sprint. So if a Sprint Planning meeting occurs next Monday morning at 8 AM, there will be another Sprint Planning meeting every two weeks after that, also at 8 AM on Mondays.The purpose of the Sprint is to implement Backlog Items, but some time must be allocated to the various activities, leaving less time for work. The sample schedule shows that overhead due to meetings takes up 11 hours, leaving 29 hours to implement Backlog Items.
- ScrumMaster ResponsibilitiesThe ScrumMaster has well-defined responsibilities for facilitating meetings and estimating Team velocity, but also exercises soft skills a lot. He talks to Team members informally, reviews status information throughout the day, and generally maintains situational awareness that the more focused Team members generally don’t have. He looks for issues that are not being addressed, and brings them to the attention of Team members who can address them. He keeps an eye out for Team members who are having problems, and helps them work through the problems. He is the escalation path for any problem Team members can’t handle on their own, whether task-related or personal.[Instructor should give examples from personal experience.]Example: “The dog ate my laptop.” Action: ScrumMaster does what is needed to get Team member a new laptop.Example: “I don’t know how to do X.”Action: ScrumMaster says, “Joe in IT knows how to do X. Let’s go talk to him and see if he can help.”Example: ScrumMaster is sitting at his desk when a Team member comes by. Team member says, “The second floor is being re-modeled, so everyone there is on our floor, and we’re doubling up in our cubicles. Marcie, from Marketing, is in my cube. She chews bubble gum all day long, and pops her bubbles. I can’t get any work done, because the popping is driving me crazy, and I can’t think.”Action:ScrumMaster does whatever is needed to solve the problem. This could include talking to Marcie, talking to her manager, seeing if it is possible to move people around so the problem goes away, etc.Product Owner ResponsibilitiesThe Product Owner must be available for discussions about requirements, and to review work-in-progress when Team members have something to show. From the Team’s perspective, the Product Owner is the final authority for all requirements-related questions. However, the Product Owner may consult with customers and stakeholders to resolve questions, as needed.Team member ResponsibilitiesTeam members are responsible for estimating Stories, creating Task Breakdowns and Task Estimates, getting the work done, updating task status in the tracking system, and collaborating with the Product Owner in real-time (or close to it) for clarification of requirements.
- ** Notebook Question 7-8
- ** Notebook Question 9-10
- ** Notebook Question 11
- ** Notebook Question 12In practice, each item is often a “Story,” which is used as a generic term for any requirement to be implemented via Scrum, XP, or Kanban. The goal is to finish each item as quickly as possible, to minimize risk of non-completion (risk mitigation is more important than efficiency). We do this by maximizing resources applied to each Story, via Swarming.
- ** Notebook Question 15
- We don’t need to go through the slide in detail, especially as the Scrum meetings have not been described yet. We do want to point out that the importance of having everyone present varies across different meetings. Sometimes everyone must be present, even when this is inconvenient (e.g., Sprint Planning). Sometimes it is acceptable to have sub-groups have separate meetings (e.g., Daily Stand-Up) or even have just one sub-group hold the meeting (e.g., Sprint Review).