Blog


What to Do When the Team Complains About Agile Processes

I recently attended a Lean Coffee event at a Denver-area agile meetup. The group was asked to come up with issues they were struggling with and then, after a vote, we had time-boxed discussions on those topics that generated the most interest.

The topic that I found the most interesting was: What do you do when the team complains about agile processes?

As with most things related to agile, there is no one-size-fits-all answer. What one team may find cumbersome, another team may like.

Almost everyone seemed to have examples, however, of times during which they were on teams that were unhappy about at least some agile processes.

Listen

The first thing a Scrum Master, coach or agile servant leader should do when they have an unhappy team is to listen to the team and understand the root cause of the issues they're experiencing.

“Try to get them to understand the why behind the processes,” someone advised. If the team can come up with another way to satisfy the end goal, then maybe it should be explored.

Not only do you want them to understand why processes are in place, but you also want to understand the team’s concerns with the processes.

“Ask several ‘whys’ and get to the root of their fundamental fears,” advised someone from the group.

Examples of root causes seemed to fall into two categories ...

1. Issues with the Tools

In many of the examples that were given, the issues seemed to be related to the tools being used rather than the fundamental agile principles. If tools are slow or filled with heavy processes that take a lot of the team’s time, they aren’t going to like them.

Though we all know that agile promotes individuals and interactions over processes and tools, the reality is that in large organizations, teams often don’t have much control over the processes and tools that are being used. If every team used their own favorite tools and processes, the lack of consistency would cause chaos.

That being said, if tools and processes are creating unnecessary waste, the team might be able to suggest ideas to reduce that waste. The teams may not be able to change which tools they’re using, but perhaps they can work together to come up with some organizational suggestions that could lighten up the processes.

2. Teams Are Not Getting Enough Support

The other category of issues that people brought up related to lack of management support. Stories included teams who were uncomfortable with estimates.

“It took a year for them not to be scared to commit,” said one Scrum Master of a team he’d coached. “As a Scrum Master, you need to help them.”

But how to help them? Again, start by understanding the root cause of why they’re scared to commit. What happens if they miss their commitments? Who holds them accountable and how?

Though agile promotes self-directed teams, the reality is that many organizations are still operating in command-and-control cultures.

The Scrum Master may need to not only coach the team, but also coach management.

There are no easy answers, but start by listening and truly understanding the issues. Then, elicit the help from the team, making sure everyone’s voice is heard.

In the end, you want to empower the team to help solve the problems they’re experiencing.

Stop the Multitasking, Listen and Engage

I’m a huge advocate for distributed teaming and the flexibility and variety of benefits we can get from a work-from-anywhere culture. However, especially in agile circles, co-location is pushed hard.

Though I hear over and over again the challenges of things such as time zone differences or cultural differences as barriers for distributed teams, I rarely hear mention of what I think is one of the primary problems when working remotely: Multitasking!

When you’re on a conference call where you can’t be seen, you’re much more likely to put yourself on mute, and keep working on whatever you think is a higher priority, just barely listening for a mention of your name or something you think you might need to know.

In fact, even when there are conference calls across sites, and many people are in the room, I’ve been in many a meeting where someone puts the room on mute so that side conversations can happen, even while someone is presenting.

If we were physically in the same room with the speaker, out of respect, most people would at least pretend to be listening.

But when you can’t be seen or heard, it gives license to not pay close attention, and so we multitask, chat or play with our phones during the parts of the call where we think we can get away with it. (Perhaps holoportation will solve these types of problems in the future.)

Focused listening can be difficult, even if we’re co-located. These days we’re constantly interrupted with texts, phone calls, tweets or emails our devices deem important with a variety of notification beeps, quacks or ring tones.

People are distracted with their smartphones, even when they are talking one on one with someone in person, so much so that it’s almost become the new norm to multitask constantly, preventing us from gaining the beautiful benefits of connecting with a person instead of a computer.

Though I’m totally a fan of multitasking in certain situations (for example, I love to listen to podcasts while exercising), it’s a huge barrier for effective one-on-one communication.

I fully believe that distributed teams can be just as effective as co-located teams, but if you are working remotely, it’s more important than ever that you learn to practice strong communication and teamwork skills from a distance.

That means you need to stop the multitasking during conference calls and start listening and engaging.

