PMI-ACP Exam Domain: Team Performance Part 1

1. Team Performance Section Overview

In this section we’re going to talk all about the project team. And specifically we’re going to talk about team performance. As the project manager, it’s your responsibility to be a servant leader. It’s your responsibility to keep the team motivated, but to keep giving the team the things that they knew that they need in order to reach their objectives. So in this section we’re going to look all about teams. And this is really an important part of having the agile mindset and being a servant leader. So in this section we’re going to look at self-directed teams about how teams are empowered to work collectively and make local decisions, how they can estimate and decide on the project work. And then sometimes teams make mistakes that we want teams to not necessarily fail, but if they fail, let’s fail fast and learn so fast and early, learn from those mistakes and keep moving forward.

That we want to encourage teams to be able to experiment and to learn new ways of doing the work, learn better ways to doing the work. So we have some different roles in the agile team that will talk about the development team or the delivery team, the business rep, the product owner, and then depending on what flavor of agile you’re working in, you might see the term of Scrum Master or coach. And so we’ll talk about those and what happens with each of those roles.

And then of course, we always have a project sponsor. Some characteristics of high performing teams will be discussed in this section. So we’ll talk again about creating a shared vision and why that’s so important, creating realistic goals for our team. What’s the team size, what should that be and why is that important? Building a team identity and then of course, someone on the team will provide strong leadership, not always the project manager. So we’ll talk about what’s leadership like in the team now throughout the project, the Scrum Master or the coach or the project manager that they’re going to need to provide some one on one coaching.

So what are the steps needed for that to happen and what are some general guidelines for coaching? Well, we’ll look at that in this section. It’s a very important topic that you’ll need to know for your exam. Colocated teams, of course, teams that are located all in one spot, those are preferred and you’re going to see some test questions about that idea. It’s a key principle and agile. So we’ll talk about how physically close team members should be. What about doors and what about this term called caves and commons? So you’ll need to know that for your exam.

So look for that in this section. Of course, when we talk about teams, we want to have some type of a team space that’s just for the project team. So keeping everyone in one location, whether you call it a war room or the headquarters or the team office, but it’s just a great way to easily communicate with the team, and the team can communicate with one another, and we can provide some information. Radiators and whiteboards and task boards, and it’s just where everything that deals with the project is located in that one spot. So that will be a theme that you see throughout this section as well. Okay. Good job. I know you’re moving forward. I know you’re learning. I know you’re excited about the course. Let’s keep going.

2. PMI-ACP Domain Overview: Team Performance

Team performance. This is another exam domain that I think you need to really pay attention to. It’s not a particularly large exam domain, but it really defines the roles and responsibilities that you’re likely to encounter on your exam. It’s 16% of the PMI AC P exam, so it’s 19 questions.

The main theme in this exam domain is about building high performing teams. So we’ll take a look at how the team is built and what you can do as an agile PM to ensure that that team is being a high performing team. So some exam tasks that you’ll face is develop team rules and processes to foster buy in. This is a collaborative activity. You want to help grow team interpersonal and technical skills. Use generalizing specialist. We’ll talk more about that coming up. Empower and encourage emergent leadership. Learn team motivators and demotivators. Continuing on, we have encouraged communication via colocation and in collaboration tools. Shield the team from distractions. Align the team by sharing project vision, anchor team to measure velocity for capacity and forecasting.

So those are all of our exam objectives. Let’s talk about the real theme here about developing and supporting self organizing team. Self organizing means that the team comes together and they decide who’s going to do what. They decide who will take on what activities and what task, based on their skill set, based on their interest, based on past experience. So tied to this, as well as the team is self empowered, they can make local decisions and local decisions means they make decisions about the work. In that iteration, the project team, they are stakeholders.

And then we have team leaders, scrum masters or coaches. So they’re involved as part of the team or they help the team like a scrum master or a coach. People over process is very important, that people are most important, people are more important and then processes are important. Focus on the people. And this is part of that idea of servant leadership. Now, a term you’ll see throughout this course and on your exam is this idea of a business rep. Well, a business rep interchangeable with the individual that’s the product owner or the customer, or a proxy customer, or a customer representative or someone from the value management team. So business reps are just the individual that they represent the customer and they’re responsible for.

