THE FOLLOWING PMI-ACP^® EXAM TOPICS ARE COVERED IN THIS CHAPTER:

 Domain IV: Team Performance

Team Formation:

• Task 1: Cooperate with the other team members to devise ground rules and internal processes in order to foster team coherence and strengthen team members’ commitment to shared outcomes.
• Task 2: Help create a team that has the interpersonal and technical skills needed to achieve all known project objectives in order to create business value with minimal delay.

Team Empowerment:

• Task 3: Encourage team members to become generalizing specialists in order to reduce team size and bottlenecks, and to create a high-performing cross-functional team.
• Task 4: Contribute to self-organizing the work by empowering others and encouraging emerging leadership in order to produce effective solutions and manage complexity.
• Task 5: Continuously discover team and personal motivators and demotivators in order to ensure that team morale is high and team members are motivated and productive throughout the project.

Team Collaboration and Commitment:

• Task 6: Facilitate close communication within the team and with appropriate external stakeholders through colocation or the use of collaboration tools in order to reduce miscommunication and rework.
• Task 7: Reduce distractions in order to establish a predictable outcome and optimize the value delivered.
• Task 8: Participate in aligning project and team goals by sharing project vision in order to ensure the team understands how their objectives fit into the overall goals of the project.
• Task 9: Encourage the team to measure its velocity by tracking and measuring actual performance in previous iterations or releases in order for members to gain a better understanding of their capacity and create more accurate forecasts.

 In this chapter, you will finish the tasks found in Domain IV: Team Performance. These tasks in directly relate to the Agile development team and how to help drive skill mastery and determine how the team is performing. The tasks in the content outline include building a collaborative working environment, encouraging transparent communication, and tracking velocity as well as creating visual charts. This is all designed to give you a well-rounded idea of how to review your team’s performance and to help guide the team to Agile mastery. It includes elements of knowledge sharing, adaptive leadership, and communication techniques that will carry over to all aspects of your Agile projects.

Tuckman’s Ladder

In Chapter 5, “The Human Side of Agile Project Management,” you reviewed a lot of information on interpersonal skills and adaptive leadership, including Tuckman’s Ladder, which is the theory by which one can identify the team’s progression from a newly formed team to one that is considered performing. It is relevant to mention it again at the beginning of this chapter on team performance because the goal is to have a team that is high performing, self-directed, and self-managed.

No team ever begins as a performing team, especially those that have never worked together before. I would imagine that any organization that is trying to implement Agile approaches at any level has team members who may have worked together on other projects or have chatted in the break room. It may seem like a best bet to place those people together and call it a development team and have lofty expectations of exceptional performance right out of the gate. That simply isn’t the case.

In 1965, Dr. Bruce Tuckman published the forming, storming, norming, and performing model, which describes the stages of team development. In line with his research and thought processes, Tuckman believed his model demonstrated that all of these phases are necessary and inevitable regardless of the type of team, type of work, or type of industry.

In 1977, Tuckman revised the original sequence with then doctoral student and now psychologist Mary Ann Jensen. Their work together added adjourning (or what some refer to as mourning) as the final stage. This additional stage expresses the feelings of loss at the end of a team dynamic or the loss of a team member from the group.

In order to develop a high-performing team, it is important for the manager to understand the stages and be cognizant of their role in getting a team from forming to performing. It’s also important to mention that this sequence happens regardless of skill set. You could have high-performing individuals who, when put onto a new team, will still go through the process of forming and then eventually reach the performing stage.

Agile project managers practice servant leadership rather than management, and in the case of a newly formed team, it would be your job to maintain the vision, lead by example, and realize that your team may be a bit more dependent on you in the forming stage. During storming, you will guide your team through conflict resolution and promote collaboration and transparent communication. During norming, it is appropriate to function in a supportive role or that of a coach, unless the team or an individual asks for help. When the team is performing, they have reached the ability to be self-directed and self-managed, and that is the goal.

Shu Ha Ri and Skill Mastery

In the late 1920s and early 1930s, the martial arts were given a new or more modern way to practice. Rather than simply beating your opponent, you would now also attempt to use your movements to protect your opponent from harm. The Aikido practice of martial arts was developed in Japan based on several years of martial art studies. Added to this was a mix of philosophy and religious beliefs of the Aikido creator Morehei Ueshiba. The entire premise was to have the skill set both to defend and to protect: Defend oneself and protect the attacker from harm.

