PMI-ACP Exam Domain: Team Performance Part 2

5. Creating a Collaborative Team Space

An important concept for your PMI ACP exam is building or creating a collaborative team space. So you want to be familiar with the concepts that we talk about in this lecture about creating a team space that’s just for your project team. In an agile environment, colocated teams are preferred. So we want people to all work in one location. We have that face-to-face communication. It’s easier to share information now when we have a colocated team. Ideally it’s within 33ft of one another or 10 meters of one another. We don’t have any physical barriers like walls or doorways.

It’s kind of that big open room concept that maybe you’ve seen in some of the Silicon Valley or tech startups where it’s just one big open room and it’s easy to share information and communicate with each other. Distributive teams use collaborative software. So if you can’t be colocated, then you might take advantage of some type of a collaboration software like Microsoft Link or something to that end, where it’s easy to check in, check out, and have chats and video conferences and little text messages and you can look at a glance to see what everybody’s doing or if they’re available or so on. So remember that for your exam. Distributive teams means non colocated. We use collaborative software. Creating a team space is important because it gives the team members, well, one a place to meet and all be together and know that all these people we can look to see who’s here, who’s working. It’s a sense of accountability to one another. It’s a location for team members in the same space.

Now sometimes you might see this called the war room. So everyone’s there working on the project in the war room, visible information radiators. So for project metrics, so you have lots of information radiators, burn up, burn down charts. You have work in progress, maybe a can band board, percent completes. So visible information radiators are good. In this team space you also need lots of whiteboards and task boards.

So it’s easy to share information and to go right on the whiteboard. And remember you can do like a roadmap or a story map and then take a picture of it with your phone so you can share it with other people. Really important concept for your exam caves and commons. All right, this is a really easy concept. So you’ve got this big open environment for your collaborative team, your colocated team. Well, that big open environment is called the common, the common area where everybody works. And then you might have some little breakout rooms or real small little offices. I’ve even seen some places they have old phone booths. But those are private spaces and those are called caves.

So you have caves in commons. So you go to a cave with one or two people and you hammer out some details or you need some quiet time to think. You go to the cave commons where everybody works. It’s the big wide open space. So caves and commons. Tacit knowledge. This is that unwritten information that’s collectively known by the group. Like what drive is a resource on how do you restart the server, how do you turn on the lights in the morning? Larger groups though, they have more difficult picking up on this because they’re generally dispersed or they’re really big and they don’t pick up on all the nuances.

So tacit knowledge is just the things that you pick up on by being a part of the team. Now very similar is Osmotic communication. Notice it’s communication, not knowledge. So Osmotic communication is basically you hear what other people say and then that helps you do your job. So you hear someone say, okay, whenever you go to do integration you have to hit F eight or whatever. So when you go to do integration you hit F eight. So you kind of pick up on what that does.

So it’s benefits of being a colocated team. If we are a distributed team, it’s a little tougher to hear other people’s conversations, right? Every conversation is planned for the most part when you are a noncolocated team, when you’re distributed. So what about these distributed teams or virtual teams or non colocated teams? There are some things that we have to consider. We have to consider different time zones where people are located physically. What about different cultures and holidays and things like that if we’re on an international team.

Different communication styles so people communicate differently all around the world. And then also what about language barriers, so different native languages, how do we overcome that challenge? So these are all things you want to take into consideration when we think about virtual teams. So managing a distributed team, distributed teams, like I mentioned, they’re virtual teams, short iterations, they help collaborations in coordination. So rather than having a sprint that’s going to last for four weeks, maybe you do one week or two week. So it’s easier to communicate and it’s more focused on shorter iterations than longer where people can fade away and hide. Apparently in a virtual team environment. Now distributed teams, it’s not the same thing as outsourcing. This doesn’t mean you just go hire some contractors. We’re talking about individuals that are part of your team, they’re working in your team. But we live in different geographical locations.

Distributed teams often face more challenges in Storming and Norming because we’re not in the same room and we’re far apart, it’s a little tougher to work through Storming. We might have a conflict but then I can end the call, hang up and then go vent. If we’re all in the same room comes a little bit more awkward. People have a tendency to be a little bit more open face to face or a little bit more willing to bend face to face than what we might have in a virtual team.