Let’s look on the next slide. Prioritizing the product features, managing the product backlog, ensuring a shared understanding, providing the acceptance criteria, making change request. They may change the product features and priorities so they can’t have new additions to our backlog. They facilitate engagement of external project stakeholders. They provide due dates for the project and they attend planning, meeting reviews and retrospectives. The scrum master. And this is used interchangeably with the coach, team leader or project manager.

It’s a servant leader. They help the delivery team self govern and self organize. They’re a facilitator and a communicator. They coach and mentor to the delivery team. They provide agile processes. They help the product owner manage the product backlog. They help the product owner communicate, facilitate meetings and follow up on issues. And the last role that we need to address is the project sponsor. The project sponsor is the main advocate for the project. Provides directions to the product owner, determines value on time and on budget. They may attend our iteration review meetings, but they’re the individual that authorizes the project. All right, good job. Let’s keep going.

3. Adaptive Leadership

In this lecture, we’re going to discuss a very important concept for your PMI ACP exam that is building an agile team. Going to have quite a few questions about the team on your PMI ACP exam. Because so much of the exam and so much of agile project management is team focused, where it’s not what the project manager does.

Remember, the PM in an agile environment is more of a servant leader. So we’re focused on the team and team cohesion and development. Now, as a project manager, we can facilitate that development process, but some of it just happens naturally. Let’s hop in and look at the things we have to talk about with building an agile team. First off, an agile team characteristics. Ideally, we have twelve or fewer people on an agile project. Team members have complementary skills, meaning that they complement one another, that they balance one another, and they have some ying and yang, if you will, to the type of things that they bring to a project that not everyone is the same on your project team. Now, why they have complementary skills. They’re also generalizing specialists, meaning that they can usually play more than one role.

Because you want the team to not just be a silo, not just be a tester, not just be a developer, or to be a SQL database guru, whatever the case may be. You want these people to have some generalizing specialists where they can hop into different roles in the project as needed. Team members are committed to a common purpose, and that common purpose is project success. So team members hold themselves mutually accountable, meaning that everyone plays by the same rules and we hold each other to those rules. And that we are all in this together, that we are a team. And our goal is to finish this sprint, this iteration, this project. Team members also have a shared ownership for the project outcome, that it’s no one’s individual fault if the project is a failure or a success, that everyone contributes and everyone is accountable. There’s a shared ownership and really have that mindset as you go into pass your PMI ACP exam. So I mentioned a moment ago about the idea of a general specialist, just to be real clear on this, because I guarantee you, you’re going to see this on your test. Team members can have multiple roles and they can switch between these different roles. This helps to resolve bottlenecks.

So you can imagine if we have these silos, if that silo can’t do anything else but program, and that can really cause things to back up. But if that person can program, and they can also help write test scripts or actually do the testing, then they can do more than one thing. When there’s loles and programming, they can switch over and help with testing to keep things moving along in the project. So, what are some characteristics of high performing teams?

Well, we have a shared vision for the project team. We set realistic goals. Twelve or fewer people building a sense of team identity, that we’re all in this together and that we all contribute and we have a shared ownership of success and failure and we provide strong leadership. You may have heard me mention throughout the course this idea of emergent leadership where different people can lead at different times. There are also eight characteristics of high performance teams. Just a good mindset to have for your exam. Self organizing. They decide who does what work. They step forward and take on the challenges of each iteration or the whole project. They’re empowered. Project manager gets out of the way. They let the team make local decisions.

They believe that as a team they can solve any problem. They’re committed to team success. They own the decisions that they make and they keep their commitments. They’re motivated by trust among one another, but also with the product owner, the project manager, the end users. But the focus is on the team. What they can do as a unit. They’re consensus driven that when there’s an issue or a question or a problem, the team as a group makes a decision. They come to a consensus to move forward. They also participate in constructive disagreement that we know there are going to be conflicts. We know people aren’t always going to agree. But the team members have respect for one another and they have disagreements. So it’s constructive disagreements. Now we’ll talk about what happens if it’s not a constructive disagreement coming up and some different things to be on the lookout for as an agile PM, but also for your exam. I’ve mentioned self organizing teams a couple of times already, even in this lecture. Self organizing teams means that it’s not a PM led team. It’s not that command and control environment. They can use their own knowledge to organize the work. So you have a group of people, they look at what needs to be done. They think about weeks, think about strengths and weaknesses, I should say.