As with any type of martial art or mastery of a given craft, it takes many years to reach the pinnacle of what could be considered expert or master. What does that have to do with Agile, you may be thinking? Agile is easy to talk about but very hard to do. A practitioner of Agile will have to work and learn to master their craft.

Martial arts also influenced Agile in the sense that anyone learning something new would be a follower of the rules as they learn them, and then, over time, they would become more comfortable with their skill sets and branch out a bit or break some rules for the good of the outcome. It is assumed that within that consistent practice and learning, eventually the individual would reach mastery. Therefore, Shu Ha Ri and skill mastery became a part of Agile.

As a contributor to the Manifesto for Agile Software Development and the Declaration of Interdependence and the creator of the Crystal Method approach to Agile projects, Alistair Cockburn also incorporated the concept of Shu Ha Ri into Agile environments.

Loosely translated. Shu is to protect or obey, Ha is to detach or digress, and Ri is to leave or separate. When the same philosophy is applied to adopting Agile frameworks, there is a learning curve that follows the same patterns when applied to learning new skills.

At its highest level, Shu Ha Ri describes the progression of learning both in martial arts and in Agile frameworks. At the Shu level, when learning something new, the student follows the master and their practices precisely to learn the skills needed to perform the tasks. In our case, the Agile project manager would be guiding the development team in the ways of the chosen Agile framework.

No such thing as bad student, only bad teacher. Teacher say, student do.

Mr. Miyagi from The Karate Kid

At the Ha level, the student uses their new skills and applies their own innovation or way of doing things—still not breaking rules, but detaching from the way they were strictly taught to reach mastery.

Ri is about allowing yourself to become as creative as seems appropriate to you personally but still not breaking the rules or laws. It allows us first to follow the rules but work toward gaining mastery that resonates with our way of doing things and without losing the framework with which we started.

In a lot of ways, this explains Agile project management in its entirety. The frameworks are more flexible than traditional project management, and there is room to grow and be creative in our execution of work. Knowledge work is not tangible, and it is a lot more of an art form than a best practice. Therefore, as teams new to Agile work to implement best practices, they look to frameworks like Scrum to provide the timeboxes and solid foundation so that they can learn.

Once we have learned, we can begin to work with our teams to branch out a bit and find a groove that works for us while still following the framework and rules. This can include a variety of tailored approaches to Agile project management. Once the team has reached the performing stage, it has also reached mastery, or the Ri Level. It is suggested that an Agile team reach mastery before trying to adapt the frameworks. However, I disagree. I think part of learning is attempting to gain mastery while still knowing and understanding your own organizational dynamics. What works for one may not work for another. In Chapter 10, “Tailoring Quality Management and Improving Project Processes,” I’ll go through some tailoring approaches and other frameworks that have been adapted as their creators addressed their Ri and their organization.

Dreyfus Model: Five Stages of Skill Acquisition

Throughout the last 40 years or so, there have been many studies of human behavior and skill acquisition. While those studies have been done for a variety of reasons and recipients over the years, it is easy to see a trend of how humans learn and the stages necessary to achieve skill mastery.

In 1980, Stuart and Hubert Dreyfus published a report about skill acquisition based on their research at the University of California, Berkeley. The Dreyfus Model was designed to show how people learn necessary skills through formal instruction and by regularly practicing what they have learned. While the model is self-explanatory, it is an excellent overview of what teams new to Agile frameworks will experience and to what level an Agile project manager needs to get involved.

The goal on any Agile team is to have a self-directed and self-managed team, but that takes time and coaching. In Figure 7.1, the Dreyfus Model is represented by some ideas for how to guide your team to self-direction and become an expert-level practitioner of Agile frameworks.

Many of these models are a lot like Agile, easy to talk about but hard to implement. It’s always a good idea to ask yourself where you fall on the model with regard to Agile practices as well as where your team of individuals fall on the scale. That identification can help you with coaching your team through a challenge or new learning environment either now or in the future.

Collaborative Working Environments

