Agile Development PDF

Agile The new work culture Franck D. NASSIRI 2024  What is Agile? Recommended readings: ü Project Management: Improving performance, reducing risk (PwC) ü Pulse of the profession 2017 ü Delivering large-scale IT projects on time, on bud...

Agile The new work culture Franck D. NASSIRI 2024  What is Agile? Recommended readings: ü Project Management: Improving performance, reducing risk (PwC) ü Pulse of the profession 2017 ü Delivering large-scale IT projects on time, on budget, and on value (McKinsey) ü Listen to the following audio recorded conversation on HBR website: https://hbr.org/ideacast/2016/04/understanding-agile-management ü Read the Article “Bureaucracy Can Drain Your Company’s Energy. Agile Can Restore It.” THE WATERFALL APPROACH & METHODOLOGY  Pools of specialized resources: functional managers Concept / Test / Development Prototyping Design validation Project Team 1 Project 1 Each team member has 2 bosses Product 1 Project 2 Product 2 Project 3 Product 3 27 septembre 2024  Traditional Project Management (Waterfall) Traditional Project Management, also known as Waterfall Project Management, is a sequential and linear approach to managing projects in order to develop new products The methodology gets its name from the way tasks are completed: one after another, in a flow that resembles a waterfall From the ideation and initiation stages to project closure, every phase in the project's life cycle follows a strict, sequential order, much like water cascading down a fall, with very limited or no opportunity to go back upstream Every aspect of the project, including the scope, timeline, costs, and quality standards, is meticulously defined before the project work begins Stages typically include requirements definition, design, development, testing, implementation, and maintenance Traditional Models for Project Development (Waterfall)  Traditional Models for Project Development (Waterfall) Problematic: Too many projects fail (70% according to 4PM.com) and too many product features remain unused by the end user Some consequences: ü The failure of IT costs the U.S. economy about $50-$150 billion annually (source: HBR, Why Your IT Project May Be Riskier Than You Think) ü Only 40% of projects at IBM (2008) meet the company's three key goals (schedule, budget, and quality). (source: IBM)  Traditional Models for Project Development (Waterfall) Over half of all IT projects become runaways Ten major government contracts have over $16 billion in cost overruns and are a combined 38 years behind schedule. Only 2.5% of global businesses achieve 100% project success and over 50% of global business projects fail. More than $8 billion of $53 billion the Pentagon spent on Iraqi reconstruction projects was lost due to fraud, waste, and abuse. Source: Project Management, Achieving Competitive Advantage, Jeffrey K. Pinto , Pennsylvania State University, 5th edition  Traditional Models for Project Development (Waterfall) Waterfall project development process works well when: Requirements are very well understood and fixed at the outset of the project Product definition is stable and not subject to changes Technology is understood Ample resources with required expertise are available freely The project is of short duration  Traditional Models for Project Development (Waterfall) For many types of projects—short term, small scope, construction, event planning, and process improvement—these traditional project assumptions are not wrong Projects with limited or narrow goals or those that will complete quickly generally do not suffer from significant problems of uncertainty Their short timeframe minimizes environmental disruptions  Traditional Models for Project Development (Waterfall) But what happens if requirements change in the middle of the project’s development? Or when the project has to be managed in a highly unpredictable environment? Or when the customer delivers a new set of “critical” features that must be part of the final product? Or when a new technological innovation allows our team to streamline the product we are working on to make it more user-friendly? And what if the initial assumptions or project scope were poorly determined and communicated by the customer?  Agile: The new Model for Project Development Under all these circumstances, the waterfall model can lead to a rigid process that will not deliver value to the customer, either because their needs are constantly changing or because they did a poor job of initially articulating exactly what the project is supposed to do It is for the purpose of addressing these critical issues that Agile Project Management was created  In class Reading Article: “It’s an Agile World” Share your thoughts with the class  What is Agile? Agile Project Management is a flexible, iterative approach to managing projects Unlike Traditional Project Management, where every aspect of the project is meticulously defined before work begins, Agile embraces change and adaptation throughout the project lifecycle  What is Agile? Agile comes from the following manifesto, which is only 68 words long The story of the manifesto is that 17 thought leaders in software development got together in Snowbird, Utah They found they had the same kind of problems: their approaches to software development were overly plan driven, and they felt like they weren't getting the kind of outcomes that they could reasonably achieve And so they talked about alternatives and they arrived at what you see in the following manifesto, the 4 key values: Agile organizations examples  What is Agile? Agile is not about a new method or a new process Agile is: ü A Mindset ü A Culture As Agile is a culture, so a set of principles, it can be applied to any organization Individual Processes Interactions Tools Working Comprehensive Software Documentation Customer Contract Collaboration Negotiation Responding Following to Change a plan  Output vs. Outcome Outputs tell the story of what you produced. ”Output measures” do not address the value or impact of your services for your clients On the other hand, an outcome is the level of performance or achievement that occurred because of the activity or services your organization provided In class Reading: “It’s not just Semantics: Managing outcomes vs outputs” HBR It’s Not Just Semantics: Managing Outcomes Vs. Outputs Harvard Business Review, by Deborah Mills-Scofield  What is Agile? Agile means that if you achieve the appropriate approach and behavior at work, this would mean you’d do very well in terms of the “outcomes” for you and for your customer Value Outcome in a typical Agile approach vs. Output in a not-Agile context  What is Agile? She sees these blue buttons that's she's supposed to make and she thinks, for whatever reason, I don't think this is going to be on the mark with the user But she's so overwhelmed with obligations and dates and emphasis on getting “output” created rather than driving to a good “outcome” that she just wants to finish her work and go home And when the software comes out, no surprise, but you know, users don't like it So that is the kind of day to day level that we're trying to avoid  What is Agile? In an Agile environment she wants to go and talk to her colleagues about things she's observed, and raise these questions about, are these blue buttons really the right thing? And what might we do instead if it doesn't seem like the right decision? And hopefully we're able to create small, self-organizing, interdisciplinary teams And that “interdisciplinary collaboration” is really at the heart of the successful practice of Agile  Interdisciplinary Project Team Product Concept / Owner Engineering Design Head of / QA Projects Individual Processes Interactions Tools Working Comprehensive Software Documentation Customer Contract Collaboration Negotiation Sales & Scrum Responding Following Customer Master to Change a plan Support Here is a typical interdisciplinary project team, with the “Product Owner” playing a central role, the main contact point with the customer/users Less emphasis on “project management” tasks and more on building “valuable outcome” for the users  Interdisciplinary Project Team Product Concept / Owner Engineering Design Head of / QA Projects Individual Processes Interactions Tools Working Comprehensive Software Documentation Customer Contract Collaboration Negotiation Sales & Scrum Responding Following Customer Master to Change a plan Support The job of the former ”team leaders” transformed into “Scrum Masters”, they guarantee Agile rules are applied Sales, marketing and support teams should be integrated: they own an important body of information and knowledge about users/customers  Interdisciplinary Project Team Product Concept / Owner Engineering Design Head of / QA Projects Individual Processes Interactions Tools Working Comprehensive Software Documentation Customer Contract Collaboration Negotiation Sales & Scrum Responding Following Customer Master to Change a plan Support The thing that engineers and designers hate most is when the sales people and managers submit change requests, late in the development cycle What Agile does is to help engineers to interact with managers and to get the right insights into users’ needs and wants and to deliver frequent partial versions of the product and to get customer feedback on a regular basis (Minimum Viable Product (MVP) or Lean approach)  AGILE USER STORIES  Agile User Stories In a traditional project planning process, the project developer’s viewpoint is considered most important Developers are looking at the project from the inside perspective: ü How long will development take? ü How many work packages (WBS) and tasks are necessary to complete the project? Project developers are interested in tasks because they allow them to accurately and efficiently plan the work and build their cost estimates The more detailed and specific the project tasks are, the easier it is to create these plans and estimates  Estimate project resources Determining a waterfall projects’ tasks: The Work breakdown structure To estimate project time, costs, and skills, you need to create a Work Breakdown Structure and use it for rough estimates. The lowest level of decomposition in the Work Breakdown Structure is also called a work package  Agile User Stories User stories are different and very important for understanding the real needs of the client (they must represent the “voice of the customer”) User stories are written by or for customers as a means of influencing the development of the functionality/feature of the product End-users explain what they do, what they need, and how they can make use of different product features to do their job better  End-users examples (or Personas) Fanny the researcher Paul the call center Susan the delivery agent Amy the sales manager George the construction engineer  Agile User Stories User stories are short, simple descriptions of a feature described from the perspective of the person who desires the new capability, usually the user or customer of the product being developed. They typically follow a simple template: As a < type of user >, I want to < do something> so that I can < derive a benefit>. Who are we building it for, who the user is? — As a What are we building, what is the intention or goal? — I want to Why are we building it, what value it brings for the user? — So that I can “from the perspective of the person who desires the new capability” means that user stories do not describe how to implement it, leaving out the technical aspect User stories are often written on index cards or sticky notes, stored in a shoe box (called Product Backlog), and arranged on walls or tables to facilitate planning and discussion  Agile User Stories As such, they strongly shift the focus from “writing about features” to “discussing them” User stories do not replace specifications. Instead, they are a backdrop for discussion In other words, their only job is to facilitate high quality narrative, interdisciplinary collaboration, and drive to good decisions about development INTRODUCTION TO SCRUM  Agile Methodologies Scrum is one of the most prevalent agile methodologies and a lot of the concepts we study in this course come from scrum Extreme programming (XP) is another methodology that actually perceives the agile manifesto. And it's more focused on coding methodologies extended forward to project management practices And finally Kanban is sometimes presented as an alternative to these and in reality it's a set of methods to reduce work in progress What is Scrum? https://www.youtube.com/watch?v=M6aShtkL6uw 27 septembre PROJET 2024 Sous titre  Agile environment A key Agile principle is to work on “incremental product development, delivering frequently in weeks, rather than months” In other words, it’s better to run several sprints than just one marathon Working on short development increments allows for a shorter feedback loop, making it easier to adapt and respond to change The end of every Sprint is an opportunity to reflect on what happened, gain learning, identify improvements, adapt and change course In environments of high uncertainty (that are, therefore, unpredictable) long feedback loops can be a recipe for disaster.  Agile environment “Valuing individuals and interactions above processes and tools” Hence, team members are not just preoccupied with their own progress, but are also concerned with their teammate’s advancement Agile teams are independent and autonomous: they decide how to plan the Sprint, how to organize themselves, and how to track progress Regarding communication channels, for example, some teams decide to use Slack, others create WhatsApp groups, others simply use G-chat  THE AGILE DEVELOPMENT STEPS  Agile development Some of the agile user stories will first be Epics Epics will be decomposed into smaller stories that fit more readily into a single iteration, also called a “Sprint” A Sprint should take about 1 to 4 weeks Several Sprints can then be integrated into one product release Release can only first be internal and not external to the company Stages in “one Sprint”  Sprint Planning The entire Scrum Team defines the work to be performed in the Sprint The Scrum Master ensures that the event takes place and that all members of the Scrum team understand its purpose ü Introduces the Sprint Backlog to the development team and coordinates their efforts to achieve the Backlog items The event must answer these questions: ü What can be delivered in the increment (time-box) resulting from the upcoming Sprint? ü How will the work needed to deliver the increment be achieved? Sprint Planning in remote working  Daily scrums (or Stand-up sessions) Agile teams are small, five to ten/eleven people (2 pizza teams): Questions to be answered during these sessions: 1. What did we accomplish yesterday? 2. What do we need to accomplish today? 3. What difficulties/barriers are slowing the progress? The team is self-governed, self-organized, with a high level of inter-team support, deciding during these sessions who should be doing what, with no command and control approach  Daily scrums (or Stand-up sessions) The team effort, over the course of one sprint, is measured as a function of the number of User Stories developed Daily scrum in front of the Kanban board Source: https://tech.deliveryhero.com/spice-up-your-daily-standup-walking-the-board-with-a-conductor/  Daily scrums (or Stand-up sessions) for remote team working If team members don’t all participate in the event—or if there’s a risk that they’ll be distracted during the call—then it’s important to calibrate the process to the context The right approach is likely to be team specific, depending on team maturity and existing norms Recording Standup meetings might be an option Daily scrums: The Kanban board Source: Scrum-basics.blogspot.com Daily scrums: The Kanban board Kanban uses visual cards/queues to manage tasks ( Kan=Visual, Ban= Cards/Board) Kanban Methodology is based on following Lean Principles: ü Pull Method ü Continuous Flow ü Waste Elimination Source: Scrum-basics.blogspot.com  Daily scrums: The Kanban board & remote working Some teams think the importance of keeping their Kanban clean, up to date, and well documented increases when working remotely A user story “inadvertently” left active would be a minor matter for a team working in the same room, because a team member could quickly confirm its status verbally But working in a remote setting, team members might work on a story for hours before getting an alert that it should have been closed Source: Scrum-basics.blogspot.com  Development Work The time when the actual work of the project is being done during the Sprint Development Work must be heavily coordinated between Scrum team members to ensure that no efforts are being wasted  Sprint Review During the Sprint Review, the Scrum team and other key stakeholders work closely to verify what was done on the Sprint Based on these results and any subsequent changes to the Product Backlog, the Scrum team now plans the next things to be done to add value, including product features that need completing or modifying Sprint Reviews are informal meetings: they are not status meetings, and the presentation of the completed Sprint Backlog is only to encourage team feedback and encourage collaboration. Sprint Review, remote working  Sprint Retrospective A meeting that is held to evaluate how the previous Sprint went: ü What worked? What didn’t? ü Where potential improvements can be made to the Sprint process? A valuable Sprint Retrospective should also include an action plan for identifying and implementing improvements to the process The Scrum Master works with the Scrum team to constantly improve communications and identify improvements that will be introduced during the next Sprint Sprint Retrospective, remote working WHAT MAKES AGILE HARD IN PRACTICE  What Makes Agile Hard In Practice There's nothing extremely difficult to understand in this course But as individuals working with groups of people, a lot of this stuff is really hard to do in practice To achieve valuable outcomes we need to be observant, collaborative, support other people, get ideas from people and share our own ideas with them : it's really not part of our normal emotional wiring We have to train ourselves to do that We have to practice to make it more comfortable And it's just important to acknowledge “that reality” as you practice Agile and continue to work through it  What Makes Agile Hard In Practice https://www.youtube.com/watch?v=MFzDaBzBlL0 Can you do it if you know it? TYPICAL MISTAKES  Typical Mistakes One of the ways that the Agile approach can go wrong is with user engagement: Meaning going out and learning about your users and figuring out what's going to be valuable to them 4 Typical Mistakes: 1. The user tells us what to do and we just do it So we're user driven. But what happens is that you just don't know what they want, you bring them back the blue button they asked for Valuable outcome might not be achieved here The product design probably doesn't solve the problem that the users really had  Typical Mistakes 2. We’re smart Our last product was successful So we're just going to do whatever we think is best, and whatever else is the user’s fault 3. Hey, you do your thing, I'll do mine We're not going to worry about each other, and then we'll patch/merge/stick this stuff together at the end 4. Micromanagement Demotivates people No single project manager, no matter how skillful he/she is, can’t keep track of all the details and what the optimal decision is on an hour by hour basis So we need nice, elevated views of what a good outcome is going to be These typical mistakes will compromise the Agile process which is basically a “human centered” approach  Solutions to avoid mistakes The Agile approach Success comes from: ü Narrative Collaboration: allows us to keep our eye on what's valuable to the user and describe that in a way that's understandable for the whole team ü A culture of experimentation: We don’t always know how we're going to deliver what's valuable to the user, it's important to acknowledge that and develop a culture of experimentation. Which in turn enables structured learning ü Small batches: so that we don't go too far down the wrong road before we learn what we should have learned DIFFERENCES BETWEEN AGILE VS NON-AGILE APPROACHES What Makes Agile Hard In Practice THE MANIFESTO IN PRACTICE The Manifesto in Practice Individual Processes Interactions Tools Working Comprehensive Software Documentation Customer Contract Collaboration Negotiation Responding Following to Change a plan  The Manifesto in Practice Product Concept / Owner Engineering Design Head of / QA Projects Individual Processes Interactions Tools Sales & Scrum Customer Master Support You need to spend a lot of time going out and observing individual users and figuring out what's valuable so that you can bring that understanding into narrative collaboration with the rest of the team Managers have to make space for that  The Manifesto in Practice Product Concept / Owner Engineering Design Head of / QA Projects Working Comprehensive Software Documentation Sales & Scrum Customer Master Support With agile approaches, project teams spend more time on development and less time on documentation, resulting in a more efficient delivery of a working product Agile project teams produce fewer, more streamlined documents that take less time to maintain and provide better visibility into potential issues  The Manifesto in Practice Product Concept / Owner Engineering Design Head of / QA Projects Working Comprehensive Software Documentation Sales & Scrum Customer Master Support On a traditional project, if you’re 75 percent done, you don’t have any working software to give the customer — “75 percent done” traditionally means you’re 75 percent in progress and 0 percent done On an agile project, however, if you’re 75 percent done, you have working product features for 75 percent of your project requirements  The Manifesto in Practice Product Concept / Owner Engineering Design Head of / QA Projects Customer Contract Collaboration Negotiation Sales & Scrum Customer Master Support See next slide  The traditional approach involved 3 key touchpoints with customers: Project start: When the customer and the project manager — or another project team representative — negotiate contract details Any time scope changes during the project: When the customer and the project manager negotiate changes to the contract End of a project: When the project team delivers a completed product to the customer. If the product doesn’t meet customer expectations, the project manager and the customer negotiate additional changes to the contract  The traditional approach involved 3 key touchpoints with customers: This historical focus on negotiation discourages potentially valuable customer input/insights and can even create an adversarial relationship between customers and project teams Using an agile approach in practice, you experience a partnership between the customer and development team in which discovery, questioning, learning, and adjusting during the course of the project are routine, acceptable, and systematic  The Manifesto in Practice Product Concept / Owner Engineering Design Head of / QA Projects Responding Following to Change a plan Sales & Scrum Customer Master Support Agile projects accommodate change systematically The agile approaches to planning, working, and prioritization allow project teams to respond quickly to change The flexibility of agile approaches actually increases project stability  The Manifesto in Practice Product Concept / Owner Engineering Design Head of / QA Projects Responding Following to Change a plan Sales & Scrum Customer Master Support Responding to change doesn't mean: oh, I had a new idea so let's go do that What it means is instrumenting change into your processes and knowing what change, what direction you should be going in Responding to change, while having no plan at all is not what Agile is about BENEFITS FOR THE MANAGER AND FOR THE TEAM  The Manager & The Engineers Agile requires a change in culture, behavior and human change is usually difficult For the manager the toughest behavior is to trust the team and not telling the team exactly what to do and giving them the space to creatively solve that problem For the team/engineers: a lot higher autonomy, and ownership of the work, a lot more creativity For management you get a lot more flexibility in your planning, a lot more predictability, and higher quality of product  The Manager & The Engineers In a non-Agile context when deadlines have been missed you get a lot of CYA behaviors The Agile approach is supposed to shift that: all team members including managers have to take joint ownership and joint responsibility of the solution and that's a really big change And all those changes need first to be addressed to ensure an effective transition to Agile People have to be open to learn and to try new ways of working, they have to be prepared and ready to adhere  Impact on the traditional PM Iron triangle What Impact Agile has on the Project Management Iron Triangle of Cost, Time & Quality? This so-called triple constraint was once the standard by which project performance was routinely assessed. Today, a fourth criterion has been added to these three: Client acceptance The principle of client acceptance argues that projects are developed with customers or clients in mind, and their purpose is to satisfy customers’ needs. If client acceptance is a key variable, then we must also ask whether the completed project is acceptable to the customer for whom it was intended. Companies that strictly evaluate project success according to the original “triple constraint” may fail to apply the most important test of all: the client’s satisfaction with the completed project. Agile transformation @ ING https://www.youtube.com/watch?v=TaV-d7eKWFc KEY TO SUCCESS WITH AGILE  Keys to Success with Agile For the Agile process to be most effective, it requires the willingness of organizations to adapt their practices and operating philosophies in several ways. Among the keys to making Agile work are the following principles: Cross-functional teams: Agile is most powerful when it is recognized as a multidisciplinary team-based initiative Empowered team members: Because the focus is on developing business outcomes, our goal is to free team members to become problem solvers Shared accountability: Because the team is emphasized above individual contributions, it follows that no one should be held accountable for only their part of the project  Keys to Success with Agile Servant leadership: Leaders of the project should focus on finding ways to provide their team with the resources and opportunities to succeed, rather than adopting an invasive, micro-management style. The role of leadership is to serve the team, through providing a vision, resources, or critical support Total openness and transparency (hiding problems): Agile requires that the customer be, as far as possible, an equal member of the development team. Without openness, Agile is no better than the Waterfall technique. AGILE WEAKNESSES  Agile Weaknesses Active user involvement and close collaboration of the Scrum team are critical throughout the development cycle: very time-demanding of all parties involved, and requires users to commit to the process from start to finish Evolving requirements can lead to scope creep throughout development Because of emerging requirements and the flexibility to make changes midstream, it is harder to predict at the beginning of the project what the end product will actually look like  Agile Weaknesses Testing is integrated throughout the lifecycle, which adds to the cost of the project because the services of technical personnel such as testers are needed during the entire project, not just at the end. If it is misapplied to projects that operate under high predictability or a structured development process, the requirements of Agile for frequent user input can be an expensive approach whose benefits do not justify its cost  Sustaining the people and culture of a remote agile team  Covid19 Crisis impact on agile Assumptions: ü Agile teams traditionally excel when their members are co-located ü Agile teams, by definition, are well suited to periods of disruption, given their ability to adapt to fast-changing business priorities However the coronavirus has challenged the typical approach to managing agile teams  Covid19 Crisis impact on agile Traditionally, co-location enabled: ü Frequent in-person contact ü Instant communication ü In-person team events, meals and coffee chats ü Building trust quickly ü Simplifying problem solving ü Fast-paced decision making ü Tracking and developing the very spontaneous ideas and innovation that makes agile so powerful  Covid19 Crisis impact on agile Many of the kinds of activities that nurture morale for co-located agile teams are not possible in a virtual environment Circumstances of the health crisis led to: ü Teams working from their living rooms or their dining-room tables ü Often sharing home workspace with children or other family members also working remotely ü Working from home blurs the lines between professional and personal lives ü Stress about the appearance of the home workspace, interruptions from young children, or even family members sharing the same workspace ü Working with new digital tools and new practices ü Capturing spontaneous ideas and putting up blockers to avoid losing them  The experience of remote working can lead to ineffciency and reduced cohesion: the survey Experience of remote work, % of respondents: Source: Harvard Business Review; Workplace Trends; Zoltán Lippényi and Tanja van der Lippe, “Co-workers working from home and individual and team performance,” New Technology, Work and Employment, March 2020, Volume 35, Issue 1, pp. 60–79  Observations Teams already operating remotely before the crisis struggled less, given their ability to handle ambiguity without losing focus and to concentrate on outcomes over processes Sudden transition of co-located teams to a fully remote approach reduced cohesion and increased inefficiencies  Reacting to remote working Teams now should: ü Accept these limitations and interruptions graciously—and team members should feel free to set their own boundaries around scheduling and use of video ü Encourage one another to introduce their pets and family members ü Show any meaningful items in their working space ü Make a more conscious effort to be social, polite, precise, and tactful—to ensure everyone feels just as safe contributing remotely as they did in person  Cultivate bonding and morale Best practices: ü At one bank in the US, one agile team established virtual happy hours. Squad members join a videoconference call for a half-hour every week, sharing the beverage of their choice and talking about whatever comes up— other than work ü A designated team member (appointed by the scrum master) sets up each poll with trivia questions to test team members’ knowledge of one another. The whole activity takes about 10 min These activities might sound silly, but they’re also fun—and a useful way of supporting morale and shaping a shared experience virtually  Cultivate bonding and morale Best practices: Assume positive intent in electronic messaging ü Electronic communications can easily be misunderstood/misinterpreted ü An agile team at one retail company has an explicit agreement that team members will always assume that the contributions of others are made with positive intent ü Team members might flag inappropriate comments that can be brought up directly with the sender or with the scrum master to resolve it ü If needed, a small group could stay on the line after a standup meeting to discuss  Cultivate bonding and morale Best practices: psychological safe of team members ü Conducting an anonymous biweekly survey to solicit input ü Tribe leaders and scrum masters use the survey to take the team’s pulse: Ø on whether they’re feeling overworked Ø how motivated they are Ø how many things they are being pulled into each day Ø whether and how processes are working Ø what professional-development concerns they might have ü Scrum masters and tribe leaders then agree on a benchmark goal and identify a list of two or three tangible actions to take over the coming weeks to improve— which might include visible team-wide actions or more personal one-on-one conversations  Company level / division objectives Best practices: “Objectives review meetings” ü Keeping teams aligned with organizational objectives can be even more challenging ü Working remotely requires more purposeful and structured communication: Ø Agile teams at one company adopted biweekly division-wide meetings to identify and agree on objectives for the following weeks  Adapt coaching and development Best practices: Adapt coaching and development ü Agile teams should aspire to model remotely everything they would have done in person Ø If you would do one-on-one coaching over coffee, try doing it remotely— while actually having coffee over video Ø Encourage all team members to turn on their video and actively monitor body language during group meetings  Keep teams engaged during long online events Best practices: ü At one US financial institution, for example, a scrum master realized that staring at a video screen for more than 2 hours was draining ( as no dynamic interaction of an in-person workshop) ü Her solution? ü For longer meetings, she began to schedule in a 10-15 min exercise break every 90 minutes—with a shared videoconference tool to recommend different exercises KEY TERMS IN AGILE PM  Key terms in agile PM Sprint – one iteration of the Agile planning and executing cycle Scrum – the development strategy agreed to by all key members of the project Time-box – the length of any particular sprint, fixed in advance, during the Scrum meeting User stories – short explanation of the end user that captures what they do or what they need from the project under development Scrum Master – person on the project team responsible for moving the project forward between iterations, removing impediments, or resolving differences of opinions between major stakeholders Key terms in agile PM Sprint backlog – the set of product backlog items selected for the Sprint, plus a plan for delivering the Sprint Goal Burndown chart – remaining work in the Sprint backlog Product owner – person representing the stakeholders and serving as the “voice of the customer.” Development team – organizational unit responsible for delivering the product at the end of the iteration (Sprint) Product backlog – a prioritized list of everything that might be needed in completed product and source of requirements for any changes Work backlog – evolving, prioritized queue of business and technical functionality that needs to be developed into a system