And they divide up the work and they challenge one another to get the work done on time and of quality within this iteration. So they structure the work based on the iteration, goals on priority, and then the responsibility to complete the work. It’s delegated to the team. It’s not the project manager, it’s the team’s responsibility to delegate the work amongst themselves and then to get that work done. Self directing teams is kind of that same idea that they’re empowered to work collectively. They make local decisions, meaning they’ll decide who does what, who manages what within the work of that iteration. They’ll also estimate and decide the project work. Yes, they’ll make mistakes and learn from mistakes. Remember that idea of failing fast and failing early and learning from our mistakes? Well, there you go. This is part of a theme that we’re going to see whenever it comes to Agile teams. Little exam tips.

Self-organizing and self-directing teams are goals of Agile projects. Teams usually do not start as self-organized and self-directed. So over time as they build trust and they get to know each other and they become more of a performing unit, then the teams can become self-organized and self-directed. So what you take away from this is early in the project you may have to step in and do some coaching and delegating and keep people moving on the project. Work late in the project. As the team has moved through team development, they’re more likely to be self-directed. Let’s nail down this concept of emergent leadership. Different people lead different initiatives, high performing teams, we have multiple leaders and there’s really no power struggle when leaders change roles. Let’s say you have emergent leadership, new leaders come in because we’re in different parts of the project and then the old leaders become more of a regular team member role. So leaders are self-selected, they’re not assigned. It’s not like someone says, okay, now you’re the leader. It’s a natural process of who is leading the team or leading the initiative or the area of the project, whatever the case may be. It’s a natural process that a leader emerges in that part of the project. Teams need to be able to experiment and fail safely, meaning that you encourage them to experiment, try new approaches and it’s okay to fail. We just learn from our failure, we learn what doesn’t work.

So an engagement culture rewards people for problem solving, collaboration and sharing ideas. This is what we want to strive to be in Agile. We want to be an engagement culture. So people try new approaches. If they’re punished for failing, they’re going to be more hesitant to try new approaches in the future. You want to encourage people now on teams, you get people together. There’s just a natural process where there’s going to be some disagreement. So debate and conflict is actually natural and to some extent it’s healthy because it ensures that we get better decisions that we get buy in from the whole team. Divergence means the team will argue and debate. Convergence means there may be some debate but they eventually will agree on the best solution. So divergent is the team splinters apart, they don’t come back together.

Convergence means yes, there may be some debate, but it’s healthy, it’s constructive and we’re going to come back together and agree on a good solution for the project. Five dysfunctions of a team. Five things that we want to look out for in Agile projects absence of trust, fear of conflict, lack of commitment, avoidance of accountability, inattention to results. So if we have these things happening in our team, then we may need to facilitate some team building exercises or to look for opportunities to coach and bring people together. We have to be careful not to interject with the natural process of team development. But obviously, if we have fear of conflict and absence of trust, lack of commitment and so on, then we’re going to have some problems in the project as a whole. Generally you see these early in the project, especially with a group of people who have never worked together. And then over time, they begin to have trust. They begin to understand how one another works and we move through some phases of team development. Now, in Agile, it’s tempting to hop right in and begin doing Process Tailoring, where we’re going to take a process and the team decides, yes we will, no we won’t. And they start twisting and changing and just doing whatever they feel is appropriate, even if they’ve not worked in Agile before. So earlier we said, well, with Process Tailoring, that’s okay to do, but you have to walk before you can run. So you have to have some experience to know what rules can change. So there’s a thought process tied to this. It’s called Shoe Hair, the model of skill mastery.