Speaking of perfect world project management, a collaborative working environment for Agile teams is recommended as the best way to manage your projects. Since Agile frameworks are best in an environment of colocated team members, the way the team space is created, or “tooled,” allows for the best interactivity and collaboration.

For the best setup of your colocated space, it is key to remember that Agile teams tend to be smaller in size. In fact, the optimal team size is about 12 people. If you have more or fewer people on your team, that’s okay, because many of the tailored approaches you’ll review in Chapter 10, “Tailoring Quality Management and Improving Project Processes,” address how to work with best practices on a large or enterprise-sized project. For exam purposes, though, we’ll stick to the thought process that everyone could practice perfectly if you have no more than 12 people working on a project.

Above and beyond the size of the team, the rest of the team space is designed for a high amount of collaboration for several specific reasons, as described here:

Shared Vision When the team sits together, it allows for free-flowing osmotic communication and a shared environment. Because of this, all of the team members are more likely to hear the same message from the Agile project manager, whose job it is to continue to perpetuate the vision for the project and the increment. Even though the scope of work will change the result, the focus of the team will remain on point.

Realistic Goal Setting Because the team is self-directed and self-managed, it is the team who will determine their goals for the iteration. The team selects the work, which will determine velocity. Limiting work in progress (WIP) allows for realistic goal setting. Having retrospectives at the end of the iteration for continuous improvement and a refocus on the goal of the next iteration also allows for goal setting to remain in the realm of realism.

Self-Organized The team’s ability to select prioritized work and then organize around it is a key tenet in all Agile frameworks. Unless you are using a tailored approach that is closer to a Waterfall methodology or framework, it is highly likely that the team will chart their own course through the iterations. The team will also self-adjust if the primary direction didn’t work effectively.

Empowered Much as with self-organization, the team is empowered to make decisions and to determine their work in progress (WIP) as well as to be creative and make mistakes. Mistakes are how the team learns, and with that information the team is empowered to adjust, reset, and reach consensus. The product owner is in charge of the backlog, but the team is empowered to determine what will be accomplished from iteration to iteration.

Consensus Driven The Agile project team doesn’t have a hierarchy as you might see in some more projectized organizations with a bigger focus on protocol and traditional project management best practices. The team works together with the same focus on the vision, and therefore they must agree together how to move forward. Reaching consensus may be a bit time consuming, especially in the beginning with a newly formed team. Over time, the team will reach the performing stage and make better decisions together. Much of this type of decision making falls on selecting the work that they will achieve and a collective understanding of the definition of done.

Manage Conflict Effectively Resolving functional conflict is a challenge, even for the best, most functional performing teams. As the team learns to self-manage, conflict resolution will become more effective. The ability to collaborate in a colocated environment helps this process, as does open and honest communication and collective decision making.

Safe Environment Having a safe environment applies more toward the emotional side of the human aspect of projects. If you have ever been afraid to bring up changes that should be made or to share your ideas, then your team space isn’t necessarily “safe.” To have a safe environment in which to work is less about removing hostile work environment influencers (of which I hope none of you work in) and more about a cultural shift in which the team feels comfortable and is able to work and learn while promoting the no-blame culture. If someone makes a mistake, the team owns it, and because of that philosophy the finger-pointing diminishes and the team rallies to support each other.

Generalized Specialists Having specialists on the team usually isn’t viewed as a terrible thing in most organizations. The more specialists, the better, right? It’s tough to disagree with that thought process. However, what if you have 10 to 12 specialists on your team who could also do a myriad of other things and who have a wide range of skill sets that reduce the need for larger teams? That would be a better situation for sure. The goal of smaller, more effective teams isn’t always achievable. In some organizations, the specialists do their thing and that is what is necessary to be successful.

Being a generalized specialist means that you are good at your job but that you can also do other things. Many expanding skill sets fall under good mentoring or training programs to expand skills outside of the specific things that you do daily. Expanding your knowledge and abilities is promoted in an Agile environment, and knowing how to roll with the punches, adapt, and adjust is key for effective Agile team members.

Task/Scrum or Kanban Boards/Whiteboards Big visible charts and graphs that are front and center go a long way toward open and transparent communication. The team contributes to the updates and isn’t dependent on a project manager to inform them weekly on their own progress. Anyone who walks into the team space will see what the team is doing, what they are working on, and what has been completed. This leaves very little question as to the efficiency of the team and the work that is being accomplished. If the brain processes visual images 60-thousand times faster than text, it is easy to see why these tools are so effective.