I teach both face-to-face and virtual classes, and, of course, the face-to-face classes are easier for me because I’m able to see the body language of the students and do activities to keep them engaged.

However, during virtual classes, we play games throughout the class so that the students can participate via chat, being the first to answer a question or cheering on a teammate. The other day, one of the students used his webcam to show us his new adorable puppy! Now that’s something that doesn’t normally happen in a co-located class.

Many of the problems that keep us from communicating effectively, such as multitasking, are happening regardless of where we’re physically sitting.

We need to recognize our own poor habits and work to enhance our communication. This is especially important if we don’t have the benefit of communicating in person.

So, stop the multitasking and, whether you are face to face or remote, when you’re communicating with someone else, find a way to listen attentively and share your smile.

Holoportation: The Newest Way to Virtually Communicate

If you’re a fan of the sitcom “Silicon Valley,” you may remember a scene in which there is a holographic teleconference meeting. Gavin is teleported and his 3D image appears to be in the room with the others in the meeting.

It turns out this new type of 3D communication is not as futuristic as it may seem. In fact, Microsoft Research has been working on the 3D capture technology dubbed “holoportation,” allowing high-quality 3D images of people to be transmitted in real time to a remote location, creating a mode of communication remarkably similar to that shown in the “Silicon Valley” episode.

By using a HoloLens, a headset created by Interactive 3D Technologies, a user is able to see the reconstructed image of someone who has “holoported.”

This video demonstrating the technology shows how the 3D image is seen to someone wearing the HoloLens. It appears as if someone remote is actually in the same room!

Of course, in that “Silicon Valley” episode, there were technology issues; first with the holographic teleconference, then, with the video conference, and finally, even with the cell phone.

Even though new technology is awesome, there are often complications and growing pains, which can cause frustration for new users or early adopters. The good news is that the issues continue to get fixed and the technologies continue to improve.

Who would have believed how easy it is now to communicate “face to face” even when we’re not physically co-located? With tools like Skype and Google Hangouts, just to name a couple, video chats and conferences have become simple.

Now we are literally taking communication to a whole new dimension with 3D communication. Though this technology is still in its infancy, it will undoubtedly improve and someday we may find it hard to remember a time when it wasn’t available.

Though I don’t believe any mode of communication can completely replace the connection that results from being physically together, the ability to communicate real time in 3D is another big step in face-to-face communication.

Some people criticize technology for taking away our “real life” social connection, but I think if used well, technology helps us enhance the social connections that are most important to us.

For example, the stronger our communication and collaboration tools are, the more freedom we have to be spending our physical time with the people and in the places that mean the most to us.

Thanks to advancements in technology, employees have more options to telecommute or avoid work travel and spend more time with their families.

In recent years, I’ve known many people who have been able to spend time with ailing parents and still accomplish their work by taking advantage of tools that help distributed teaming.

In my opinion, employers are really putting “individuals and interactions over processes and tools” when they give their employees the freedom to spend time with their families, as long as they’re able to do their job well.

Holoportation is the latest, greatest innovation in communication. Though it may be a while before it’s mainstream, I’m excited to see how this new technology will be used and how it will grow and improve over time.

What do you think? 

What, When, How: The 3 Levels of Strategic Agile Planning

When we think of agile, we often think of quick reactionary planning to the realities of a project as it unfolds.

For that reason, most discussions of agile planning focus on the short term. Our teams plan and synchronize at the daily level using recurring morning stand-ups. And, for those teams practicing Scrum, we plan at the iteration level using recurring sprint planning meetings.

Both of these practices are great for keeping a team on the same page tactically, but what about strategically?

Luckily, there are some simple techniques for aligning your team strategically and helping them to think beyond the sprint.

Strategic agile planning comes down to three simple questions:

1. What are we doing?
2. When do we need it done?
3. How are we going to get there?

The key is to remember that the answers to these questions will likely change as your team progresses through the development of your product. But, by taking an iterative approach, you can keep your teams on track to ensure that you deliver the right product at the right time.

So let’s take a look at these three questions in turn to see how each propels you down the path of creating a great product.

What are we building?

The most important decision that you need to make as a team is what are you building? But the question is often more complicated than that. Instead, the deeper question is often what need should your product be solving.

One of the best ways to answer this question is with a visioning canvas. There are many variations of the canvas available, including the well-known Lean Canvas, but my personal favorite is Roman Pichler's vision board.