What this means is we have three different layers here. Shoe obeying the rules to keep, protect or maintain. So if you’re really new to something, like if you’re really new to golf, you might obey the rules. Well, I hope you would obey the rules and the approach and how you hit the golf ball. Well, the same thing is true if you’re new to Agile, that you should obey the rules and keep and protect or maintain. As you become more experienced, you conscientiously move away from the rules. So ha means to detach or break free. Let’s go back to the golf analogy. So if you’re just learning golf, you might hit the golf ball the same way every time, or try to hit it the same way every time. As you become more and more experienced and you kind of master your swing, you might make some minor adjustments, like you want to draw or fade the golf ball, depending on what hazards are in the way in the course.

So that’s the same idea here. As you become more experienced than Agile, your team becomes more experienced. Then they can begin to move away from the rules and make adjustments and then re. Is that when you become such a proficient golfer or such a proficient team in Agile that you unconsciously find your own way? So re means to go beyond or to transcend to the rules. So shooha re shu. Start by following the rules. Ha. Once the team has mastered the guidelines, you can move away from them and they work intuitively. And then re is where the team reaches full mastery and they can transcend the rules. So they’re very experienced. I guarantee you, you’re going to see that on your exam. You’ll also need to know this Dreyfus model of adult skill acquisition. Just a way of saying, what are the stages that we move through as we begin to learn a new skill. So think about your project team as we talk about these. We have the novice, you follow the rules and then you make analytical decisions that adhere to the rules. Advanced beginner.

You’re still following the rules but based on experience you better understand the context of the rules. Competent determining which rules are best for each situation, proficient, actively choosing the best strategy rather than simply relying on the rules. And then finally we have expert decision making becomes more intuitive. So we have novice, advanced beginner, competent, proficient and then finally an expert. So I would be topically familiar with that just, it’s a pretty logical progress but know those for your exam, how you go from novice all the way to expert. The Tuckman model of team formation development is something you’ve probably have seen on your CAPM or PMP exam and you’re also going to see it on your PMI ACP exam. So you want to be familiar with this logical progress of how a group of people becomes a team. So we have forming the team comes together and they learn about each other. Also known as a working group. Storming is where you have that natural conflict and struggle. So how are we going to accomplish the iteration? What’s the approach?

Who’s really the leader? This is also known as a pseudo team norming is where we have that convergence. The team works with each other and conflict settles down. This is known as a potential team. Finally we have performing where now the team hits their stride. They’re known as a real team and they’re on their way to becoming a high performing team. There is a fifth stage here that it’s pretty easy. It’s a journey. I didn’t include it because it’s not an official part of the Tuckman model. But a journey means the project is over and the team disbands and we’re done. They go on their way for your exam. I would know forming Storming norming and performing and then also know the idea of a working group forming pseudo team Storming, potential team norming and then a real team is performing.

4. PMI-ACP Exam Domain: Team Performance

In this lecture, we’re going to discuss a very important concept for your PMI ACP exam that is building an agile team. Going to have quite a few questions about the team on your PMIA ACP exam. Because so much of the exam and so much of agile project management is team focused, where it’s not what the project manager does. Remember, the PM in an agile environment is more of a servant leader. So we’re focused on the team and team cohesion and development.

Now, as a project manager, we can facilitate that development process, but some of it just happens naturally. Let’s hop in and look at the things we have to talk about with building an agile team. First off, an agile team characteristics. Ideally, we have twelve or fewer people on an agile project. Team members have complementary skills, meaning that they complement one another, that they balance one another, and they have some ying and yang, if you will, to the type of things that they bring to a project that not everyone is the same on your project team. Now, why they have complementary skills. They’re also generalizing specialists, meaning that they can usually play more than one role. Because you want the team to not just be a silo, not just be a tester, not just be a developer, or to be a SQL database guru, whatever the case may be.

You want these people to have some generalizing specialists where they can hop into different roles in the project as needed. Team members are committed to a common purpose, and that common purpose is project success. So team members hold themselves mutually accountable, meaning that everyone plays by the same rules and we hold each other to those rules. And that we are all in this together, that we are a team. And our goal is to finish this sprint, this iteration, this project. Team members also have a shared ownership for the project outcome, that it’s no one’s individual fault if the project is a failure or a success, that everyone contributes and everyone is accountable. There’s a shared ownership and really have that mindset as you go into pass your PMI ACP exam. So I mentioned a moment ago about the idea of a general specialist, just to be real clear on this, because I guarantee you, you’re going to see this on your test. Team members can have multiple roles and they can switch between these different roles. This helps to resolve bottlenecks. So you can imagine if we have these silos, if that silo can’t do anything else but program, and that can really cause things to back up.