Round Tables Having round tables increases the ability to have free-flowing conversations and increases eye contact and the ability to read body language. It also signifies equality of everyone at the table. There is a reason King Arthur had the knights at a round table. Aside from chivalry, it’s a great practice to have round tables for, at the very least, conversations, brainstorming, and planning poker games if your organizational dynamic has a different setup.

No Barriers Like round tables, the removal of barriers helps increase osmotic communication as well as removing the need to pop your head over someone’s partitioned wall space, thus surprising them in the middle of an email. Many organizations have partitioned desk spaces and that’s okay. The best dynamics I have seen keep the partitions low enough to maintain eye contact and keep the flow of communication going but high enough that someone’s “hang in there” cat poster doesn’t end up next to your coffee cup.

Face-to-Face Communication Seeing a trend here? Round tables, no barriers, and face-to-face communication? It’s all dependent on the next item, colocation.

Common Team Area of Colocation Best practice suggests having your entire team occupy the same space within 33 feet of each other without barriers. The thought is that having a common area will supply multiple tools for team use as well as face-to-face communication. Having the ability to share information easily allows for tacit knowledge to be shared, and it saves substantial amounts of time that could be spent in meetings trying to obtain the same information. I don’t know anyone who can’t get behind that thought process. You might be thinking to yourself, “What happens if I need to make a private call?” or “All of that chatter and sharing can be distracting—I like quiet when I work.” You would not be alone in that thought process, so a best practice is to have a secluded area dedicated to the team. These are fondly known as “caves” or “common rooms.” These areas can be used to protect privacy as needed while working on the same iteration/sprint.

The team space is designed in such a way that all team members are playing on a level playing field. Everyone knows where everyone else is located and what everyone is working on. Colocation is always suggested on any project team for a lot of the reasons that you just reviewed. It isn’t always possible in the real world, so consideration must also be made for distributed or virtual teams.

Now let’s take a quick look at the roles or players on the team, whether they are virtual or not. In Figure 7.2, you’ll see a table of roles on an Agile project team and what titles you may see on the exam.

Even though having everyone colocated isn’t always possible, it is recommended that your team is colocated for the planning phase, at the very least, and for one iteration if not two.

If your organization has distributed teams across multiple locations, it is recommended that you colocate one entire team’s worth of positions so that each location has a fully functioning, cross-functional team working with the other teams on the same project. You may find in your own world that this can be very difficult to pull off and that your virtual or distributed team members may very well be working on an island by themselves. If that is the case, it is important to understand some of the challenges found on virtual teams.

Distributed Teams

If you have ever worked on or managed virtual teams, then I’m sure a lot of what you will read about in this section will resonate. Don’t get me wrong: There are a lot of benefits to having virtual team members, including, but not limited to, the ability to have people from all over the world as candidates for your open positions. I had a friend who used to say, “Brilliance isn’t always found in one place,” and she was correct.

Organizations can have team members who are in multiple time zones, who speak a multitude of languages, and who understand global markets. Or, people can work from home and cut down on their environmental footprint by not commuting every day. Yes, there are many benefits to having virtual teams, but there are also some challenges that, if not addressed, can wreak havoc on an Agile project team.

One of the items of which you should be aware is the PMI Code of Ethics and Professional Conduct. You will be asked to review, accept, and abide by the code as a practitioner of project management for any certifications that you obtain through PMI. It’s especially relevant to give you a glimpse into the code as it pertains to people who are colocated or virtual.

Section 3.1 of the PMI Code of Ethics and Professional Conduct reminds us that respect in all forms is our duty. The sidebar “Code of Ethics and Professional Conduct” provides a snippet of the code as it pertains to the human side of project management.

I chose to add snippets of the PMI Code of Ethics and Professional Conduct to this section of this study guide for the following reasons:

• First and foremost, you’ll have to agree to abide by the code as an Agile practitioner.
• Because in the world of global, virtual environments connected by a web of technology, it is easy to forget our manners sometimes.