So sometimes what we may need to do, especially in Storming and Norming as the project manager, is to facilitate that early in the project. Bring in controversial topics or some difficulties early in the project, assuming that they’re of priority. But the idea would be that it facilitates, it gets people going on the idea of Storming so we can get to Norming and overcome that hurdle. We don’t want to just kind of plot along and then get to Storming late in the project and have problems. We want the project team to have an opportunity to Storm but then to settle down and go through Norming to get to performing at a longer duration in the project. We want a long tail on that project to have the opportunity, experience performing a good cohesion among the team.

And so another way to do this is to do a face to face kickoff to bring everyone together so we can meet one another face to face and understand where you’re coming from and we have an individual to put to the voice. So face to face kickoff is a good idea. With Distributed Teams exam tip use a frequent communication intensified facilitation like we were talking about a moment ago with Storming and Norming. Use best practices for conference calls, keep on track, keep on time, know who is on the call and get them involved. Facilitate that phone call, keep the answers coming. So keep people involved and contributing. Don’t let one person hog the conversation.

So keep it fair and then also keep it documented. If people make a promise to do something, let’s write it down and follow up with a distributed team. There are some tools that we can use to help manage this. Distributed team video conferencing an interactive whiteboard course, instant messaging, presence based applications like Microsoft Link.

I’ve mentioned a couple of times, if you’re not familiar with this, it’s basically like a chat program that shows all the people on your team and then they can change their status to what they’re working on or if they’re available or so on. Electronic tasks for Storyboards web based meeting Facilitators so just like having a meeting but you have a facilitator online that keeps people involved and keeps the agenda and keeps things moving along, you might have a virtual card wall instead of having a backlog made up of sticky notes.

You might do it through a website or a piece of software. You might also have a wiki site that provides some communication for the team and picks up on some of that tacit knowledge and Osmotic communication and shares it online. Now, the problem with all these that we are drifting away from the idea of low tech, high touch tools, all of these for the most part are high tech tools so that may create some challenges. But there are pros and cons to having a distributed team.

6. Tracking Team Performance in an Agile Project

In any project, predictive, waterfall, agile, XP, Scrum, any flavor that you want. We want to track team performance because it tells us two things. It lets us know where are we right now? Always a good thing to know. And then it’ll allows us to do some predictions of where are we likely to end up. Now, one approach that we can do and that you need to know for your exam is using a burn down chart.

So a burn down chart, what it shows is it tracks the work that remains to be done on the project. So it measures the team progress and how quickly they’re completing the project work. So here’s what’s happening in this burn down chart. So across the bottom we have the different sprints or iterations and then the number of points, total points to do this project. If you recall that we assign point values to features and user stories and then we say how many points can we do per iteration? So in this example here we have our estimated burn down. So from 30 points, our goal is to come all the way down to zero.

So from 30 points to zero, this is our estimated here in blue, how many we predict that we can do each iteration and then what was in red is what we actually accomplished. So you can see early on in the project, it kind of our velocity here. Our throughput, especially these first three iterations was pretty sluggish. We weren’t hitting our predicted burn down. What was in blue, you can see the reds above it. We should be lower, we should be hitting that blue line. But then we start being a good team and things start going in our way and we begin to figure things out. And you can see that we eventually catch up. Here in about the fifth iteration or 6th iteration, we catch up with what was predicted. And you can also see we’ve talked a little bit about our velocity, that our velocity begins to go up, that we are able to have a faster throughput or put more points through an iteration.

So that’s this yellow line is what’s our velocity, how quickly can we manage and do the work in progress our width? So let’s get back to our red line here. So it’s pretty exciting about the 7th iteration. We catch up and then look what happens in eight and nine is we surpass what was our estimated burn down. Now of course this isn’t going to happen every time. This is just an example of a burned down chart that our goal is to go from the total number of story points to zero and to track that at each iteration, how many story points did we get done and how many are left in the project? Now a burn up chart, it’s very similar. I kind of like the burn up chart more. But know both for your exam all right here’s what’s happening in a burn up chart. Again across the bottom we could have each one of these tick marks could be an iteration and then going up the left hand side are the number of story points that we have to get done the red line. Each iteration we measure how are we accomplishing the number of points per iteration. So iteration one looks like we did about 20. Iteration two maybe we got up to 50 and so on that it’s kind of a stack of each iteration allows us to move that line upward. Our goal being to hit this line, this dashed line originally that we had 200 points to knock out. Now notice what happened here though.