The example that you see here is how a vision board for a streaming music service, named Ostinato, may look. Notice that the vision board starts at a higher level than the specific needs of the product and instead focuses on the overarching need that the product is trying to fulfill.

Some of the characteristics you’ll discuss when creating a vision board include:

-Defining the specific user need or market opportunity that the product is trying to fill
-Identifying the core user base you’re targeting with the product
-Identifying potential competitors who may also already be in the market
-Discussing how the product will generate revenue

The outcome of the visioning exercise is intentionally vague, as it is not used for planning the execution of the product, but rather to build alignment across the team of what the ultimate outcome of building the product should be.

Some teams refer to this exercise as “setting their North Star,” as the result is a guiding direction on where the team is heading without the specific steps dictated of how to get there.

Although your product vision is unlikely to change daily, you should expect it to evolve as you learn more about your target users, potential competitors and where your product can most effectively fit in the market.

For that reason, plan to repeat this exercise periodically to re-evaluate core assumptions that you may be making about the competitive landscape, as well as to take a fresh look to help spot opportunities for growth.

To do this, a good rule of thumb is to repeat this exercise annually, though newer and more rapidly evolving products may benefit from a slightly more frequent cadence.

To get the full benefit from this session, you should expect it to be attended by the product’s executive sponsors, the relevant product management team and key technical representation such as the product architect.

Although members of the product delivery team such as engineers, testers and designers may benefit as well, be wary of growing the session too large and remember that the resulting vision may be more effectively conveyed to these team members by the architect and product manager after it’s complete.

When does it need to be done?

Now that you know what you’re building, the next question that you need to solve is when does it need to be done?

But, remember that you’re running an agile project, so rather than waiting until the entire project is complete, you’ll want to deliver in small increments to get as much feedback as possible along the way.

This combination of answering both when you want to deliver your overall product as well as how and when you want to make small incremental deliveries along the way will become your product roadmap.

Product roadmaps are high-level plans that show your product’s intended evolution over the next few releases. They show, at a high level, the overall strategic direction that you plan to take your product, as well as the different guide points along the way that will help get you there.

If the idea of long-term planning fills you with fear as images of Gantt charts dance in your head, don’t worry ... there are better alternatives that we’ll discuss here.

Agile product roadmapping has become a hot topic in the past few years with several very nice tools coming on to the market. However, my favorite is still the goal-oriented product roadmap, or GO roadmap, which was created by the very same Roman I mentioned previously.

What sets the GO roadmap apart is that rather than focusing on the features required for each release, it instead focuses on the goal of each release.

This approach not only frees you from thinking about implementation details and sequencing too early, but it also leaves the responsibility to define the specific features of each release until a time when you know more about them.

The example above is a GO roadmap for the streaming music service, Ostinato. Notice that any features defined here are very high level and intentionally lack specific detail.

Forcing your team to define features too early often creates an unrealistic impression of certainty for your product and can even lock you into a less than optimal feature set too early.

Instead, thinking at a higher level about the overarching goals that each release should meet will free you to think strategically not only about the impact of each release, but also how the entire release cycle for the product fits together as a whole.

While your roadmap won’t change frequently, expect to revisit it more often than your product vision. If you’re revisiting your product vision once a year, then revisiting your roadmap quarterly would be a good rule of thumb.

To be effective, this session should include key technical personnel who can advise you to any technical dependencies or limitations that may affect the goals you’re laying out.

During each roadmapping session, your team should be focusing primarily on the release that’s immediately upcoming. While you’ll still want to leave time to discuss subsequent releases, expect that they will be more vaguely defined and more volatile as they’re farther out on the horizon.

As a rule of thumb, you should be able to draw a diagonal line from the last objective of the nearest release to the last objective of the farthest release showing how each release becomes progressively less defined as you move toward the horizon.

How are we going to do it?

The final piece of strategic planning is to lay out a plan for how your team will approach the next release. This is done with a tool that’s similar to the GO roadmap we discussed previously, but with a more fine-grained feel.

While this release plan contains much of the same information found in your roadmap, it also adds lower level information such as a prioritized list features that will be tackled in each release.

These features can be prioritized by whatever means is the most comfortable for your team ... as long as they are prioritized. I’ll often use the MoSCoW prioritization technique, which has the advantage that it allows for items to be explicitly removed from a release.