There are some things to keep in mind and avoid if you are part of or working with virtual team members from a different country or even a different part of your own country. All of this applies to colocated team members as well, but since virtual team members don’t have the ability to be face-to-face all day and build relationships as quickly, much of this is experienced at the virtual level. It’s important to avoid these at all costs whenever possible, or at the very least be aware that they exist. Be diligent in your own world and the virtual world of your team members to identify and communicate anything that may waver outside the respect bubble.

The following list of challenges are not meant to be in any particular ranked order, but I feel that it is an important reminder to review the big challenges, if only to establish a list of things to consider while working with virtual employees.

While I put away my soapbox, ponder the main offenders:

Stereotypes I’ve heard people say that stereotypes are there for a reason. One such stereotype I heard recently is that all Philadelphia sports fans are obnoxious. I take umbrage with that and would counter by saying that is only the case when we are playing a football game against a team from a large city in Texas. Otherwise, we are very well mannered, thank you very much. Okay, okay, except that one time when people were whipping snowballs at Santa. It happened the year I was born, so I can’t be held accountable for that piece of our history. All joking aside, even if you do think that all Philly fans are obnoxious, it doesn’t mean that you should say it out loud, express your thoughts at the next stand-up meeting, let it interfere with your professional interactions with said football fans, or spread those terrible rumors in general. Your thoughts are your thoughts, and you think what you want, but in a professional environment all stereotypes should be kept out of the workplace and not influence your day-to-day work by making offensive jokes or treating people differently because of how you happen to view them.

Generalizations See above! Also, it is always never a bad idea to avoid words like…always and never. Nothing will demotivate a colocated or virtual team member more than being told that they always do (insert business task here) or that they never do (and here) correctly. This is especially helpful information to use on the home front as well. Generalizations can be hurtful, and frankly they are not accurate statements at all. I always try very hard never to generalize.

Ethnocentrism Ethnocentrism is the thought or feeling that one’s country or culture is better than anyone else’s. It’s shocking to me that this mindset continues, but I feel it is safe to say that any person who feels or professes that their culture is better than any others hasn’t traveled or actually met people from another culture. You can and should love your country, but you should respect another’s at the same time. The global environment we find ourselves working and living in should always include respect—no matter what. As an Agile project manager or team member, it is up to you to perpetuate best practices and lead by example. Ethnocentrism may be something you tolerate on your daily Facebook feed, but it should never be tolerated in a work environment. A big no-no!

Culture Shock Believe it or not, culture shock doesn’t just occur when you step off an airplane into another country and attempt to get your bearings while suffering from jet lag. Culture shock can happen when you join a new team with new management and a different vibe from your old team. If you have ever experienced anxiety when starting a new job, you can chalk that up to culture shock. It doesn’t mean that the new thing is necessarily bad or good; it just is different from the organizational culture that you are used to. Culture shock can often be experienced when a new team is in the forming stage and everyone is a bit uneasy and on their best behavior. There are several ways that you can practice adaptive leadership and servant leadership when you have a newly formed Agile team.

Culture shock can occur or be created by the following:

• Work habits
• Communication styles
• Time differences
• Lack of understanding of context
• Misreading body language
• Ethnocentrism

Best practices for avoiding culture shock are the following:

• Avoid ethnocentrism.
• Base team building events on each person’s country or culture.
• Educate each other about other cultures.
• Recognize different work styles, habits, writing styles, and language differences.
• Create ground rules as a team for meetings, emails, and other communications and set deadlines with very specific terms.
• Create mission statements, goals, and ground rules.
• Identify stakeholders and their expectations.
• Build relationships and generate trust.
• Recognize conflict even if it isn’t stated, and manage it according to organizational or team culture as much as possible.
• Have a casual meeting or gathering to help orient the team.
• Keep the team colocated for at least two iterations if possible.
• Make sure the team has a good understanding of the purpose of the project and what success looks like.
• Understand the definition of done.
• If distributed, make sure Agile teams are complete groups in each location with matching skill sets to the other locations if possible.

Osmotic Communication

You have already learned about and have probably experienced osmotic communication. The recommended best practice is colocation, which promotes a specific setup for your team space and encourages open, honest, and free-flowing conversations. The goal of any communication is for the message to be received and understood by the intended recipient. In a situation involving osmotic communication, even more people will receive the message and choose either to use the information or toss it away.