But if that person can program, and they can also help write test scripts or actually do the testing, then they can do more than one thing. When there’s loles and programming, they can switch over and help with testing to keep things moving along in the project. So, what are some characteristics of high performing teams? Well, we have a shared vision for the project team. We set realistic goals. Twelve or fewer people building a sense of team identity, that we’re all in this together and that we all contribute and we have a shared ownership of success and failure and we provide strong leadership. You may have heard me mention throughout the course this idea of emergent leadership where different people can lead at different times. There are also eight characteristics of high performance teams. Just a good mindset to have for your exam. Self-organizing. They decide who does what work.

They step forward and take on the challenges of each iteration or the whole project. They’re empowered. The project manager gets out of the way. They let the team make local decisions. They believe that as a team they can solve any problem. They’re committed to team success. They own the decisions that they make and they keep their commitments. They’re motivated by trust among one another, but also with the product owner, the project manager, the end users. But the focus is on the team. What they can do as a unit.

They’re consensus driven that when there’s an issue or a question or a problem, the team as a group makes a decision. They come to a consensus to move forward. They also participate in constructive disagreement that we know there are going to be conflicts. We know people aren’t always going to agree. But the team members have respect for one another and they have disagreements. So it’s constructive disagreements. Now we’ll talk about what happens if it’s not a constructive disagreement coming up and some different things to be on the lookout for as an agile PM, but also for your exam. I’ve mentioned self-organizing teams a couple of times already, even in this lecture.

Self-organizing teams means that it’s not a PM led team. It’s not that command and control environment. They can use their own knowledge to organize the work. So you have a group of people, they look at what needs to be done. They think about weeks, think about strengths and weaknesses, I should say. And they divide up the work and they challenge one another to get the work done on time and of quality and within this iteration. So they structure the work based on the iteration, goals and priority and then the responsibility to complete the work. It’s delegated to the team. It’s not the project manager, it’s the team’s responsibility to delegate the work amongst themselves and then to get that work done. Self-directing teams is kind of that same idea that they’re empowered to work collectively. They make local decisions, meaning they’ll decide who does what, who manages what. Within the work of that iteration.

They’ll also estimate and decide the project work. Yes, they’ll make mistakes and learn from mistakes. Remember that idea of failing fast and failing early and learning from our mistakes? Well, there you go. This is part of the theme that we’re going to see whenever it comes to Agile teams. Little exam tips. Self-organizing and self-directing teams are goals of Agile projects. Teams usually do not start as self-organized and self-directed. So over time as they build trust and they get to know each other and they become more of a performing unit, then the teams can become self-organized and self-directed. So what you take away from this is early in the project you may have to step in and do some coaching and delegating and keep people moving on the project, work late in the project. As the team has moved through team development, they’re more likely to be self-directed. Let’s nail down this concept of emergent leadership. Different people lead different initiatives, high performing teams. We have multiple leaders and there’s really no power struggle when leaders change roles. Let’s say you have emergent leadership, new leaders come in because we’re in different parts of the project and then the old leaders become more of a regular team member role. So leaders are self-selected, they’re not assigned. It’s not like someone says, okay, now you’re the leader. It’s a natural process of who is leading the team or leading the initiative or the area of the project, whatever the case may be. It’s a natural process that a leader emerges in that part of the project. Teams need to be able to experiment and fail safely, meaning that you encourage them to experiment and try new approaches and it’s okay to fail.

We just learn from our failure, we learn what doesn’t work. So an engagement culture rewards people for problem solving, collaboration and sharing ideas. This is what we want to strive to be in Agile. We want to be an engagement culture. So people try new approaches. If they’re punished for failing, they’re going to be more hesitant to try new approaches in the future. You want to encourage people now on teams, you get people together. There’s just a natural process where there’s going to be some disagreement. So debate and conflict is actually natural and to some extent it’s healthy because it ensures that we get better decisions and that we get buy in from the whole team.

