Agile Leadership ─ Keeping Team Members in the Zone | Will Jeffrey | Skillshare

Agile Leadership ─ Keeping Team Members in the Zone

Will Jeffrey, Professional Agile Coach

Play Speed
  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x
5 Lessons (20m)
    • 1. Welcome

      3:19
    • 2. Meaning of keeping in “the zone”

      2:47
    • 3. Activities that keep out of “the zone”

      3:18
    • 4. Keep a team member in "the zone”

      9:30
    • 5. Conclusion

      0:43

About This Class

In multiple Agile checklists, you can find a question like: “Are Team members spending most of their time in “the zone”?”

  • What does that mean exactly?
  • What could lead a team member to be out of “the zone”?
  • What can we do to keep everyone in “the zone”?
  • Why does this matter concern Facilitators?

This question makes sense if you are already an agile coach.

But it is also appropriate whether you are a Scrum Master or a Facilitator, because these roles have been likened to that of a coach.

A good coach creates star players! If you think of any of the great coaches in sports: They can take underperforming players and make them successful, increasing the success of the team.

As an Agile Coach, you’re here to help the team do the best work it possibly can. You do everything possible to help the team perform at their highest level - delivering the committed product on time, and with the defined quality.

In this course you will get answers for the following questions:

  • What is the zone? What does it mean to be in flow?
  • What does it mean to keep team members in “the zone”? What Does Being in the Zone Include?

  • What activities might keep a team member out of “the zone”?

  • How to keep a team member “in the zone”? 

Also you will learn why the importance of:

  • Handling Impediments
  • Facilitating Communication
  • Encouraging Education
  • Handling Interruptions (“Illegitimus Non Interruptus” pattern)
  • Focusing on the Sprint Goal
  • Making Coffee

Pieces of advice for distributed teams are also included.

Related class:

Transcripts