Have you ever sat in a crowded place, heard the buzz of conversations, and mostly ignored it as background noise until someone says something with which you are familiar or something that is interesting to you, so you zero in on the information and you begin to listen to the conversation more intently? That is osmotic communication. With an open environment of sharing and communication, the Agile team is set up a bit differently from other types of project teams in the sense that a prescribed and highly suggested best practice is to be colocated and to engage in communication on many subjects, including reaching consensus, learning new things, and being privy to transparent communication across all team members.

Information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis.

This is normally accomplished by seating them in the same room. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work.

Alistair Cockburn

Team and Individual Coaching

A team that has access to coaching will be a team with high performance. It’s as simple as that.

A bit later in the chapter, you’ll be reviewing velocity tracking as well as how to use burn up or burn down charts to track team performance. Nonetheless, even a great high-performing team may need some coaching at some point.

Lyssa Adkins, president of the Agile Coaching Institute, suggests some guidelines for one-on-one coaching:

• Stay a half step ahead.
• Guarantee safety.
• Partner with managers.
• Create positive regard.

Much of the advice is designed around creating an environment that is comfortable for the person receiving the coaching. The goal is to help the person feel like they are in a safe environment in which they can learn, grow, and totally make mistakes. Mastery isn’t earned; it is gained, and we could all use some coaching some of the time.

The part about partnering with managers would only be necessary if your team or part of your team belonged to another Agile project manager, or even a functional manager. That can happen in the real world. I borrowed generalized specialists from other functional departments as needed, and I always felt that it was a best practice to document all of the things that they learned and did on the project. My reasoning was twofold:

1. A lot of managers or bosses only remember the last two weeks of your life, and particularly the one stupid thing you did all year, so having documented proof that their people are awesome helps overcome some of that.
2. Documenting successes and learned skill sets helps to perpetuate growth in the team member because they have the support of their manager.

Hopefully it helps the manager understand the team member’s role on the project a bit better, and it also helps them develop the team member further since they are already on a growth trajectory from being coached on the project.

Agile best practices would suggest that part of being a servant leader of a self-directed team is knowing when to step in and help. That time is when someone asks you for help. If an individual comes to you and asks for guidance, or for you to drop some knowledge on them, then by all means hook them up! When it comes to the team, though, it can be a bit trickier to know when to facilitate, when to lead, and when to coach. My best advice is to coach the team as needed at specific points in the project. Typically, do so between iterations or specific planning points if the team is having trouble and needs more than a facilitator.

For me, coaching is best received on the team level during the retrospectives. This is the point when the team is looking back at the last iteration and asking themselves what they could do differently going forward and what they did well. This is especially true with teams newer to Agile frameworks. The coaching is mission critical then because there is a tendency to slip back into the “we always did it this way” habits of yore, especially when best practices are still freshly out of the chaos zone.

Velocity Tracking

I’ll be the first person to admit that creating charts and graphs from scratch is not my strong suit, and many times I’ll be scouring the Internet for free templates that I can use to knock out a status report. I tell you this for two reasons:

• There are actually free templates online that you can use to knock out a status report (yay!).
• You will be using charts and graphs for a lot of your transparent reporting. Those charts will be front and center and hanging on the team space wall, hence the frantic search for something functional and a bit easier on the eyes as well.

Smartsheet has a ton of templates out there, and they are awesome, free, and easy to use and they work with Excel. And, if you are looking for software, Smartsheet is a good one! (I’m not a paid representative for Smartsheet, but I’m all for spreading the joy when it comes to free, usable stuff and giving props where they are due.) What you are about to see in chart form is 95 percent Smartsheet and 5 percent me.

I’ll now show you the charts and graphs that you can use to track team performance during the iterations measured in the units that the team determines best suits the project. For our purposes, we’ll look at a velocity tracking chart as well as tracking the scope of work in burn up charts and burn down charts. These are probably the big three, most-used charts or visible items other than a Kanban/task/Scrum board.

Remember, the team’s velocity varies in the first iterations, increases, and eventually plateaus. Whether your team is still experiencing fluctuations in their velocity or things have stabilized, it is important to track velocity and for the team to know where they stand from iteration to iteration. Eventually, it becomes easier to predict when the increment will be done-done, once velocity stabilizes. Velocity tracking is all based on what has been done in the past to predict the future and to determine the time frame for completion.