Expect to revisit your release plan after each minor release, which should occur more frequently than the major releases detailed on your roadmap. For example, if you follow a release cadence of a major release at the end of each quarter with minor releases at the end of each subsequent month, then you should expect to revisit your roadmap quarterly and your release plan monthly. The goal is to create a plan that represents what your team is currently working towards as well as to give you an idea of what lies in the future.

Ideally, your entire team should be involved in this meeting as they will be those who will deliver the work inside of each release.

And, as with the roadmapping discussion, you should be focused primarily on the next upcoming release and expect subsequent releases to be progressively less defined as you move out to the horizon.

In fact, the guiding principle of drawing a horizontal line from the last feature in the next release to the last feature in the farthest release works just as well for release plans as it does for roadmaps.

Seeing the big picture

Strategic agile planning is as much of an iterative exercise as anything else that we do in an agile context. The secret is to realize that no matter how confident you feel in your overall vision today, it’s very likely to change as your product grows and your market evolves around it.

By taking an agile approach to your strategic planning, you can significantly increase the odds that the product you deliver will make the impact you envision.

A Quick Guide to Agile Project Management Certifications

 

 

As you transition to agile, you're going to be faced with decisions about certifications. If you're thinking about transitioning into an agile project management role, you have a couple choices: Scrum Master or agile project manager.

Since the Scrum Master and the agile project manager are essentially the same role, it's up to each person whether he or she wants to become certified as a Scrum Master or an agile project manager.

There are three choices for certifications for these roles, and the exams are very similar:

The Scrum Master role (CSM) is certified by the Scrum Alliance. The Agile Certified Practitioner (PMI-ACP) is certified by the Project Management Institute (PMI). The Certified Agile Project Manager (Cert.APM) is certified by the Project Management Association of Canada (PMAC).  

The PMAC exam is pretty much the same as the ScrumMaster Certification exam. The PMI exam has an additional "ethics" section to it, and may also have questions on types of agile methods such as DSDM, FDD, XP, Lean, etc.

However, the criteria for certification requirements are a little different between the various certifying bodies. 

The CSM designation (Scrum Master) requires:

A person become familiar with Scrum. The Scrum Guide can be downloaded for free from the Scrum Alliance website. They have also compiled a list of resources to help you see how Scrum transforms the world of work. An in-person, two-day (16-hour) CSM course taught by a Scrum Alliance authorized trainer. After successfully completing the course, you are required to pass the CSM exam. To get a passing score, you must correctly answer 24 of the 35 questions. That you accept the Scrum Alliance license agreement and complete your Scrum Alliance membership profile. 

The PMI-ACP (PMI Agile Certified Practitioner) requires:

1,500 hours working on agile project teams or with agile methodologies. 2,000 hours working on project teams. 21 hours of education in agile practices.

Cert.APM (Certified Agile Project Manager) requires: 

That you complete a PMAC-accredited agile project management course within the 12 months prior to the application.  Have a recognized project management credential, or document a minimum of one year of project, portfolio or programme management experience, which will be approved by the certification body operational committee of the PMAC.

In all of these, you are also required to continue learning and obtain PDUs (for the PMI) and SEUs (for the Scrum Alliance) throughout the year to keep your professional designations relevant and up to date.

What is the Role of the Project Manager on an Agile Project?

The most common question I get asked related to roles on agile teams is around what becomes of the traditional role of the project manager or the business analyst.

The question comes up because agile projects have only three roles: the Scrum Master, the product owner and the development team member.

In this post, I will focus on the project manager role and its evolution in relation to agile projects. 

The Project Manager: How Do You Fit into an Agile Team?

As teams began to adopt and transition to an agile software development environment, and as it became more popular and mainstream, the Project Management Institute (PMI), Project Management Association of Canada (PMAC) and other organizations around the world created the agile project manager role and introduced a career path for professionals transitioning to agile projects.

On some agile teams, the agile project manager is referred to as a Scrum Master. If you've ever wondered how different the roles are of a Scrum Master and agile project manager to the traditional project manager role, let's look at that now.

Authority: The traditional project manager role moves from a command-and-control, hierarchical position to a servant-leader or facilitator position. This is the essential role of the Scrum Master.