1. Welcome: in multiple agile checklists, you can find a question like our team members spending most of their time in the zone. What does that mean exactly? What could lead a team member to be out of his own? What can we do to keep everyone in the zone? Why does this matter concern you? These questions will be addressed in this course. To begin will first answer an important question. This question makes sense if you are already an agile coach, but it is also appropriate whether you are a scrum master or a facilitator. Because these rules have been likened to that of a coach. A good coach creates star players. If you think of any of the great coaches in sports, they can take underperforming players and make them successful, increasing the success of the team an excellent example is Jesus Christ, who coached his disciples to make them able to do greater works than himself. John's Gospel reads that one also will do the works that I do, and he will do works greater than these Jesus humbly acknowledge that their works would be greater than his. As an agile coach, you're here to help the team do the best work it possibly. Can you do everything possible to help the team perform at their highest level, delivering the committed product on time and with the defined quality? So who are the star players in your team? When you remove impediments, you saved the day. When you share advice that turns out to have been useful. You are amazing. It may feel like you are the star player, but remember, you're the coach, not the star player. Your star players are on the agile team. Remember, that includes the developers but also the product owner. Business assistance testers, etcetera. Let your team members shine. Now we know who are the star players we need. Answer this. Another question. What is the zone? This flow diagram shows how people react to various levels of challenge in relation to their level of skill inflow. There is a delicate balance between a high level of skill and a highly challenging task. And of course, as your skills develop, you have to look for more demanding challenges in order to remain in flow. The zone, when you are in flow, is a state of supreme focus, which helps athletes in all sports perform at their peak. Potential entering the zone requires total commitment. It is when your mindfully connects with achieving the goal. According to sports psychologists. In this state of concentration, mental distractions lose the battle in competing for your attention entering the zone or the flow State means being at the intersection of the highest level both of your skills and challenges. It involves applying the highest level of skill to the greatest challenges. Star players are better at entering the flow state in which they attain optimal performance and feel the best in this course. These three items will be covered. What does it mean to keep team members in the zone? What activities might keep a team member out of his own? How to keep a team member in the zone? 2. Meaning of keeping in “the zone”: Let's see what it means to keep team members in the zone. What is being in the zone include being in the zone includes the following clear goals, concentrating and focusing direct and immediate feedback. Personal control. Rewarding work. Let's take a closer look at what that means. We're using a car trip metaphor to explain what being in the zone involves the 1st 1 clear goals. Knowing where you're supposed to go in having road signs on your way, doing your best to achieve the sprint goals. Basically, it means doing what is on the Sprint backlog. Focus. No distraction. It includes texting, making phone calls. We want to be focused on one task at a time, like when we're driving. Working on the Sprint backlog most of the time I would say all of the time, but that's not reasonable or realistic. Avoiding multitasking. What I meant by multitasking Here is a context switching in the middle of a task. It takes 10 to 15 minutes without interruption to get into the zone. Feedback. When you're driving your dashboard indicates in real time your current speed and any warnings you need to take into account. We need the same in a project getting direct and immediate. For example, using test driven development, or T d D gives you the advantage of the cycle with unit tests. You know your code works shortly. Integration tests are not so immediate, but provide similar certainty. Knowing the Sprint Progress servant leaders like scrum masters and agile facilitators ensure that information is radiated. Daily sink is useful in this regard. Personal control. When you're driving, you are in command. You're holding the steering wheel. What is the equivalent for your team? The concept of the self organizing team. The team decides who is doing the job and how, within the limits of its authority, fostering collective ownership of the work. A good question to check its maturity level in this regard is, Does the entire team consider itself collectively responsible for testing user documentation, etcetera Rewards Arriving safe at your destination and happy to get there, especially if you were in vacation. You are home where this is the finish line. Team members should celebrate each other's success. How can we tell whether our team members are in the zone? Basically, it is when they're working on what is in the Sprint backlog 3. Activities that keep out of “the zone”: interruptions and distractions that don't contribute. Sprint goals are impediments they prevent from keeping in the zone. Let's start with interruptions. A team member is working on tech support, something out of the Sprint backlog. It might be an investigation of weird system behavior, performing system maintenance, etcetera. Remember, there is certainly a team for that in your organization. We want to be helpful, for sure, but each team has its own responsibilities. By the way, we can be helpful by communicating the issue to the right team. Environment problems interrupts the flow. For example, a broken build, a network outage, an issue with a version control system. Like it etcetera. Sprint process flow is impeded due, for example, to not enough requirements or a lack of technical knowledge. Were waiting too long for code reviews, etcetera Remember. Motivation is linked to accomplishments and progress. It's important to solve them quickly or anticipate to avoid them. Now let's talk about distractions First great idea syndrome. Sacrificing product development time for personally developed tools. This is must not be confused with legitimate activities like building tools as part of ongoing personal education or in case of a spike when a developer codes a proof of concept to investigate an implementation. In this context, basically, he's doing research and development for a user story, not a duly gold plating That is the practice of making changes to a project that are outside of the original, agreed upon scope. It happens when developers add unnecessary features or refinements or one re factoring gone bad. And in this case, the extra effort doesn't bring out of value scope creep that refers to how it projects requirements tend to increase over a project life cycle. For example. What once started out as a single deliverable becomes five or a product that began with three essential features now must have 10 or midway through a project. The needs of customers change, prompting a reassessment of the project requirements. Scope creep is typically caused by key project stakeholders changing requirements or sometimes from internal miscommunication and disagreements. Consider M V P. Minimum viable product. Instead, that will help you to avoid it. Pair programming gone bad because workmates were not actively engaged where there was a motive mismatches, for example, one started the pair programming because he was looking for help with good design or knowledge transfer whether the other was looking for social connections. This discrepancy and motives can lead to failure. Noisy workplace Especially true when sharing offices. Think about this question. Can we mitigate the disadvantages of colic ation in order to benefit from the advantages more about that later? 4. Keep a team member in "the zone”: Now we're going to address the question. How to keep star players in the zone. We will be demonstrating some of the activities that keep team members in the Zone. Six activities to keep star players in the zone. Handling impediments. Facilitating effective communication. Educating the team, handling legitimate interruptions, focusing on the Sprint goal. Making coffee. Let's discuss each of these activities handling impediments. This is our top priority to keep the team in the zone environment and fools ensuring team members have everything they need to accomplish their work programs installed. Computer environment ready to be used. Tip. These tax can be simplified with checklists that helps for finding resource locations and following installation sequence in team area on Web portal like SharePoint or incorporated into a wiki. Use the daily sink, also known as daily Scrum, to determine concentration and focus in the flow. These questions might help which developers air struggling to complete tasks, perhaps due to lack of framework or technical knowledge, etcetera. Our developers, spending time on tool making or other outside work, use Sprint retrospectives to improve the process. Address process issues, for example, regarding pair programming habits, lack of requirements, context, switching mid task, etcetera. Build a helpful team culture to feel collectively responsible and pulling together. Encourage good communication with other teams. For example, when it comes to collaboration or tech support. Tip. Ensure they know who does want. See the organization chart of existing attempt to schedule the retrospective after the Sprint Review. This way, the review is used as a benchmark for the effectiveness of the process. Tip. Although you want to look for ways to improve, always include positives as well. Celebrating success is a key component of staying in the zone. Use one on one to address sensitive issues like noisy workplace. Tip the earplug protocol to indicate need for quiet tip. Invite others to monitor your own noise. By initiating communication on this issue and use the Baby Brother protocol, I turn the volume down hand gesture. Facilitating effective communication. Distributing breaking news could be about overnight activity. Production report announcements etcetera. Tip mentioned them at the daily sink on the team's own persistent chant or send an email ensuring meeting recordings are easily available. For example, these recordings air used in large project went team members air not co located or when they're not working in the same time zone. Having them ready and available in a known repository helps to keep everyone in the zone. If you're interested in knowing more about effective communication and agile, see my course on this topic in skill share. Educating the team, consolidating emergent technical knowledge tip subscribed to forum categories and pass on the emergent knowledge in its context. For example, by round up emails were on a wiki promoting best practices. Use code review to promote single responsibility principle. Proper test plans. Etcetera. Also to monitor gold plating and scope creep tip. Spread code review among developers. To reduce the feedback cycle, minimize contact switching and improve skills through cross pollination. To that hand, use a double review training process. Use Sprint retrospectives to educate. For example, consider the benefits of unit tests. Educate on natural principles towards self organizing concept. Using task board to identify priorities. Task Self assignment. Use Sprint Planning to train, for example, Encourage ready to start user stories small enough to finish split. If not ensure awareness of Sprint velocity and establish clear targets. Ensure that Sprint review is product focused, for example, concentrate on completed functionality completely done that has understandable value to the stakeholders to clearly reveal the effectiveness of the process. Handling legitimate interruptions, critical bugs in production. In almost all cases, it is desirable to have the scrum team meet their own dog food. If they produce a defect that gets into the field, they need to fix it as soon as possible. Setting up special maintenance teams to fix defects. Incentivizes the scrum team to not be attentive toe latent defects. For these and many other reasons, a scrum team is always exposed to interrupts that disrupt production to support the commitment while allowing capacity to fix bugs. Estimate a number of effort points for, interrupts a buffer or slack, and build that into the commitment. This pattern is called the L Legitimate. Non interruptus set up three simple rules that will cause the company to self organize to avoid disrupting production. This strategy will help the Team Marie plan during a sprint to raise the chances of delivering the complete product increment, the team creates a buffer for unexpected items based on historical data. For example, 30% of the teams work on the average comes from unplanned work coming into the sprint unexpectedly. If the team Velocity averages 60 points. The team reserves 20 points for the interrupt buffer. So during the Sprint planning, the team commits user stories up to 40 points of effort. All non trivial requests must go through the product owner for triage, for example. Web page spelling errors and compilation errors are be considered of trivial errors. Where the fix is so obvious that there is no benefit from additional business insight. Developers may spend some small time boxed amount of time addressing even nontrivial defects before escalating to the product owner. The product owner will give some items low priority. If there is no perceived value relative to the business plan, the product owner will push many other items to subsequent sprints, even if they have immediate value. A few items are critical, and the team must complete them in the current sprint, so the product owner puts them into the interrupt buffer. If the buffer starts to overflow, meaning the product owner puts one point more than 20 points into the sprint, the scrum team must automatically abort, the sprint must be re planned and the product owner notifies management that dates will slip, focusing on the Sprint goal making fools. They may have value to the project but are not considered a product increment. Are your developers working on items that are not in the Sprint backlog? Meaning they're making tools. Check usefulness with software architects and tech leads. Perhaps tooling direction is going to change. Check priority with product owner. Another Managers tip better that you, the facilitator or a scrum master do it as you're not directly responsible for the Sprint goal, but we need to be reasonable based on skill. Sets following up on retrospective action items. Tip. Include an action item follow up Survey is the first activity in your retrospectives. Radiate information Used. Big visible charts make the task board visible especially useful during the daily sink tip in CA, located work areas Create a visible dashboard like for airport departures and arrivals boards with a PC and a wall mounted monitor making coffee. After all, as someone said, programming is turning caffeine into code Lesson. Do whatever it takes tip help requirements and business assistance for technical understanding According to your skill set. Let's summarize what we have discussed during this session. Handling impediments. Our top priority to keep the team in the zone environment and tools, ensuring team members have everything they need. Use the daily sink to determine concentration and focus. Use Sprint retrospectives to improve the process. Use one on one to address sensitive issues. For example, noisy workplace facilitating effective communication. Distributing breaking news gleaned from overnight activity. Ensuring meeting recordings are easily available, especially for team members, not on the backbone. Educating the team. Consolidating emergent framework knowledge. Promoting best practices. Handling legitimate interruptions for critical bugs in production. Used the illegitimate snot interruptus pattern focusing on the Sprint goal making tools. They may have value to the project but are not considered a product increment. Following up on retrospective action items. Radiate information. Used big, visible charts. Making coffee. Do whatever it takes to help your team members to keep in the zone. I hope this course will help you and your team members to succeed with agile by keeping everyone in the zone 5. Conclusion: in conclusion, I think I may have given you further food for thought in answering the question I asked previously. What do you do to keep team members in the zone? I hope these ideas and tips help your team having clear goals, being able to concentrate and focus, getting direct and immediate feedback, having personal control and doing rewarding work by. Keep doing this. Your team will be fully immersed in a feeling of energized focus, full involvement and enjoyment in the process of the activity they will perform at their best.