Divergence means the team will argue and debate. Convergence means there may be some debate, but they eventually will agree on the best solution. So divergent is the team splinters apart, they don’t come back together. Convergence means yes, there may be some debate, but it’s healthy, it’s constructive and we’re going to come back together and agree on a good solution for the project. Five dysfunctions of a team. Five things that we want to look out for in Agile projects absence of trust, fear of conflict, lack of commitment, avoidance of accountability, inattention to results. So if we have these things happening in our team, then we may need to facilitate some team building exercises or to look for opportunities to coach and bring people together.

We have to be careful not to interject with a natural process of team development. But obviously if we have fear of conflict and absence of trust, lack of commitment and so on, then we’re, we’re going to have some problems in the project as a whole. Generally you see these early in the project, especially with a group of people who have never worked together. And then over time they begin to have trust. They begin to understand how one another works and we move through some phases of team development.

Now in Agile, it’s tempting to hop right in and begin doing Process Tailoring, where we’re going to take a process and the team decides, yes we will, no we won’t. They start twisting and changing and just doing whatever they feel is appropriate, even if they’ve not worked in Agile before. So earlier we said, well, with Process Tailoring that’s okay to do, but you have to walk before you can run. So you have to have some experience to know what rules can change. So there’s a thought process tied to this. It’s called Shoe Hair, the model of skill mastery. What this means is we have three different layers here. Shoe obeying the rules to keep, protect or maintain. So if you’re really new to something, like if you’re really new to golf, you might obey the rules. Well, I hope you would obey the rules and the approach and how you hit the golf ball. Well, the same thing is true if you’re new to Agile, that you should obey the rules and keep and protect or maintain.

As you become more experienced, you conscientiously move away from the rules. So ha means to detach or break free. Let’s go back to the golf analogy. So if you’re just learning golf, you might hit the golf ball the same way every time, or try to hit it the same way every time. As you become more and more experienced and you kind of master your swing, you might make some minor adjustments, like you want to draw or fade the golf ball, depending on what hazards are in the way in the course. So that’s the same idea here.

As you become more experienced than Agile, your team becomes more experienced. Then they can begin to move away from the rules and make adjustments and then re. Is that when you become such a proficient golfer or such a proficient team and Agile, that you unconsciously find your own way? So re means to go beyond or to transcend to the rules. So shooha re shu start by following the rules ha. Once the team has mastered the guidelines, you can move away from them and they work intuitively. And then re is where the team reaches full mastery and they can transcend the rules. So they’re very experienced. Guarantee you you’re going to see that on your exam.

You’ll also need to know this Dreyfus model of adult skill acquisition. Just a way of saying what are the stages that we move through as we begin to learn a new skill. So think about your project team as we talk about these we have the novice, you follow the rules and then you make analytical decisions that adhere to the rules. Advanced beginner.

You’re still following the rules, but based on experience, you better understand the context of the rules competent determining which rules are best for each situation proficient actively choosing the best strategy rather than simply relying on the rules and then finally we have expert decision making becomes more intuitive. So we have novice, advanced beginner, competent, proficient and then finally an expert. So I would be topically familiar with that just it’s a pretty logical progress but know those for your exam how you go from novice all the way to expert. The Tuckman model of team formation development is something you’ve probably have seen on your CAPM or PMP exam and you’re also going to see it on your PMI ACP exam.

So you want to be familiar with this logical progress of how a group of people becomes a team. So we have forming the team comes together and they learn about each other also known as a working group. Storming is where you have that natural conflict and struggle. So how are we going to accomplish the iteration? What’s the approach? Who’s really the leader? This is also known as a pseudo team norming is where we have that convergence. The team works with each other and conflict settles down. This is known as a potential team. Finally we have performing where now the team hits their stride. They’re known as a real team and they’re on their way to becoming a high performing team. There is a fifth stage here that it’s pretty easy. It’s a journey. I didn’t include it because it’s not an official part of the Tuckman model but a journey means the project is over and the team disbands and we’re done. They go on their way for your exam. I would know forming Storming norming and performing and then also know the idea of a working group forming pseudo team Storming, potential team norming and then a real team is performing you.