Requirements: The responsibility of ensuring the requirements are defined and providing direction for the product and services being delivered move from the project manager to the product owner. The product owner assumes the responsibility for ensuring the requirements are defined, prioritized and ready for the team. This is achieved iteratively, through just-in-time planning and progressive elaboration of requirements. Work Assignments: Assigning work and getting the status of the work completed moves from the project manager to the team members. The rationale behind this is that the agile team is a self-organized group of highly skilled professionals, accountable for the work they commit to in a sprint. The team takes ownership and accountability for meeting the project and team goals.

Managing Stakeholder Expectations: Providing the project status to stakeholders and sponsors moves from the project manager to the product owner, since it is the product owner who provides direction and leadership to the team, so that they can build the right thing and deliver business value based on priority and ROI.

Leadership and Support: The Scrum Master serves the product owner and the team so that they are better able to do their jobs by assisting them, facilitating creativity and fostering empowerment. The goal is to allow the team to self-organize and become a mature high-performing team. This is a change to a servant-leadership model.

Removes Impediments: If the agile development team is unable to resolve issues within the team, for example external dependencies and challenges that are out of the team’s immediate control, the Scrum Master helps remove obstacles and support the team.

To be successful in this transformation, the project manager needs to take on the role of a Scrum Master to become the champion of the Scrum process and facilitate the team’s adoption of Scrum with the understanding that they have no authority over the Scrum team. If this is a role you are considering, you will need to not only adapt and transition your skills, but also move towards an agile culture that embraces agile values. 

Are You 'The Scrum Police'?

I remember my first job as a ScrumMaster. I took it very seriously. I saw my job as being the custodian of Scrum, and ensuring everyone was doing it correctly.

Does any of the following sound familiar to you?

Make sure all the Scrum meetings are set up and rooms booked One minute before the daily standup, call people to make sure everyone attends the meeting Call each person’s name for them to answer the three questions in the daily meeting Make sure any discussion outside the three questions gets parked for after the standup meeting Time the daily scrum to make sure it never exceeds 15 minutes Insist that templates get used for stories Insist that story points are used Create a company-wide template for all Scrum artifacts Force everyone in the team to attend retrospectives Ensure the team completes everything they committed to each sprint Assign work to team members in the sprint Complete Scrum assessments online to see how your team compares to other teams

I did all of the above with the best intentions.

I really wanted Scrum to work, and I really wanted to help my team succeed. I thought this was what was necessary for them to succeed, and I thought that it was what my job entailed. 

Experience has taught me that whilst the above seemed like a good idea, I was actually slowing down my team's learning curve and its level of maturity as a team.

So what would a ScrumMaster with more experience do with the examples I mentioned above? Let's look at that closer.

"Make sure all the Scrum meetings are set up and rooms booked."

Anyone on the team should be able to book meetings and rooms. Perhaps ask the product owner to book the review and backlog grooming meetings, since they would know which stakeholders to invite, and ask a team member to book the daily standups.

"One minute before the daily standup, call people to make sure everyone attends the meeting."

Don’t call people for standup, just start on time. If no one arrives, then sit down again. Ask the team during the retrospective if they missed the standup or if something might have gone better if they had the standup. If you teach them to rely on you calling them, they will not take accountability for themselves to be at the meeting on time.

"Call each person’s name for them to answer the three questions in the daily meeting."

Let the team decide how to do this, even if the first few are a little chaotic. Consider what would happen if you weren’t there for a standup. Also, calling peoples' names implies they are reporting to you; instead, they should be talking to each other. Ask a question at the end like, “Is there anything we would like to change for tomorrow?”

"Make sure any discussion outside the three questions gets parked for after the standup meeting."

Although the standup is not supposed to be a problem-solving meeting, you need to use your judgment on if the conversation is adding value to the participants. Better yet, encourage the team to call each other if they go off topic in the standup, rather than you having to monitor it.

"Time the daily scrum to make sure it NEVER exceeds 15 minutes."

Although daily scrums should be 15 minutes or less, actively timing them usually means you are focusing on the wrong thing, and will drive the behavior of having a three-minute meeting of no value, just to be able to “look good." The duration is much less important the the content of the conversation.

"Insist that certain templates get used for stories."

Don’t force any story templates. The point of a story is to have a conversation and shared understanding. Templates imply written documents, and changes the emphasis from the discussion to the artifact.