In Figure 7.3, you can see the velocity from each iteration climb and eventually plateau as the team tracks how many story points they were able to complete in each iteration.

Because velocity fluctuates and plateaus, it is not always easy to answer the question, How long will this project take? It is better to give an estimate based on the average velocity of the first several iterations. That will give you and the team the ability to estimate more accurately going forward, before the team has determined the velocity plateau value.

Burn Down and Burn Up Charts

Charts and graphs in an Agile environment are supposed to be simple, easy-to-read dashboards of how the project and the team are progressing. No more Gantt charts, network diagrams, and critical path determinations. I’ll wait until you complete your happy dance and then we’ll begin.

The goal of any chart is to show visually the result of a lot of data manipulation and make it easy to understand. For both burn down and burn up charts, the simpler the better. As an overview, burn down charts show the progression of work completed, and burn up charts track completed work and document comprehensive scope changes along the way. Both charts are designed to help the team stay focused on the goal and work toward improvement and will significantly shorten the confusing status report conversations that tend to utilize conference rooms for much longer than necessary.

Burn Down Charts

Let’s start with burn down charts. A burn down chart, in the simplest of terms, tracks work completed in each iteration and allows for predictions to be made about how many iterations are left based on the amount of work completed and the amount of work remaining. How fast the team is burning through or completing user stories is a great way to show work in progress and work completed visually as well as to provide some insight into how the project is going.

The chart is rather basic in nature, with a projection line moving down as work is completed. Since nothing is ever perfect, don’t expect to see your burn down charts with a perfectly formed downward trajectory throughout the project. Real life shows that there are always fluctuations due to changes, tech debt, bug fixes, and perhaps a scramble to complete the project toward the end. Either way, the information is front and center. Everyone knows what is going on during the project, and they are very well aware when work isn’t being burned through at a high or even pace.

One thing always to consider in Agile project management is that when the team selects the work and someone asks the big question, “How long will this project take?” the team can make a prediction when that date will be, based on current work and velocity.

Another thing to consider is how differently this question is answered for an Agile project compared to a Waterfall or traditional project.

In a traditional project, which is fully scope-driven, since the scope of work is fairly static and set in stone, it is common for the time and money-related aspects to work around what is happening with the scope of work. That doesn’t mean that a customer or sponsor isn’t setting deadlines, because they certainly are. Those deadlines tend to be optimistic in nature, and that is precisely why many Waterfall projects come in over budget and behind schedule. But the end goal is always the scope of work. If you want it completed, you’ll have to provide contingency money and buffer time to get what you want.

In an Agile environment, the iteration length is static, and typically the budget is rendered due to the iteration length and the work predicted to be accomplished in that iteration. Scope of work isn’t fixed, but time and money may be. If a customer asks when the project will be done-done, the team will use a burn down chart to predict that based on what is currently in the backlog and what the definition of done is right now. The answer may be six months. The customer may want it in four months. Now it will be up to the customer to decide what is more important, time or scope. The team will explain how much they can get accomplished by the deadline, and the customer will have to decide whether to trim the tail off the scope of work or allow the team to take the time they need to produce to spec. It’s as if everything is flipped. I’m pretty sure that if I told my Waterfall sponsor that if they wanted something specific, they would have to wait X amount of time longer than they not-so-gently requested, I’d be creating an RPE for myself; that is, a resume-producing event.

In Figure 7.4, you’ll see a typical burn down chart and be able to understand just how easy it is not only to read but to create (with free templates!). This burn down chart shows the effort and iterations across time more realistically to the real world. Everything will fluctuate based on how the team is performing the work. The fluctuations will continue even if a plateau has been reached because it doesn’t necessarily mean that we are static and perfect going forward.

It looks simple, right? In this case, the burn down is showing that the team originally predicted that they would be finished in a certain amount of iterations based on the amount of points they needed to complete the work. My invisible team appears to be on track. In some cases, work gets added and begins to show a burn up on the chart, or the team adapted some of their estimates to accommodate something else on the project. After the burn up, the team returned to the original or close to the original projected velocity and pace.

