Facilitation Foundations - A Guide to Effective Agile Meetings

Editor's Notes

• #2: \n
• #3: \n
• #4: \n
• #5: \n
• #6: If you find that you are beat up at meetings, you are in the right place. The fact is many Agile teams struggle with why meetings are needed or if they indeed provide value. I am here today to tell you that MOST Agile meetings provide little or no value to the team or key stakeholders because of the manner in which they are approached and conducted. This session will help you identify why the meetings are important and what we can do to make them most effective. \n
• #7: Principles behind the Agile Manifesto\nWe follow these principles: \n\nOur highest priority is to satisfy the customer through early and continuous delivery of valuable software. \nWelcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. \nDeliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. \nBusiness people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. \nThe most efficient and effective method of conveying information to and within a development team is face-to-face conversation. \nWorking software is the primary measure of progress. \nAgile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. \nContinuous attention to technical excellence and good design enhances agility. \nSimplicity--the art of maximizing the amount of work not done--is essential. \nThe best architectures, requirements, and designs emerge from self-organizing teams. \nAt regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. \n
• #8: \n
• #9: \n
• #10: Nobody likes to be asked to do something because ‘the book’ says we should do it. In fact, this is the ultimate turnoff! Teams need to be motivated to know the why behind the what and have some idea of the value add that the meeting provides. \n
• #11: Forming:\n\nIn the first stages of team building, the forming of the team takes place. The team meets and learns about the opportunity and challenges, and then agrees on goals and begins to tackle the tasks. Team members tend to behave quite independently. They may be motivated but are usually relatively uninformed of the issues and objectives of the team. Team members are usually on their best behavior but very focused on themselves. Mature team members begin to model appropriate behavior even at this early phase. Sharing the knowledge of the concept of "Teams - Forming, Storming, Norming, Performing" is extremely helpful to the team.\nSupervisors of the team tend to need to be directive during this phase.\nThe forming stage of any team is important because in this stage the members of the team get to know one another and make new friends. This is also a good opportunity to see how each member of the team works as an individual and how they respond to pressure.\n\nStorming: \n\nEvery group will then enter the storming stage in which different ideas compete for consideration. The team addresses issues such as what problems they are really supposed to solve, how they will function independently and together and what leadership model they will accept. Team members open up to each other and confront each other's ideas and perspectives. In some cases storming can be resolved quickly. In others, the team never leaves this stage. The maturity of some team members usually determines whether the team will ever move out of this stage. Some team members will focus on minutiae to evade real issues.\n\nThe storming stage is necessary to the growth of the team. It can be contentious, unpleasant and even painful to members of the team who are averse to conflict. Tolerance of each team member and their differences needs to be emphasized. Without tolerance and patience the team will fail. This phase can become destructive to the team and will lower motivation if allowed to get out of control.\nSupervisors of the team during this phase may be more accessible but tend to still need to be directive in their guidance of decision-making and professional behavior. The groups will therefore resolve their differences and group members will be able to participate with one another more comfortably and they won't feel that they are being judged in any way and will therefore share their own opinions and views.\n
• #12: Norming: \n\nAt some point, the team may enter the norming stage. Team members adjust their behavior to each other as they develop work habits that make teamwork seem more natural and fluid. Team members often work through this stage by agreeing on rules, values, professional behavior, shared methods, working tools and even taboos. During this phase, team members begin to trust each other. Motivation increases as the team gets more acquainted with the project.\nTeams in this phase may lose their creativity if the norming behaviors become too strong and begin to stifle healthy dissent and the team begins to exhibit groupthink.\n\nSupervisors of the team during this phase tend to be participative more than in the earlier stages. The team members can be expected to take more responsibility for making decisions and for their professional behavior.\n\nPerforming: \n\nSome teams will reach the performing stage. These high-performing teams are able to function as a unit as they find ways to get the job done smoothly and effectively without inappropriate conflict or the need for external supervision. Team members have become interdependent. By this time they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decision-making process without supervision. Dissent is expected and allowed as long as it is channeled through means acceptable to the team.\n\nSupervisors of the team during this phase are almost always participative. The team will make most of the necessary decisions. Even the most high-performing teams will revert to earlier stages in certain circumstances. Many long-standing teams will go through these cycles many times as they react to changing circumstances. For example, a change in leadership may cause the team to revert to storming as the new people challenge the existing norms and dynamics of the team.\n
• #13: The meeting facilitation toolkit should include: \n \n Whiteboard & Markers\n Pens\n Index Cards\n Sticky Notes\n Agile Planning Poker Cards\n Toy or Widget to be held by the only person speaking\n Timer or Stopwatch\n List of Meeting Rules which should be posted\n Team Defined definition of Done (which also should be posted)\n Painters or masking tape\n Bell or Chime to alert when time is up on a topic\n
• #14: All agile meetings should follow a set of rules or guidelines used to facilitate and keep the meeting on topic and on time. Below you will find a helpful list of items that will help you be prepared for a meeting and moderate it in an agile fashion. \nBe Prepared: \nEvery agile meeting should have a purpose and goal\nPrior to holding a meeting, make certain all of the key participants are invited\nThe agenda for the meeting should be well defined and published at least 24 hours in advance\nThe meeting goal and agenda should be sent to each attendee prior to the meeting\nAll resources should be reserved and prepared for the meeting\n\n Do you have the room scheduled? \n Do you have a projector in the room selected? \n Will you have at least one participant with a laptop to project the backlog and record issues, actions, and assumptions? \n Is your meeting facilitation toolkit ready? \n
• #15: Only one person should speak at a time during the core focus of the meeting unless time is set aside for group collaboration on a specific topic. \nMeetings should follow a specific time-boxed flow. Below I will provide a sample standard meeting workflow:\nThe meeting goal and objective should be presented\nThe time-boxed agenda should be presented\nThe rules should be posted and all should be reminded to take heed\nIf at any time a discussion begins that is not part of the agenda, the topic should be added to a running list for later discussion\nIf the meeting ends and the goal has not been reached, arrange for a subsequent meeting at a later time (do not go over time in hopes of solving an issue)\nOnce conclusive results have been reached, record all risks, assumptions, and action items \nInsure that all list items have a party responsible to address each topic outside of this meeting\nPost the results in a visible place for all to see\nTake the time to allow the team to formulate meeting rules and make certain all meeting participants are clear on what the rules consist of and who is responsible for enforcement. Remember, if it is not written, it is not a rule. \n
• #16: \n
• #17: \n
• #18: \n
• #19: \n
• #20: \n
• #21: \n
• #22: \n
• #23: \n
• #24: \n
• #25: \n
• #26: \n
• #27: \n
• #28: \n
• #29: \n
• #30: \n
• #31: \n
• #32: \n
• #33: \n
• #34: \n
• #35: \n
• #36: Are you looking at me? This is where the real finger pointing begins. The fact is we need to assess the level of management oversight vs. the level of helpful management. This follows the Servant-Leader Principle. It is far easier for managers in these roles to stick to removing impediments and steering clear of the everyday nature of the work the team does. \n\nLikewise, a good Product Owner / Manager can learn to stay focused on the customers needs and the direction the product takes to get there. The Project Manager should be focused on the success of the team and should really work to gain the team’s trust. This role should serve more as a consultant and mentor. The greatest fall any manager level position could take is to dive too deeply into roles outside of their own. \n\nThe fact is effective managers manage from the outside in. Worry about the bare minimum that you need to in order to insure the project’s success. Focus on removing impediments and providing the team the tools they need to be successful. In return you will receive the greatest level of visibility into the project. \n
• #37: \n
• #38: \n
• #39: There are at least 12 unique innovation games (and any number of new games derived by combining elements of these 12 games).\n20/20 Vision: Several potential product features appear on a shuffled set of note cards, one feature per card. The facilitator tapes the first card face-out onto the wall and displays each of the remaining cards one at a time to the participants, asking if the feature on the card is more or less important than the feature on the wall. No two features are allowed to be of equal importance. \nBuy a Feature: Participants see a list of proposed product features and a cost (expressed as development effort or street-level pricing) associated with each. Each participant “buys” a desirable feature; participants may also pool resources to buy features too expensive to be purchased with individual funds. \nGive Them a Hot Tub: Several potential product features appear on a shuffled set of note cards, one feature per card. Some of the proposed features are completely outrageous, such as a “crush rocks” setting for a new food blender. Observers note what happens when a customer uncovers one of these outrageous features. \nMe and My Shadow: Observers carefully record a participant using a product or service. Observers sit next to the participant to watch for and listen to actions, expressions, comments, and suggestions. Observers ask questions of the participant, such as “Why are you doing that,” or “what are you thinking at this moment”. \nProduct Box: Participants imagine that they’re selling a vendor’s product at a tradeshow, retail outlet, or public market. Participants use plain cardboard boxes, glue, paint, crayons, and other scraps and knickknacks to design a product box that they would buy. \nPrune the Product Tree: A very large tree (representing a system or product) is drawn on a whiteboard. Thick limbs represent major areas of functionality within the system. The edge of the tree—its outermost branches—represent the features available in the current release of the product. Participants write new features on several index cards that are shaped like leaves, and then they place these feature-leaves onto the tree, revealing which branches (product features) are important to customers for future improvements. \nRemember the Future: Participants imagine a time in the future when they will have been using the product almost continuously between now and then. (“Future” may be expressed in months, years, or some other time frame.) Participants then write down exactly what the product will have done to make them happy, successful, rich, safe, secure, etc. \nShow and Tell: Participants bring in examples of artifacts created or modified by the product or service. Participants explain why these artifacts are important, and how and when they are used. \nSpeed Boat: A drawing of a boat appears on a white board or sheet of butcher paper. Anchors “attached” to the boat prevent it from moving quickly through the water. The boat represents a product or system, and the anchors are features that the participants don’t like. The lower the anchor, the more debilitating the feature. \nSpider Web: A product name appears at the center of a circle drawn in the middle of a whiteboard. Participants draw other products and services, explaining how, when, and why they are used. Participants then draw lines that link these additional services to each other and to the product’s circle. \nStart Your Day: Participants describe their daily, weekly, monthly, and yearly events related to their use of a product. Descriptions are written on pre-printed, poster-sized calendars or timelines taped to the walls. Participants include events with time frames that match the product’s expected lifecycle or release cycle. Participants may also include one-time events (particularly horrible days where everything goes wrong) and describe how the product helps or hinders as the event unfolds. \nThe Apprentice: An engineer or product developer uses the product as an end-user. For example, if the system is used for data entry, the developer enters data for a couple of days. Observers record the engineer’s actions, expressions, comments, and suggestions. \n
• #40: \n
• #41: Please send me your feedback and or thoughts. \n