"Insist that story points are used."

Let the team decide how they want to size stories. We have a workshop you can run to try out four different styles, then let the team decide what works best for them.

"Create a company-wide template for all Scrum artifacts."

Allow teams to create their own artifacts. This gives them some freedom, creativity and allows them to express themselves. Consistency is much less important than people having the ability to change things to fit their own needs better.

"Force everyone in the team to attend retrospectives."

Retrospectives should be valuable enough that the team wants to attend them. If people don’t want to attend, don’t force them. Rather find out why they don’t want to be there, and work on that problem.

"Ensure the team completes everything they committed to each sprint."

As a ScrumMaster, you are not responsible for delivery. The point of commitments and actuals is not for them to always match, but rather for your team to figure out what they can deliver comfortably.

"Assign work to team members in the sprint."

If you feel the need to assign team members work, I would dig a bit deeper and see what the underlying reason is. Asking the team an open question like, “Is there anyone on the team who can help with this?” is better than assigning something to someone on the team.

"Complete Scrum assessments online to measure how your team compares to other teams."

While Scrum assessments might be helpful, the team should be assessing itself and deciding what the results mean for the team. Usually, if Scrum Masters are assessing their teams, it is because they are wanting to see how their team is doing as a reflection of their value as a Scrum Master. Rather, ask your team what you can do to add value to the team as a Scrum Master. 

Some Final Thoughts

Consider if you are making your team dependent on you, or helping them become a self-organizing team. Try to be less of a master ordering the team around and more of a servant leader, helping the team become better than it is today. These days, we judge the effectiveness of ScrumMasters by how well the team learns, deals with conflict and collaborates, rather than which boxes they check on a Scrum checklist. 

Is 'Host Leadership' a Better Term Than 'Servant Leadership'?

When my grandfather made a toast, he often raised his glass first higher than the other glasses and said, “Never above you,” and then lower, below the others, and said, “Never below you,” and then clinked the glasses at the same level, finishing with, “Always beside you.”

Apparently, the quote originated from Walter Winchell, reminding us that our place is often best, not in command or in servitude, but together, in unity. Might this be best in leadership as well?

I admit that I’ve never been entirely on board with the term “servant leadership” or the often stated sentiment in agile circles that managers need to “get out of the way.” Luckily, in most organizations I work with, teams understand that servant leadership is not meant to devalue the talents of the leaders, but rather to be in opposition to a traditional command-and-control style of leadership.

Servant leaders are taught to empower self-organized teams by trusting them with more decision-making responsibilities and to eliminate unnecessary micromanagement waste.

The term “servant leader” was originally coined in 1970 by Robert Greenleaf in his essay, “The Servant as Leader.” The idea is to “serve first” and in so doing, become a stronger leader. While certainly giving employees and teams more autonomy has been proven to lead to higher-performing teams, it seems that “host” leadership rather than “servant” leadership, would align more closely to the emphasis on teamwork focused in agile.

Pierluigi Pugliese, in the article, “I’m Not a Servant – I’m a Host! A New Metaphor for Leadership in Agile?” provides several examples of why “leader as host” seems to be a better description than “leader as a servant.”

Host leadership, a leadership style alternative developed by Marc McKergow and Helen Bailey, see the leader not as a hero nor a servant, but as a host who receives and entertains guests.

The host leadership model is described in the book, “Host: Six New Roles of Engagement for Teams, Organizations, Communities and Movements,” published in October 2014. The six roles: initiator, inviter, space creator, gatekeeper, connector and co-participator, can be played from four different positions: on the stage, among the people, on the balcony, and in the kitchen.

The combinations resulting from mixing role to each position result in 24 styles that might be used for leadership, depending on the context.

For example, the space creator role is used to create an environment, either physical or emotional. The on the stage position is used when the host leader is the center of attention. An example of the combination of the space creator + on the stage would be when a host leader explains the purpose of a meeting.

In my opinion, understanding and applying the complete host leadership model is not necessary to becoming an effective leader. My issue is not with servant leadership as it’s being applied in today’s world, but rather with the term “servant.”

I believe team members as well as servant leaders are all meant to both serve and lead, depending on the circumstance and context. Though servant leadership was a big step in the right direction as an agile leadership model, host leadership may be an even better model for developing strong teams.