We have this dash line says it was our original target and then we have this solid black line that now says it’s the target. What do you suppose that is? Well the reason why is because the scope changed. The customer added things to scope which created more story points. So a burnt up chart gives us insight into the overall project status that we have more points now, more features and user stories to create. So it’s going to require more time in order to hit that new target. So we are moving up to our new target. This was our original was 200 but because of the changes you can see there’s lots of changes. All these upticks represent a change here on our original target. So that is a burn up chart and the reason why I said I like a burn up chart more is because it reflects the change to scope.

It reflects there’s additional work now above what was originally agreed on. If we go back and look at the burn down chart, we don’t really know if there’s been changes or not. So the burn down chart is good to use if you have a consistency. If you know they’re not going to be any additional changes here, let’s be realistic, it’s agile, changes are welcome. There will be changes, there will be additions. So anyway, our burnup chart just the opposite. It shows that know both of these. For your exam I’ve mentioned team Velocity and you probably have picked up on this that team Velocity is the team’s capacity for work for each iteration. So it’s measured in the same unit that the team estimates the work. So if we go back and look at our burn down these are points, these are points for the user story or stories and we’ll talk a little bit more about this coming up.

But so if we say okay, we can do ten points per iteration, we can do 50 points per iteration. It says how many user stories in the priority in the backlog equate to 50 points. That’s how we pull that into the current iteration or to the current sprint. So velocity very early on it’s going to be pretty unstable but over time it stabilizes. At some point, velocity tends to plateau, that you hit your target of number points that you can do per iteration. And you probably aren’t going to get better, probably aren’t going to get worse. It’s going to flatline your plateau. And that’s okay. That’s a good thing because now we have stability.

So based on velocity, you can predict when the project will be done, right? Now, pay attention to this. Know this for your exam. So if the team’s velocity has been 20 story points for iteration, and we have 200 story points left, and each iteration is going to last for two weeks, we can make a prediction of how long the remainder of the project will be based on past performance. So we say, all right, there are 200 story points left, and we divide by 20 story points per iteration. So 200 divided by 20 is ten iterations, right? Because we can do 20 per iteration. So 20 divided by 200, it is ten iterations. Each iteration is two weeks long. So ten times two is 20. So we can predict there will be 20 weeks left in the project if everything remains the same, if our velocity remains the same and our target doesn’t change. Know that little formula for your exam.

7. Team Performance Section Wrap

Great job finishing this section on team performance. Let’s take a look at this section wrap on team performance. We talked about roles in agile teams. Recall, we talked about the development team or the delivery team, the different business reps for the product owner, the role of the Scrum Master, the coach or the project manager, basically for your exam. But the Scrum master or the coach and the project sponsor. What are the different roles and responsibilities? Well, that’s what we just talked about. We do have some characteristics of high performing teams that you should know. For the exam, the team needs a shared vision for the project and that’s what they look to you to do. Set realistic goals. Ideally, the team is twelve people or fewer.

Build a sense of team identity and provide strong leadership and notice that can come internally. It doesn’t have to come from the project manager. Remember, the idea of emergent leadership self directing teams is another thing we talked about in this section, where they’re empowered to work collectively. The team can make local decisions, basically about the project work and the order that work and how they will organize themselves, that they’re empowered, estimate and decide the project work and then make mistakes and learn from the mistakes. That’s a theme we’ve seen a lot. Feeling safe to experiment, safe to make mistakes.

If that happens, we want to create a team space or some type of a location for team members that they can all be colocated. You might know this as the war room. Within this war room or the project headquarters, you have visible information radiators for project metrics. So lots of whiteboards and task boards where they can quickly see information and they can write information and share information on these different whiteboards or task boards.

Two types of charts that you need to know. Very related that we talked about. In this section, we have a burned down chart where we track the number of items to be done until project completion. So we’re burning down. And then of course, the inverse of that, we have the burn up chart where it tracks the work that has been completed. The burn up chart, remember, shows changes in the project. So if the scope changes, we have more items to do. So it’s a little bit more honest than just a burn down chart. All right, good job finishing this section. A lot of important information and I’m really happy for you that you’re moving forward in the course. Let’s keep going. You’re almost to the end. You’re almost earning that certification. You.