Agile Webinar: Managing Distributed Teams

Editor's Notes

• #3: ** 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.
• #4: Highlighted principles are impacted by geographic distribution.
• #5: Highlighted principles are impacted by geographic distribution.
• #7: ** 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.
• #8: ** Notebook Question 8-10
• #9: 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.
• #10: 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.
• #11: 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.
• #12: 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.
• #13: 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.
• #14: 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).
• #17: ** Notebook Question 6
• #18: 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.
• #19: 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.
• #20: ** Notebook Question 7-8
• #22: ** Notebook Question 9-10
• #23: ** Notebook Question 11
• #24: ** 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.
• #26: ** Notebook Question 15
• #30: 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).