Agile Team Coaching

1. Course Overview: Hi everyone. My name is Will Jeffrey and welcome to my course. I had been a certified agile coach and professional Agile trainer for multi-discipline teams. I've been teaching them for more than 15 years how to work smarter together. My workshops, Dr. ground up collaboration for much better and more integrated results. I am happy to help you improve and do what you love. This course, provide agile approaches and agile leaders with the necessary knowledge, skills, and attitudes they must have in coaching their teams. This course focuses on how to coach Agile teams. By the end of this course, you will be able to explain what his team development and to set up the team environment codes. The team journey toward high performance. Helped individuals and teams deal with change, teach Agile practices at the team level. Adl, organizational impediments and surface and work with team conflict, resistance and dysfunction. This course will give you the tools and structures you need to become an effective Agile coach. As a team coach, you'll catalyze change, not only in others and organizations, but in yourself too. 2. Introduction for Team Coaching : A coach is a person hired by a team, It's owners or its managers to help the team get what they want. As defined by the International Coaching Federation. Coaching is partnering with clients and a thought-provoking and creative process that inspires them to maximize their personal and professional potential. Team coaching combines individual coaching and consulting with inspiration from sports training. High-functioning sports teams respond to stressful moments instantly because they practice their responses and execute as a team. The dynamics of organizational and business teams parallel those of sports teams in that the right people need to be in the right jobs at the right time. Coaching teams is far more complex than coaching individuals. You've probably already have guessed that when coaching a whole team, you need to focus on more than one person. You need to be aware of the perspectives and intentions of several people. And you need to master both steering the conversation towards a goal, letting each of them have airtime and help the team finding consensus. Tough job, isn't it? Well, don't panic, even though the going gets tough. In this class, I will introduce you to some tools and techniques that you can use in team coaching. 3. Team Development and Performance Models: Forming and performance does not happen by itself. You cannot form a team by placing five to nine persons in a room and shouting, self-organize. As you close the door, give it a moderately healthy environment and time to work together. A group of people will generally start collaborating to achieve better performance. This can take a long time, however, and not all groups we'll get there in the end. There might be incompatible personalities or people who simply do not get along. A skilled coach can guide groups pass the worst pitfalls and help them build a well-performing team much faster than they could do it on their own. In the one hundred, nine hundred and sixties, Bruce Tuckman introduced a model for understanding the development of teams. The model is interesting for Agile coaches because if we can identify the stage of the team, then we can determine what interactions with the team would be appropriate. The model in its original form consists of four stages. Forming group members are generally attentive and well-behaved, but self-focused. The group of people is looking for answers on questions like, who is in the team? What are we expected to do? How shall we do it? Who are we reporting to? Here? The Agile coach should help the team members to get to know each other and clarify the basic terms, objectives, vision, and values. Assuming that these remains stable, that teams should move into storming on their own. Storming, the group members are starting to form opinions about each other. They're trying to establish a common understanding of the goals, roles, and procedures, but have challenges coordinating and resolving difficulties. Here the Agile coach should work on diversity, descent and conflict resolution slashed dissolution. In other words, is okay to have differing opinions. But people need to learn how to constructively build on top of the contributions of others. Team-building exercises can be very useful at this stage to help the team see what kind of people the others are. Norming. Members are starting to understand and accept the different working habits and the team. The team starts establishing a common understanding roles and procedures through self-assessment and agreements, the community will be established and each individual will begin to accommodate herself. Here the Agile coach should encourage the development of the team specific common understandings, roles, routines, et cetera. Help the team create working agreements, cutting guidelines and pull policies, update the definition of done and streamline the task board. Help the team build their identity, pick a team name, encouraged some fun and silliness, retains souvenirs. Let them rearrange their corner of the office, helped them set up their own information radiators, et cetera. Performing a team in this stage can primarily concentrate on getting the job done. Rather than thinking about procedures, cooperation, and organizing. The cooperation is working well and there is less talk about process and self-assessment. Here the Scrum Master or Agile coach should help encourage work performance through a focus on excellence, further potentials, new goals and targets, etc. Note that this stage is very wide and doesn't account for the presence or lack of synergy. It covers all working groups and teams that have established their roles and procedures and are now focusing mainly on the actual work. The performance can be low or high or anything in between. Teams do not necessarily progress linearly through the model. Tuckman noted that many teams skip the storming stage altogether going directly from forming to norming. Other teams can get stuck in storming or norming. And whenever the team setup changes, members leave or join, or the context changes, the team relocates or is transferred to another department, that team becomes a little less mature. It can, for example, dropped from performing back to norming or even all the way to forming. The Agile coach should change your interactions to reflect this new situation. Research of team performance conducted by john Katzenbach and Douglas Smith and describe in their iconic book, The Wisdom of teams, shows how the performance of a team is impacted when a group of people develops from being a working group to a high-performance team. Katzenbach and Smith described the following stages. Working Group. A working group is merely a group of people for which group performance is primarily dependent on individual contributions. The working group is the sum of its parts but nothing more. And there was little potential for improvement. Members do not take responsibility for results other than their own, nor do they try to develop incremental performance contributions requiring the combined real work of two or more group members. In other words, there is no synergy in the working group. Sudo team. This is a working group for which there could be a significant incremental performance need, or opportunity. But the group either does not recognize this potential or is not interested or capable of working towards it. But typical pseudo team is not focused on collected performance and who's not trying to achieve it. It can be very discouraging to be part of a pseudo team where the members are not interested in Jelly. This can sometimes lead to a vicious cycle of mediocrity and stress. An ongoing state of low productivity. When coaching a working group or a pseudo team, you should focus on fostering a team identity, help them create a common goal and also introduce opportunistic collaboration where it makes sense. Show them that collaboration can be fun and profitable individually, as well as collectively. Also help them visualize their work and understand what is happening. Potential team. This is a group with a significant incremental performance need that is interested in improving its performance and is actively working to achieve this. Typically, the group would need more clarity about purpose, goals or work products and more discipline and hammering out a common working approach. It has not yet established collective accountability. When coaching a potential team, show them how easy it is to try out new techniques and working methods. Focus on improving the retrospectives and ensure that the team is in control if it's working agreements, tools and processes ensure that they have simple but good metrics with both leading and lagging indicators so that they know when they are improving. Real team. This is a small number of people with complimentary skills who are really committed to a common purpose, goals and working approach for which they hold themselves mutually accountable. As a coach, you can help them become a high-performing team. A team needs to set up personal professional development plans together. They will also need to know how to give and take feedback. High performing team. This is a group that meets all the conditions of a real team. In addition, the members are deeply committed to one another's personal growth and success. And new members will also join this commitment. The high performing teams significantly outperforms all other similar teams and also outperforms all reasonable expectations given its membership. In the Performing phase, the team has reached synergy and are getting a lot more out of their individual contributions. The Tuckman and Katzenbach Smith models look very similar, and I chose to draw them as parallel tracks. This is not always the case. One could argue that the Katzenbach Smith model continues where the Tuckman model stops with a bit of overlap. Forming or storming team, according to Tuckman, can at most be a potential team. And the Katzenbach Smith model. And what Tuchman considers a performing team may still be only a pseudo team according to Katzenbach Smith. Furthermore, the Tuckman model is team and turtle only. And team formation can be strengthened regardless of the organization. Assuming of course that the budding team is not torn apart all the time. Improvements along the Katzenbach Smith model are, however, strongly dependent on the surrounding organization and require understanding and support from the Scrum master, product owner, manager and stakeholders. For example, if a line manager keeps using new words but acts like always before, the team will notice this. Becoming a real team requires that each member is willing to take risks and trust the others, where they previously had individual actions and separate work products. They will now have collective actions and joint worked products. They need to agree on a common purpose, set goals, decide on the approach, and take mutual accountability. There will be conflicts that need to be handled in constructive ways. People who call themselves teams but take no such risks are at best, pseudo teams. 4. Creating Team Synergy: Working in a close Agile team is exciting, but cohesive teams don't just spring up in an instant. They take time to gel. When a team doesn't pull together, people get frustrated. The software they produce will reflect this. According to Professor Richard Hackman, real teams have clear boundaries, are interdependent for some common purpose, and have at least some stability of membership, which gives members time and opportunity to learn how to work together well. The difference between a team and a working group is synergy. Individuals can achieve synergy for the obvious reasons. Groups don't have synergy by definition, only when a group has worked together towards a shared goal for long enough to gel together, can we call them a high performing team? But what is this telling? How do you recognize it and how do you make it happen? Team members contribute to the goals by acting according to their own interpretations of the situation and recent events. Obviously, if team members have different understandings of the situation and the goal, no synergy as possible. But if their interpretations are aligned so that they support and supplement each other, then the contributing actions will also converge and give synergistic effects. The whole collective activity system of habits, actions, signals, and reactions becomes greater than the sum of its parts. You can help a team gel by establishing the conditions for teamwork to happen. Start by making time for them to get to know each other. Improve the workspace. So the team has an environment that supports working together. Look for ways that you can help the team build a shared sense of where the project is headed. 5. Helping a Team Jell: An effective team seems to run like a well-oiled machine. Watch carefully and you'll see they're not just following routines. When they hit problems. They adapt a way to work. When something needs doing, someone steps up to do IT. Teams take time to gel. It takes time to get to know everyone and to build trust. By working together. The team will start to understand one another's perspective and problems. Meetings for especially the daily stand up and retrospectives provide an opportunity to learn about each other. Create opportunities for people to get to know each other better. You could try sharing personal histories or a range of team outing, such as a meal or bowling. When the team relaxes together, some of these stories come out in conversation. This helps create social glue that binds the team together. Team collaboration requires trust. George didn't, when he writes, trust builds on reasonable self-disclosure. You don't have to tell everything about yourself, but you can't be secretive either. You can lead the team and building trust by showing that it's safe to be open, be transparent about your motives and disclose information about your experience, your opinions, and your feelings during this invites openness from others. Admit when you make a mistake, ask for help regularly. But trust cannot take root when people don't feel safe. If there is a blame culture or people are criticized for mistakes, they won't feel safe. Team members need to be comfortable to admit when they need help. When the team feels safe, they will be happy to share advice and help each other. In overcoming The Five Dysfunctions of a Team. Patrick Lencioni's recommends you help a team get comfortable with openness by taking the time to share personal histories. He suggests running an exercise where each member of the team tells a story about a challenge that they faced in the past. This could be a story from their childhood, school or first job, starting with some basic information such as where they're from and how many brothers and sisters they had. As each team member tells their story, they have an opportunity to practice being open with their teammates as the people on the team here, the stories, they get a better insight into each storyteller and knowing something personal about them helps create empathy. Lunch she only stresses the purpose of the exercise should be made clear to the team from the outset. You also need to take care that everyone understands they are not being asked to reveal anything they feel uncomfortable sharing. If a person on the team seems unhappy with another team member, invite them for coffee and discuss it. What assumptions has she made that has caused her to think that way about her team member? What alternative explanations are there? Building trust between different roles, such as developers, testers, analysts, technical authors also takes time. You can help the team bridge the gap between different disciplines by suggesting they take on another role for a short period. For example, a developer could take on a testing role for a week. If they do not have the required skills to do the other role. That can pair with someone and contribute as much as they can. Walking a mile in their moccasins will help them get a better understanding of the work. People may not understand what their teammates do and assume their own role is harder. But without mutual respect, the team will not flourish. You can demonstrate respect for everyone on the team by asking for opinions and help and by taking their concerns and problems seriously. Others will notice this and imitate you. A team needs a shared workspace to keep communication flowing. The ideal is for the whole team and no one else to sit together in the same room. A breakout area near the team where they couldn't get a cup of coffee and chat allows the team to relax and build friendships. A meeting room nearby is useful for privacy over having discussions without interrupting the team. However, some people may be reluctant to move desks or sit together because an open plan workspace can feel exposed and impersonal. Encourage the team to design their own workspace and customize it to suit them. It's amazing how a few plants, books, and pictures can make a space feel safer to work in. Sometimes when companies adopt agile, it takes them a long time to realize that this is not just about how developers work. It requires change across the whole organization. Consequently, you may find a lot of resistance to the idea that a tester should sit next to a developer who is in turn sitting next to a product manager. Campaigned tirelessly for this. Because it is hard to build an agile team when people are segregated. Once everyone is sitting together, it can get started on building an informative workspace. Were useful information is displayed to help people structure their time and make good decisions. It's not just the physical workspace that you need to pay attention to. The virtual environment, needs to support collaboration, to arrange of session with the team to work out where they want to keep electronic information. Encourage them to set up a Wiki or shared repository for documents rather than relying on shared network drives. They also need to be clear about the consistent setup of development and testing environments. 6. Balancing Responsibilities: The relationship between customers and developers is crucial because they need to work together to create the best product. Everyone needs to feel like they are part of the same team. Working toward the same goal. Make role responsibilities clear to the whole team. The customer is the person who owns the business case and prioritizes what the software should do. In Scrum, he or she is called the product owner. The development team takes responsibility for deciding how to build it and communicating to the customer how long that takes. The customer can set the dates that they require software to be delivered. But they don't nail down scope that's worked out with a team. Often the customer is a product manager who works with multiple users and stakeholders to decide what the software should do. On large developments, the customer role can be too big for one person. So a customer team is formed. This team needs to contain all the necessary expertise to work out the user stories and prioritize them. Your customer team might include business analysts, user representatives, and interaction designers. The exact mix depends on the project and the organization. Sometimes the best solution is a near customer who helps work out the details of the requirements with a team. At a far customer who makes the decisions about business priorities. The near customer could be played by a business analyst who sits with the team. While the far customer as a product manager who sits closer to the business operations and marketing teams. If the roles get out of balance, one side or the other will be overworked. If the customer is overworked and developers don't get enough of their time and are left to guess at what they want. If there are not enough developers where they are working slower than expected, the business will be disappointed with their output. You can help us ACOTE by making the side effects of the imbalance more visible. So management can consider addressing this problem. 7. Energizing the Team: Great teams are self-motivated. Sometimes though we find a team gets stuck. There, not sure how to get started. There may be big opportunities, but they can't see the wood for the trees and are overwhelmed. The following are some ideas about how to energize the team and help them find their own motivation. The secret degrade teams is they need reachable but challenging goals. Everyone needs to be sufficiently challenged, neither bored nor anxious. This is the optimum zone where people enjoy it the most. If work is too easy, developers will get bored and demotivated. They won't be proud of achieving something easy. If there is a lot of easy work to be done, encouraged them to find ways to automate it. Sometimes the work seems to be impossible and far beyond their comfort zone. This can paralyze the team. They need to break down the work into manageable chunks. Can they find something that they can get started on? If more investigation is needed before they can figure out what to do next. Encouraged them to experiment and try their ideas. Foster a culture where it's okay to experiment, to learn more about a problem that the team is trying to solve. As Thomas Edison famously said, I have not failed. I've just found 10 thousand ways that won't work. If the team doesn't have enough information to choose between two or three ways of doing things. They could try them all out. After each experiment, the team will know more. Although developing more than one solution may feel like a waste of time, it can be a quick way to learn and a cheap way to mitigate the risk of making the wrong decision. Knowing they're producing a useful product should help the team engage. Although as a coach, you can't set the product direction, you can help the team understand the big picture and the team mission. If you can arrange for the team to meet end-users, user needs will be more vivid to the team and give them ideas of how they can help make a better product. You can also help paint the picture of the opportunities within the project and how it might connect with their personal goals. Agile team's plan and design their own work. Be clear how much latitude and autonomy they have over how the software is designed, built, and tested. The ownership model helps to facilitate this discussion, making it clear whether intervention is necessary or whether to let go is the better option. But too bad zones and read occur when freedom and maturity are not imbalanced. Too much freedom leads to chaos. While too little freedom makes the team captive. Once they understand that they don't need to wait for permission, it can free them to make a start. Having frequent discussions with the teams on how the context and environment fields and whether they take ownership is a good way to nurture a safe environment. I've met developers on Agile projects who were burned out by working on a continuous stream of users stories. If they don't get time to explore new technology or experiment with innovative product ideas. Teams become de-motivated time and iteration plans for them to explore new ideas. This can do wonders for motivation and for the product. When team members get time to experiment with new ideas, clean up things that bug them, or learn something new, and they become happier at work. This improves the energy of the team and rubs off on project tasks to help the team find their own mini-projects within each project by listening to them and encouraging them to follow up on their ideas. According to the Agile Alliance, there are six learning areas that an employee could follow, such as individual, inter-team, inter-team, organizational, global, fearless learning. Learning should be integrated into the team workflow. The product owner provides the learning visibility on the sprint backlog, creating dedicated items and allocating time for it during every sprint. For example, four hours for a sprint of two weeks. The beauty of the agile learning processes that everyone is free to establish the learning topic that keys results and the learning cadence according to his slasher interests to bring more value to the project. Find ways to celebrate the success of every release. Having a team lunch or drink celebrates success and increases team bonding. Health team find ways to demonstrate their success to other teams and the wider organization. They could invite people to their iteration demo, show the product that accompany meeting, or send out an announcement. The team will get a boost when other people notice they are successful and appreciate them. A word of thanks from management or customers is important. Consider prompting them to do this. Getting feedback from users, especially if their lives have now been improved. His motivating, one company displayed emails from happy customers and unhappy customers prominently on the wall by the coffee machine. People start off motivated. If nothing demotivates them, there's a good chance they'll stay motivated. What makes people happy and motivated at work is what they do. What makes people unhappy and demotivated at work is the situation in which they do it. Situational problems include stress and the company culture and the motivation to work. Frederick Herzberg explains hygiene factors. These are factors that demotivate people if they are not present. Even though these factors aren't motivators when they are present. For instance, fast computers, decent coffee, and fair pay won't be noticed if they are there. But they're absence can be motivated employees. Although some of these hygiene factors may be things outside your influence as a coach, it's worth talking to the team about what annoys them. You may find some things that can easily be fixed, such as improving their work environment. Be careful about using incentives to motivate people. As Alfie Kohn explains and punished by rewards, incentive schemes aimed at encouraging individual productivity, damaged collaboration within the team, because helping out a teammate doesn't make sense if developers are competing for a bonus. If the team is being offered a bonus for doing their job, they will often do only what is needed to achieve the reward, no more and no less. If management must have a bonus scheme, then ask them to base it on achieving a team or company goal, not an individual one. The team will work better when they're motivated by the satisfaction of doing a good job and producing a great product. 8. Introducing High-performance Culture: A high-performance culture is often described as a collective mentality where there is a strong community spirit and collaboration around a shared sense of purpose. This interdependent culture where people are able to grow and fulfill their potential, is the most highly evolved as seen on the performance curve. The performance curve is a model that shows how to measure culture and where that relates to low, medium or high performance. My performance curve can be used to assess the level of performance by mapping a culture onto a four-stage model. Sharing the performance curve, we create a clear understanding of how coaching creates a high-performance culture and thereby revolutionizes the traditional approach to organizational culture. This is the new frontier for coaching and leadership development. The performance curve focuses on the collective prevailing mindset of an organization's culture and how this creates the conditions for performance. It provides a useful tool for organizations and individual leaders to gain an immediate idea of where they are operating. Either from the perspective of this is the culture of my organization or this does the culture I create as a leader. Different parts of an organization can operate on different parts of the curve at the same time. You can use this awareness to see what needs to change in order to improve performance. Each incremental shift in mindset toward interdependence leads to improved performance. Each stage on the performance curve follows the process of individual psychological development. It starts with a reactive, short-term, whatever happens, happens way of being. At the impulsive stage, there is a minimal awareness of culture, impact, performance and responsibility. The organization reacts to situations as they arise and it can feel unpredictable. There's little communication, engagement or development. There can be a survival mentality and progresses to a dependent state of following the rules typified by command and control behaviors such as judgment and blame. At dependent stage, there's a low medium awareness and responsibility. The organization is focused on maintaining stability and following the rules. Individuals focus on process and task completion with little opportunity for autonomy. Strong sense of group identity. People feel the need to fit in. There are strong one-way communication and varying levels of recognition. There is low engagement and trust which creates a risk averse mentality. Next is the independent stage which can be high performing the carries the risk that it is two individualist. At this stage, there is a medium, high awareness, high responsibility for our own performance. The organization supports innovation and individual development. People believed that can make a difference with their own actions. Individuals may focus on achieving own goals above those of the team or organization. Work-life balance may be hard to reach due to the high level of internal competition. Two-way communication and engagement is more likely. There's an achievement mentality. The ultimate stage is interdependence of collective mentality supported by emotionally intelligent leaders. At this stage, there is a high awareness and responsibility for self and others. There is a strong coaching culture. Teams feel a strong sense of ownership for high performance and believe this can only be achieved by the group. People engage with others to understand diverse viewpoints and display high levels of trust, care, and collaboration. There is continual authentic communication and feedback. This creates a collective potential mentality. There are challenges to changing an organization's culture, even if there is a clear view and agreement of the benefits of a more mature and evolved state. It can push people out of their comfort zone, especially as empowering their people and giving them ownership can feel like losing power for leaders. However, they soon find they get this back in multiple from a team that is empowered and responsible and operating at a more agile way that is responsive to customers. 9. Coaching for Team Performance: It could be said that it is even more difficult today to get the best out of a team for the following reasons. Global mobility brings diversity to Teams which greater flexibility of mindset. People no longer work in settled groupings but are continually forming and reforming teams. Teams can be project-based, functional, matrix based, operational, virtual, self-organized. Some teams are spread across geographical boundaries, making contact more infrequent and more problematic or entirely virtual in nature. The timescales within which teams are expected to join, form and perform to meet a business challenge are shorter than ever before. The business challenges themselves have increased in complexity. Coaching has a very important role to play in helping people to work well together. It can help people to establish whether and when they need to be in a team coaching and also has a fundamental role in helping with team leadership. It is said that leaders only have two functions. First, to get the job done, second, to develop their people. All too often, leaders are too busy doing the first to get around to the second. Equally, the first second sometimes can seem conflicted. The urge to get the job done well has created the audit culture. We started believing that we can be in full control of our output via an individual, team or organizational output by quantifying and measuring everything. Yet development is always about potential, about the future, the vision, innovation, creativity, and growth. Stock with a tension between getting the job done and developing our people. Organizations tried to separate them by separating management and leadership. To quote Alma Harris. Leadership is about learning together and constructing meaning and knowledge collectively and collaboratively. It means generating ideas together, seeking to reflect upon and make sense of work in the light of shared beliefs and new information and creating actions that grow out of these new understandings. Management became about the operational, getting the job done, about the process and the President. Leadership, on the other hand, at its focus on development, vision, and the future. However, in today's fast and complex world, lines between management and leadership are blurred, especially when it comes to day-to-day business. A coaching approach allows for the tension between management and leadership to be embraced and leveraged. Coaching can support teams to navigate between a management culture and the pull toward playing safe and a leadership culture and the pull toward taking risks. It allows for an environment where learning, innovation and raising awareness, as well as action and accountability can be pursued simultaneously. 10. Project Performance: Coaching approach is always applicable when working with a team as it helps to tap into the collective intelligence. A place where a lot of team leaders find it easy to start using this approach is at the beginning of a new project, as well as during the review of a finished task. Having coaching conversations at those stages of a project cycle creates an environment where the team can think together, learn together, and tap into their resourcefulness. This in turn will lead to performance at much higher levels than if every team member merely got on with their part of the task after a short briefing about their role. Why might these conversations look like? Let's imagine that an Agile team is tackling a new project. Some key questions a coaching leader can have in mind are, how do I raise this team's awareness of their own resourcefulness in light of this particular project, the focus is on team as a whole, as opposed to on each member individually. How do I invite them to take ownership and responsibility for the project as a whole? Again, not just individually in their roles, but as a team. How can this team be a net that holds this project strongly at flexibly? Approaching the conversation through this collective lens. The coaching leader can then ask questions following the grow model. The grow model follows four distinct stages. The first stage is about goal setting for the session as well as the short and long-term. At the second stage, we perform a reality checking to explore the current situation. The third stage focuses on options and alternative strategies or courses of action. And at the last stage, we decide what is to be done when, by whom, and the well-to-do it. Back to our example. Here are some sample questions. The list is endless and it will be defined by the particular context goal. What is our goal? What is important about this goal, this project slash task or a success? What would the outcome look like? What would be different for a slash our customers slash our stake holders? If we work together and the best possible way, what would that look like? Reality. What strengths do we have as a team that can help us accomplish this task? What challenges might we encounter as a team, both external and internal, On a scale of one to ten, how ready are we to tackle this task? What helped do we need options? How can we get more prepared for the task? Brainstorm possible ways, even be our allies in accomplishing this task. Make a list. What can we do? Brainstorm actions. Well, what will we do as a team? Create team actions. What will we do individually? Individual actions and accountability. While for ease of use, these questions are listed in grow order. As with all coating, the process is rarely linear. 11. Facilitating Coaching Conversations: The process of facilitating a team coaching conversation can vary. The coach might ask questions and get the team members in pairs or trios to discuss their responses to goals and reality with each other and then report on their conclusions to the whole group. They might mix people with different functions for this process to stimulate new ideas. They might themselves participate in one of the pairs or trios. The resources and ideas of the whole team are employed to brainstorm the options. And an agreed action plan is reached and driven forward by the combined will of the group. Another instance where a coaching conversation can be implemented easily and naturally is in reviewing the teams past performance on a task. If the focus is on team learning than the conversation, we'll focus again on the team as an entity. What did we do well as a team? What team's strengths showed up while we carried out this project? What was difficult for us as a team? What did we learn? What will we do differently next time? Notice how this process simultaneously create self-directed feedback and feed forward loops. It is very thorough and brings out detail. It ensures clarity and understanding and it draws on all team members resources. The process also promotes ownership and commitment and build self-esteem and self-motivation. 12. Fostering a Coaching Culture in Teams: Each team, like each family or partnership is different. Each team has an ecosystem of its own and it has to discover its own way of being through curiosity, commitment, and creativity. What works for one team might not work for another. And the dynamics of the team require continuous attention, exploration, and care to get the best out of it. The list of options that follows has been compiled from suggestions by participants on team development workshops. Each of these options can be considered by the team using a coaching approach. That discussion may be facilitated by the Scrum Master or another agile leader. But what happens should be decided on by team members themselves. Agree a set of ground rules or operating principles acceptable to all team members and to which all have contributed. These ground rules should be subject to regular checking as to whether they are being adhered to and whether they need to be changed or updated. All parties should also agree the procedure of the agreements are overlooked or broken. Not as a punitive measure, but as a way for a member or the team to take responsibility to repair their relationships by consciously creating working agreements up front and redesigning them as often as necessary. The team will build stronger relationships, collaboration, and high-performance. Many of the suggestions that follow could be included as ground rules. Educate leaders and teams on the key communication skills and dynamics needed for a team to thrive. While each team is unique, there are some guiding principles and practices that can help improve communication as well as the Teams well-being and effectiveness. Making these practices transparent and educating people on how to use them will enable them to create the interactions and results they want. Team members also need to understand that while each of them has an impact on the well-being of the team, the dynamics of the team influenced their own well-being to. Moreover, even though each team member has an impact on the culture of the organization, the team has the power through its development to transform the organization as a whole. Discuss and agree a set of common goals for the team. This should be done within the team regardless of whether your organization has defined the team's goal at the outset, there is always room for modification and for deciding how the task should be carried out. Each team member should be invited to contribute, as well as to add any personal goals that might be embraced within the overall team goal. Hold group discussions on individual and collective meaning and purpose as perceived by group members. This is both broader and deeper than exploring goals. Meaning and purpose are what drive people and a lack of them leads to lethargy, depression, and poor health. Throwing more light or awareness on something so pervasive that we are barely conscious of. It will increase the purposefulness and the quality of life at work and at home. Set aside time on a regular basis, usually in conjunction with a scheduled task meeting for group process work. During this time, agreements are reviewed, appreciations and gripes are expressed, and personal sharing may be included so that openness and trust are built. After experiencing a few such meetings facilitated by the coach. A high-performing team will be able to do this work on its own. Learn a new skill together. Some teams have agreed to learn a new skill such as a language or to attend a work-related course together, or even to undertake training and coaching. This might be in healthy competition with other regional teams. For example, in the same organization. Canvas team members views about the desirability of arranging structured social time together. Some teams perform better if they strengthen relationships through shared experience of non-work activities. If a regular event is planned for the team, the preference of an individual not to attend because of prior commitments or to respect the need for more family time should be acknowledged. That team member, on the other hand, needs to be prepared for some feeling of separateness as a consequence of that choice. Develop a common interest outside work. Some teams have found that a group activities such as a sport or a common interests outside of work that is shared by all members can be an excellent bonding opportunity. I recall one team who adopted a child in a developing country and with a small monthly contribution each paid for her schooling. This team felt that she had contributed even more to their lives than they had to verse, put support systems in place to deal in confidence if requested with individual troubles or concerns as they arise. If process meetings cannot be held frequently for geographical or other reasons of buddy system might be instituted whereby each member of the team has another member as a buddy to whom they can talk with if necessary. This way, minor issues can be resolved properly and valuable process meeting time is not wasted. The decision to adopt one or more of these options must be made democratically, but it also must be specific and recorded. Remember that the basis of coaching to improve team performance is not imposing, but increasing individual and collective awareness and responsibility. As the performance curve shows, takes will and focus from a coaching leader and a good deal of emotional intelligence to create the conditions and foster the mindset and culture needed for teams to become and remain high performing. Team coaching provides the space where learning, adjusting and real-time developments are possible. 13. Coaching by Example: The only way of genuinely promoting a desired change is by modeling it first through attitude, since attitude will color all of our actions and then by interactions with others, agile leaders need to be clear about their own willingness to invest time and energy in developing their team with a view to fostering long-term quality relationships and performance. They need to create a culture where the whole team views relationships as something worth time and investment. If leaders only pay lip service to team building principals, they will get no more than they pay for. Dedication to a team process pays off. If agile leaders wish to establish openness and honesty in the team, then they need to be open and honest from the outset. If they want team members to trust them and each other, they must demonstrate trust and trustworthiness. However, the agile leader is not the only one creating this culture. And they need to involve the team in the conversation and co-create with them. The leader has that delicate yet powerful role of both initiating and facilitating, of leading but not imposing, of accepting what is while seeing clearly what can be and what is possible for the team. Dealing with uncertainty. Agile teams need to be responsive, creative, and innovative in order to perform. Most people experience change real or anticipated as a stressful factor and are challenged by the speed and scope of change. The brain does not like uncertainty and when operating in an environment, we cannot predict or control as much as we would like. We tend to operate in survival mode. The direct consequences of stress in the workplace is that we become less collaborative, less creative, and less efficient. A coach has a crucial role to play in reminding team members what is under their control and what strengths they possess to help the team succeed. 14. Lead by Example: Let's talk about how you can lead by example. Give the team a real life example by following Agile principles yourself. For instance. And important principle of agile is to work at a sustainable pace rather than getting burned out. The sixth agile principle reads, agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. So make sure you leave the office at a sensible time to demonstrate that you take this principle seriously. Have conversations face-to-face instead of sending e-mails to demonstrate how to communicate. The eighth principle reads, the most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Try making a list of the principles that you would like to demonstrate and how you will do so. Following your own advice is a powerful way to lead the team. When you're consistent with your own recommendations, people know they can rely on you. Take a moment now to think about ways you can show that you practice what you preach. 15. Keep Your Balance: It's natural for the team to react against changes. And as a coach, you're often the one who's introducing change. Sometimes you'll be introducing new Agile practices. Other times you'll be helping a team fine tune its process. Either way, you need to lead the team to make changes. It's not as simple as telling people what they need to do. People need to understand what's driving a change before they'll throw energy into it. So, how can you open their eyes to new possibilities? Starts slow. Give them some time to think about change before pressing them into action. Look for opportunities for them to learn about agile. Then engage them in designing change by asking questions and building on their ideas. It's not enough to convince the team that change needs to happen. You also need to show them how to get started. Expect some backlash with every change, and don't let the teams reaction throw you off balance. They may simply be recovering from the last great idea for management, which didn't work out. And be cynical about making any change at the moment. Never take criticism personally. It's most likely to change rather than you that the team is reacting to positive and keep your coaches had firmly in place. Take some positive action, such as working out the root causes of any team grabs, and then look for ways you can resolve them. 16. Set a Realistic Pace: Patients is one of the most important qualities of a coach. Don't expect instant protection from the team. Change takes time. Take care not to add to the stress on the team by finding fault with their early attempts to be agile. We're having unrealistic expectations. Remember, the team may be under other pressures that are distracting them from learning about Agile right now. Chill out and don't add to the pressure. When the team is slow to apply what you've been teaching them, don't jump to blame them. Take responsibility and look to yourself for the cars. Are you going too fast? Have you chosen a bad time to get started? Back off for a while and let off some steam by talking to someone outside the team. Patients is not the same as complacency, don't give up. You do want to see a change of ventrally. So keep pushing gently and persistently. Can you find another way to help the team see how important it is to slow down and learn these new agile skills. Look for ways you can support the team by getting the rocks out of the way and making it feel safe to try something new. 17. Mind Your Language: This might be a surprise, but when you're a coach, you have to watch your language. Of course, it helps to keep it clean. But what we're driving it is that you need to take care how you talk to the team. Show that you are part of the team by talking from a team perspective using our wie es rather than I, you, they say, We need to update our release burn up chart. Instead of you need to update your release burn up chart. The difference is quite subtle, but important because it shows the team you're on their side. You don't need to use inclusive language all the time. When sharing a personal opinion. It's clearer if you use I as in. I've noticed that our tests are taking more than an hour to run. If you notice something unusual, say-so for example, I haven't seen it done this way before. Or the more concrete. The last team I worked with checked with their customer before they put out a release. Sharing this as information rather than advice or criticism can lead the team into considering alternative approaches. Avoid making sweeping generalizations. Don't use words like never, always, right and wrong. Because doing so can discount the situation at hand. Try hard not to dismiss past practice by saying it was wrong or incorrect. This creates bad feeling. And people may feel they've lost face. Beware of putting people in boxes, uh, using labels and talking about the developers or management. Putting people in categories creates a barrier to communication. Try to use people's names. Every time you use someone's name, they feel important. They feel like they have a little more connection with you. They listened to what you have to say. 18. Learn As You Go: When things don't go as you were hoping, don't panic. Take time to reflect on what happened and why. The most powerful lessons are learned from mistakes. Ask yourself what you can do differently if you're faced with the same situation again, although it's tempting, don't try to protect the team from making mistakes. Instead. Give the team room to make mistakes and be there to help them learn from the experience. You don't need to be busy working with a team all the time. Take time to stock up on fresh ideas and keep up with what's happening in the Agile community outside of the company. Read books, read blogs, listened to podcasts, and try to connect with others who are interested in Agile. 19. Coaching Your Team: You will be coaching the team every time you meet them. But there are subtle differences in what to focus on in the different meetings and events. During backlog refinement and sprint planning meetings, you should focus on facilitating, helping the team and stakeholders make great product decisions. After the daily stand-ups, however, you have a great opportunity to grab five or ten minutes with a team following up on how they are doing short-term. And the retrospectives. You can drive long-term team questions. The Agile framework you have chosen supports coaching in certain ways. Let's compare Scrum and Kanban. Scrum conveniently provides a number of prescheduled meetings and touch points with the team, So there is little to plan. Scrum also has two specific roles besides the development team, namely the Scrum Master and the Product Owner. Both of these are make and break roles. As the Agile coach, your job will become difficult and you will lose precious time if one of the designated persons is unsuitable for the job or doesn't have enough time to do it. Well, kanban, on the other hand, doesn't define any meetings or roles. We find that many teams pick up meetings from other Agile methods. And these generally fall in one of three categories. One, just-in-time meetings, backlog replenishment, continuous improvement meetings, quality circles, to asynchronous cadences, daily stand-ups, backlog refinement, retrospectives, three cadences synchronized with other teams, daily stand-ups, released demos. Just-in-time meetings are often scheduled on short notice. Hey, let's refine a couple of backlog items after lunch today, which can be difficult if you are working with multiple teams or multiple clients. Cadence meetings, on the other hand, can be scheduled months in advance. For this reason, I have found it best to set up cadence meetings during the coaching period. Also when working with Kanban teams. Each of these touch points bring together the whole team or a subset of the team and provide a great opportunity for you to observe or interact with them. Don't give them up too easily. New Scrum teams often think that some of the built-in activities are obsolete or boring and want to skip them. If that happens. I suggest that you ground the discussion with the team and the values and principles in the Agile Manifesto. Together, figure out which values and principles are behind each of the activities they want to skip. If the proposed change does not undermine those values and principles, Just go for it. Otherwise, a better option would be to figure out new and better ways to meet the values and principles. When observing your team, that's useful to look at team dynamics, what they talk about, and the energy levels. I often use the following cheat sheet of questions adapted from lisa atkins. Is everyone who wants to getting the time to speak by their dominant people in the room who need to listen more. Or they're quiet voices that want to be heard. Or the ideas of high-quality, or are people simply going with the easiest solution? Is the team moving toward the simplest solution possible? Or are they going future proof and gold plating it to? Is the team getting tired? Do they need a break? Is the atmosphere getting tense? Do they need some comic relief? Is the team being audacious enough? Do they come up with great ideas or breakthrough barriers? Or are they avoiding taking a risk? Are they taking on as much as they could or are they letting accepted barriers get in the way? Is the team considering things in terms of customer value or in terms of their own effort? Are they stuck? Do they need a new perspective? One that brings them more possibilities? This is intended to be a starter kit of observation points. Keep this list of observation questions handy somewhere that you can quickly access when a conversation just happens around you. Over time, you will come up with your own observation questions arising from what you observe. For example, if you worked with several teams in the same company, you may notice that they behave similarly. Add your questions to this list and share them with fellow Agile coaches. 20. Coaching the Daily Standup: A daily stand up is a short-term planning meeting. Although the meeting is not exclusive to Agile methods, it's an integral part of many Agile methods including Scrum, Kanban and XP. For an Agile coach, the daily meeting forms a great opportunity to observe the team and asked some coaching questions. Let the meeting run its course. While you observe and listen, make notes and form hypotheses. While every team is different, there are some items to keep in mind. Let's start off with a situation. Does the team report to itself or the scrum master? Is the situation presented honestly? Do they have facts and information in front of them? Is the granularity, right? Tasks less than one day in length. Then pay attention to the focus. Is the goal clear? Is that team focusing on getting the next backlog item done rather than ensuring everyone has worked for the day. Is there a lot of bureaucratic overhead? When it comes to speaking? Reflect on these questions. Does everyone get the opportunity to speak? Who speaks most? Who is most silent? You people listen intently or are they just waiting for their own turn? People supporting each other? Let's pay attention to their decision-making process. Who makes decisions? Is it one person or the whole team? Do they evaluate multiple options? Our decisions based on facts? If they make guesses, Do they go on to validate the decisions before investing time? What about the language? Does the team have their own slang? Does the body language support the verbal message? When it comes to trust? Are they showing respect for each other and for other teams? Are they having fun together? Are they able to bring up difficult topics? Are there showing courage? Stand-ups are also a good moment to evaluate team agreements. For example, retrospective action points, daily goals, checking burndown charts, urgent tickets, or any other things that team agreed to check daily. If you have something to discuss with the team or just want to share your observations, you can ask them to stay on for a few more minutes after the meeting. It's polite to make this request before the meeting starts. Here are some best practices to try. Focus on the work, not the worker. Avoid asking each person on the team to give a status report. Focus instead on the stories and priorities. Pass a ball or some token around to indicate whose turn it is to speak and to add dynamics to the daily stand-up. Team members should be speaking and making eye contact with each other, not reporting to the Scrum Master. If the team is not finding the meeting useful, find the root cause and fix it. Rather than abandoning the meeting. Often the granularity of the tasks does not match the frequency of the meeting, where people do not see the need to collaborate. A parking lot for discussions that are too long or do not concern the whole team. Keep the stand-up focused, finish it on time, and then anyone who needs to continue the park discussions can do so after the meeting is over, anyone has the right to call timeout. Towards the end of the meeting. Ask questions like, which story are you going to finish next? Or do you have in front of you all the information you need to make good decisions. 21. Coaching Refinement and Planning: The sprint planning and backlog refinement meetings are strongly focused on product questions. Your role as an Agile coach is initially to facilitate the meeting, helping the team and stakeholders have productive discussions and make good decisions about the product. At the same time, you will show the scrum master how to run a good planning meeting. Over time as the team learns what the planning meeting is about, coaching the scrum master will become your primary focus point. Eventually you can step back and let the Scrum Master take the lead. I would like to point out that an Agile coach should not get involved in product design questions. As an Agile coach, you should always be careful not to involve yourself in content and productive decisions when advising and role modeling. It may be tempting to propose new and nifty features or nudge the user interface to. So remember that you have been engaged to improve the organization and not the product. When you position yourself inside the system, you are making it difficult to stay objective and unbiased. And unless you happen to be a recognized domain expert, it is very likely that the organization you are coaching understands their customers better than you do. You should help the team learn the tools and methods they need, coaching and training and help them bring out information if necessary, facilitating. You can also provide options if you receive a direct question. But it's not your job to design the product. 22. Coaching the Retrospective: The retrospective provides a way for you to engage the team members in improving their process in direct response to problems that they face. As a coach, you want to enable the team to learn how to use their retrospective to identify where they feel pain in their current process and to learn how to reduce it themselves. I often meet agile teams that have already tried retrospectives and have given them up. They felt their retrospectives didn't result in any change. So continuing with him was a waste of time. This situation is usually caused by not knowing how to run retrospectives. Here are some smells that indicate the retrospective isn't working. Ideas fest. The team members are asked to call out ideas without discussing what happened in the last iteration. This doesn't work because problems are glossed over. Actions may not be connected to resolving problems and tend to be about trying out cool stuff rather than fixing what's not working. History lesson. This retrospective is rather like an archaeological dig that results only in lists of what went well and what needs improvement, but no actions. This can improve communication as the team gradually understands what's happening. But because there's no discussion about how to improve, change is left to individuals rather than planned into the next iteration. Change the world. The team commits to an ambitious list of actions without considering whether it has time to get them done in the next iteration. This leads to disappointment because the actions don't get done. And the team adds more actions to this list. Every retrospective. Wishful thinking actions discussed are rather vague with no owners, such as improved communication or do more refactoring. These are not actions, they are problems to work on. Without more discussion. The team doesn't really know what to do to implement these pseudo actions. No time to improve. The team takes five to ten minutes after their iteration demo to have a quick chat about how things have been going and calls that a retrospective. This is a sign that the team sees no benefit in retrospectives. If individuals do have ideas for improvement than they face a struggle to implement them without a forum to get support from the team. Hot air. The team spends the retrospective grumbling about how bad things are without taking responsibility for improving the situation. This may be cathartic and release tension in the team, but can easily turn into a blame game. Retrospectives are about making changes for the better, and that can't happen without some discussion of what the team can do. Wire retrospectives important when done correctly. Retrospectives can be a catalyst for organizational change as well as team change. They can be a place to build and enable Teams or to help teams start their journey from the best possible place. Team retrospectives can be a place for learning, problem-solving or having fun and motivating each other. This is why it is so crucial to get them right. In retrospectives, participants look at the process and discuss what worked and what did not try and to understand the reasons for each. They then make hypotheses about how to address problems and define actions that could solve them. To make this happen, it is crucial to clearly define the goal. Who was responsible for achieving it, what is the timeframe, and which metrics will be used to verify the outcome. The status of these action items should be checked at each following retrospective. It is important from time to time for leave room for new independent, innovative ideas and experiments to improve the process. Diana Larsen and Esther Derby, in their book Agile Retrospectives, Making good teams great, lays out five stages of a successful retro. Set the stage. Understand where everyone is coming from today. Gathered data, get the viewpoints of all members of the team so that you can create a shared picture of what is happening, generate insights, unpack the data, and analyze or look for the root causes. Decide what to do. Make sure the team decides what's most important together. Close, appreciate people's time and get feedback on how to improve your retro future. Your retrospectives won't always need to include all five stages. But this is an excellent baseline and makes for a good starting point. Let's look at some tips you can share as a coach to help a team improve their retrospectives. A generic retro structure can be a good start. But if you wanted to make meaningful improvements, you need to make sure that you understand the specific needs of your team. The facilitator, coach or Scrum Master should observe and pay attention during the sprint project or whatever cadence the team has. They should be looking closely at how the team works together in any difficulties they're having, encouraged the scrum master to ask herself, what does the team need? Is there a specific issue that they are grappling with? Are they making their sprint goals? How is the level of trust? Have they lost trust in each other? Or is there a lack of trust between the team and the product owner? Are they a new team still finding their rhythm? How are the energy levels? Another way to meet the teams needs is to simply ask them before the retrospective. Here's an example of a survey I sent out to participants before the retrospective to collect the issues they want to discuss to help me work out the best format for the retrospective. I would appreciate if you would send me an email answering the following questions for you. What are the top three topics that need to be discussed? Looking back, are there any high points that stand out for you? Were there any particular events that are still a puzzle for you? What reservations are concerns do you have about this retrospective? What impact do you hope this retrospective will have? Your answers will be kept in strict confidence. I will review everyone's comments and identify common themes, but no individual response will be shared with a group. With these answers in hand, you can start to put together a picture of what the team needs. Maybe there are big trust gaps in the team that need to be addressed. Or maybe they're lacking resources. Maybe they have just had a hectic series of sprints and they need to celebrate their wins and not change anything. The only way to find out it to be in tune with your team and the work they're doing. Once you have decided on what your team needs to focus on, you need a plan for your retrospective. Spend some time deciding how you're going to divide up the time spent in the Retro. Are you going to split it into five phases? Do you need all five phases or can you skip some? And finally, what are you going to do for each phase? Break people into smaller groups. Groups of two or three are optimal in a retrospective, it makes it much easier to keep the energy high and keep people engaged, is also much easier to get things done. Make sure you are encouraging everyone in the team to contribute in their own way. Many people are tempted to force people out of their comfort zones, such as making introverted employees take the lead on talking. While there is some merit to encouraging people to step out of their comfort zones, remember to play to everyone's strengths. Someone who doesn't like talking, a preferred to do the writing, do some silent brainstorming and a small group get up and take notes on the board. These are valid ways of being engaged and they bring the best out of people rather than putting them on the spot and causing anxiety. A common mistake in team retrofit is to approach it without a specific outcome in mind to see what comes up. This lack of structure can be useful on occasion to allow the team more freedom to explore their experiences. However, most of the time it can make things feel directionless and can get in the way of moving forward. Make sure that there is an outcome for the retrospective and provide support to the team and reaching that outcome. Be careful not to make the change for the team. You want to encourage self-organization. If you were only looking at the symptoms of a problem and not understanding the root cause, then you are missing a valuable opportunity for learning and improvement. You will also keep having to deal with the same or similar issues over and over again. This may also result in long lists of policies or agreements set up to change behavior, but without meaningful change because the root cause hasn't been addressed. Analyze and dig beneath the surface, or you may just be wasting your time. Use smart goals. Remember to not try to do everything at once. One or two key changes are usually more than enough. If team tries to do everything, they often end up doing nothing. A good idea is to come up with an action plan and include a smart goal. Smart goals are specific, measurable, achievable, realistic, and timely. 23. Resolving Conflicts: As a coach, you may be drawn into situations where there is a conflict within the team that's holding them back. Sometimes this is an open disagreement and other times it's a festering situation where there's a disagreement, but it's not openly discussed. If you detect that there's a concealed conflict within the team, spend time listening to the concerns of individuals on the team. This helps you understand the causes before surfacing the conflict with the team. Before you dive into the role of peacemaker, consider whether the dispute will resolve itself without your help. If you intervene every time there's a dispute, then you may find team members start whining to you as if you were a parent being called upon to resolve squabbles between kids. Marshall Rosenberg teaches and approach in nonviolent communication that is a useful technique to apply to defuse conflict. The basic principle is that you ask about the feelings and needs of others. By listening to them, you help build enough trust that others will listen to you. The four basic steps are as follows. Observation. When you describe your observation, feeling, are you feeling just the emotion? Need because you need guessed the need request. Would you like me, him her them to specific action? For example. When you walked out of the design review, I guess you were feeling frustrated because you needed more time to explain your new design to Roger. Would you like me to arrange a follow-up meeting with Roger so you have some time to get your idea across. When you are acting as a mediator, be clear that in this role you can't take sides. Listen to the problem from each side, and demonstrate that you understand what is being said by restating the problem in your own words, or ask them to restate each other's problem. Next, try to detach the problem from the individuals and frame this in the context of the team. Explain the situational factors that you see at play in the situation. Such as if there's pressure on the team to deliver and people have been working late. It may even be useful to create a diagram of effects to explore the forces involved. Resolving disputes within the team helps stop them from working at cross purposes. However, remember that some differences in opinion are healthy. Too much emphasis on peace and harmony within the team can signal that the team members are complacent. Group think and set in where the team favors group happiness and conformity over critical thinking. Whenever making important decisions. Try to make sure the team considers different options. Ask the team for a devil's advocate perspective to anticipate problems with what they're proposing to do. If someone has an emotional outburst because of a conflict in a meeting, I recommend you call a break to give them time to calm down and recover their composure. Before you resume the meeting, take a moment to talk to the person to understand what has upset them. If you decide to continue the meeting, don't pretend nothing happened. Acknowledged that feelings are running high and check with the whole team whether they can continue with the meeting or whether the issue that caused the upset should be resolved first. How can a coach help when planning meetings have a lot of conflict or tension? Running planning meetings can be challenging. Developers often have opposing views on how the design should be done. Customers may not see the point in changing or splitting the stories. Tension in the first part of the meeting. Stories are being discussed. Maybe about how to slice the stories or which are the most important stories. Encourage the team to explain their ideas and concerns to the customer. Be clear to the customer that they need to listen. Ultimately, what stories end up in the plan has to be a joint decision. The second part of the meeting can also become tense because the team has to agree on how they will build the software to deliver the stories. A certain amount of conflict here probably helps test and improve ideas. But too much conflict is just unpleasant and inefficient. If several alternative solutions are proposed, all of which seem equally good or equally bad, then remind the team to judge each solution on how simple it will be to develop. The team might try developing both solutions. This will help them learn more about the problem. Soon it should be obvious if one solution is better than the other or if a combination of both ideas is best. Although it appears wasteful to code two solutions, it may well be the quickest way to learn and it may provide a better solution. Disagreements on the team about architectural aspects of the design can also prevent the team from moving forward. These conflicts often bubble up when there's a power struggle between developers with different expertise in the team. A common debate is how much logic to put in front-end middleware or stored procedures. The team gets stuck because they don't know how to resolve that disagreement by themselves. If the team reaches an impasse, run a team workshop to evaluate the pros and cons of different design options. Where possible. Bring an expert from outside the team to the workshop to provide an independent perspective. Make sure each alternative gets equal. Airtime in consideration. Suggests the team write up each design on a white board. This helps move the debate away from the personalities and onto the issues. Encourage the team to pick one designed to follow for the next iteration and agreed to review concerns in their next retrospective. Suggests this choice be made by an anonymous ballot if you're concerned about, about the pressure within the team. And recap, if a conflict erupts. Make sure all sides get to share their viewpoint. Don't step into resolve every conflict for the team because otherwise they rely on you as a peacemaker rather than learning to get along.