I realize that the chart looks simple, and in reality, it is supposed to be. Will your charts be as simple? Probably not. In the case of a real project, there may be a lot of fluctuation in the beginning, and as velocity shifts and changes, more or fewer story points will be accomplished depending on how the project is going. The goal of any visual in Agile is to keep it as simple as possible, easy to read, and easy to explain. A burn down chart shows the team’s progress as they chip away at story points and practice continuous improvement on each iteration.

Burn Up Charts

The purpose of a burn up chart is to track completed work as with a burn down chart, but also to show very clearly the changes to scope and what is considered an ideal burn through the project. In this case, the burn line is moving up and scope can be added and removed as the team works through the chosen user stories. Both burn down and burn up charts show very clearly the visible result of knowledge work.

In Figure 7.5, you can see the three main variables plotted out on the chart. The first variable is the number of stories planned to be accomplished. This means that the team selected the number of stories they felt they could accomplish in a day, or week, or month. You can design your charts to match the iteration length on which your project is running. The second variable is the actual work accomplished, and the third variable is a visual of the ideal burn up; meaning that, if everything goes perfectly, this is what it will look like.

A Kanban board, velocity tracking, and burn up or burn down charts are all designed to be as easy to read as they are to create. Granted that there are many templates out there for you to use as well, and all you have to do is search for them and then adapt them as you go. If you are the guru in the office where Excel is concerned, then this will be a snap for you, or they can be hand drawn on a whiteboard or on flip charts. Either way, everything is supposed to be front and center in the team space and transparent in its communication of team performance.

Summary

In this chapter, we covered some additional items relating to the human side of Agile project management and reviewed some of the items of team performance that you saw in previous chapters. Because team performance builds on many of the best practices that you have already seen in different frameworks, plus ways to engage other stakeholders, this may seem redundant, but it is, in fact, the keystone to the rest of the Agile best practices working effectively.

We reviewed some skill mastery theories like Tuckman’s Ladder, Shu Ha Ri, and the Dreyfus model of the five stages of skill acquisition. Even though there are numerous theories out there about how people learn, communicate, and behave, these are the most prevalent on the PMI-ACP exam. Along with that, we went through some information on coaching your team and the best practices to do so.

Next we covered the best practices for collaborative team space tooling and some of the ideal configurations for an Agile team. Even though you may not be able to follow all of them, there are some great ideas on how to set up your space for maximum interaction, including but not limited to, the ability to experience osmotic communication.

We also covered some aspects of the PMI Code of Ethics and Professional Conduct that point to a need for all of us to practice respect and to avoid behaviors that can damage relationships and how that ties into a virtual or distributed team dynamic.

Finally, we covered some ways to see how well your team is performing with visual charts. We discussed burn up and burn down charts and graphs representing the team’s velocity, how much work is being accomplished, and the influence of scope changes mid-iteration.

Exam Essentials

Be able to understand different levels of skill mastery. Understand why it is important to know the level at which your individual team members are in their skill mastery and some ways to work with the team to reach the Ri stage and become a self-directed generalized specialist.

Understand the concept of collaborative work environments. Setting up your colocated team space to maximize your interactions will increase the ability to communicate and place everyone on an even playing field. This setup involves much more than moving desks around. The team space tooling is designed to encourage the team all to sit together and work as a unit while gathering information through osmotic communication.

Be able to understand the differences between working with a colocated team and a virtual team. Much of the exam will focus on colocation as the best practice, and many questions will place you in situations that involve a team space designed for colocated teams. It’s important to remember that currently there are more virtual Agile teams in the world than colocated. If you’re lucky enough to be in a perfect world, then certainly colocate as much as possible, but also be aware that your virtual team members need a slightly different kind of servant leadership.

Understand team and individual coaching. If you have a high-performing Agile team, then your role is that of a servant leader. This doesn’t mean that your team won’t occasionally benefit from coaching. Best practice states that you coach an individual when they ask for it and the team during planned meeting times, such as, for example, in a retrospective environment.

Be aware of different ways to show work effort visually. Velocity charts, burn down charts, and burn up charts are just a few of the visuals used to illustrate team performance metrics quickly and easily. It’s important to know what each chart does and what information is reflected in order to answer questions on the exam about how they differ.