Listen to this post:
This is part 4 of 7 posts on PMI-ACP Exam Prep (link to part 3). In this post, I focus on building high-performance teams, including adaptive leadership, empowering and coaching the team, collaborative team spaces, and performance tracking.
Why people over process?
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.” Indeed, the idea of individuals over processes is the path to project success. Having best in class people (compared to industry averages) will always bring better results over having best in class processes (compared to industry averages). The goal is obviously to improve both people and process – but given a choice, there will always be better return from investing in people.
Agile Team Roles
Key team roles include:
Dev Team/Delivery Team
This group includes everyone needed to build and test a complete increment of the product, such as coders, writers, designers, analysts, and testers. These team members:
- Build the product increments, using agile practices and processes.
- Regularly update information radiators to share their progress with stakeholders.
- Soft organize and self-directed their working process within an iteration.
- Share their progress with each other in the daily standup meetings.
- Write acceptance tests for the product increments.
- Test and revise the product increments until they pass the acceptance tests.
- Demonstrate the completed product increment to the customer in the iteration review meeting.
- Hold iteration retrospectives to reflect on their process and continually improve it.
- Perform release and iteration planning, including estimating the stories and tasks.
Product Owner/Customer/Proxy/Value Management Team/Business Rep
The goals of this team role are:
- Maximize the value of the product by choosing and prioritizing the product features.
- Manages the product backlog, making sure that it is accurate, up to date, and prioritized by business values.
- Makes sure the team has a shared understanding of the backlog items and the values they are supposed to deliver.
- Provides the acceptance criteria that the delivery team will use to prepare acceptance tests.
- Determines whether each completed product increment is working as intended, and either except sit for requests changes.
- May change into product features and their priority at any time.
- Facilitates the engagement of external stakeholders and manages their expectations.
- Provides the due date for the project and/or its releases.
- Attends planning meetings, reviews, and retrospectives.
Scrum Master/Coach/Team Leader
- Acts as a servant leader to the delivery team, helping them improve and remove barriers to their progress.
- Helps the delivery team self-governing self-organize.
- Serves as a facilitator and conduit for communication within the delivery team and with other stakeholders.
- Makes sure the delivery team’s plan is visible and its progress is radiated to stakeholders.
- Acts a coach and mentor to the delivery team.
- Guides the team’s agile process and makes sure their agile practices are being used properly.
- Helps the product owner managed the product back.
- Helps the product owner communicated the project vision, goals, and backlog items to the delivery team.
- Facilitates meetings: Planning, reviews, and retrospectives.
- Follows up on issues raised in standup meetings to remove impediments so that the team can stay on track.
- Serves as the projects main advocate within the organization.
- Provides direction to the product owner role about the organization’s overall goals for the project.
- Focuses on the big picture of whether the project will deliver the expected values on time on budget.
- Is invited to the iteration review meetings to see the product increments as they are completed, but might not attend.
Building Agile Teams
There are 4 aspects to a great agile team:
- Agile methods recommend keeping the delivery team small (typically less than 12 people) since this allows the team members to develop better relationships and communicate more directly. If the project requires a larger group, it will usually need to be broken into smaller subteams that coordinate their work.
- The team consists of generalized specialists. Meaning rather than having complementary skills, a software developer may also be able to do QA and business analysis. This doesn’t mean they are the jack of all trades but more like the king of several trades and master of each. This helps in 2 ways:
- Less handoff is required – handoffs can be risky and time-consuming
- Fewer bottlenecks.
- They are committed to a common purpose.
- Hold themselves mutually accountable.
Exam Tip 1: In the real world, agile teams may be large but for the sake of the exam, the recommendation is 12 or less.
Exam Tip 2: Agile teams sometimes use the word “swarming” to discribe collective problem solving – this can take the form of multiple people pitching in to finish a task, remove a bottleneck, or move a deliverable across the line to production readiness.
Characteristics of High-Performing Teams
A few characteristics of a high-performing team include:
- Create a shared vision for the team. This enables the team to make faster decisions and build trust.
- Set realistic goals.
- Limit team size to 12 or less.
- Build a sense of team identity. This will help increase the team member’s loyalty to the team and support for other team members.
- Provide strong leadership. Leaders should point out the way, then let the team own the mission.
- Self-organized rather than role or title based.
- Empowered to make decisions.
- Believe as a team they can solve any problem.
- Committed to team success rather than success at any cost.
- Own their decisions and commitments.
- Motivated by trust.
- Consensus-driven. Divergence and then convergence.
- They are in constant constructive disagreements. This is vital for really understanding and working out issues.
It’s really important to understand that self-organizing and self-directing attributes of agile teams are goals. We don’t start there. The team members will initially need support and tools and learn to work together as a team. Once the team has stabilized we can introduce the goals of self-organization and self-direction as long-term objectives for groups.
Furthermore, empowered teams aim to create an emergent leadership model where different people step up to lead different initiatives. One identifying feature of high-performing teams is how seamlessly they swap leadership roles without an angry power struggle or big debate.
In leading agile teams it is important that you create a safe place for experiments. Allowing team members to try new approaches, make mistakes, and then get help, learn, and recover from mistakes. But how do you do this? Don’t criticize an experiment that fails and rather ask for lessons learned. And create an engagement culture. Reward people for problem-solving, collaboration and sharing ideas and inputs.
Models of Team Development
There are 3 models of team development that the PMI-ACP exam will expect you to be familiar with: Cockburn’s Shu-Ha-Ri model, Dreyfus’s model of skill acquisition, and Tuckman’s model of team formation. Let’s look at each below.
Shu-Ha-Ri Model of Skill Mastery
This model describes a 3 step process of increasing mastery that progresses as follows:
- Shu: Obeying the rules – Shu means “to keep, protect, or maintain”
- Ha: Consciously moving away from the rules – Ha means “to detach or break free”
- Ri: Unconsciously finding an individual path – Ri means “to go beyond and transcend”
Put simply, obey the rules, break the rules, and make your own rules!
A very good example of how you can use this model is shared in this YouTube video: https://www.youtube.com/watch?v=TxJP9vcldVc
Dreyfus Model of Adult Skill Acquisition
According to this model, adults learn new skills over 5 stages: novice, advanced beginner, competent, proficient, and expert. Let’s examine each stage:
- Novice: They follow rules they have been given and make analytical decisions.
- Advanced beginner: They are still like a novice in many ways but at this stage, they have gained enough experience with real-world situations to begin to understand the context of the rules.
- Competent: As we start to gain competence, the number of rules and guidelines for different contexts become overwhelming. Since we can’t apply them all, we begin to decide which rules are the best for each situation, and this makes us feel more personally responsible for the choices we make.
- Proficient: At this stage, our decision making is still analytical but we are actively choosing the best strategy rather than relying on the rules and become more emotionally involved in the process and the tasks.
- Expert: Our decision making has become more intuitive – we are able to spontaneously assess the alternatives and select the best approach without having to first analytically examine all the possible strategies.
Tuckman Model of team Formation and Development
The 4 primary stages of this model are called Forming, Storming, Norming, and Performing. There are followed by a disengagement phase called Adjourning or Mourning since people often miss being on a high-performing team after it’s disbanded.
Training, Coaching, and Mentoring
Training is the teaching of a skill or knowledge through practice and instruction. There is an agenda and a structured format that is usually prepared in advance.
Coaching is a facilitated process that helps the person being coached to develop and improve their performance. Coaching often starts with an initial topic that is then expanded and developed in collaboration with the coach. Coaching sessions have a structure and scheduled in advance.
Mentoring is more of a professional relationship than a specific activity. The mentee sets the agenda and the format is free-flowing.
In the context of an agile team, coaching is the most common of these activities. The goal of coaching is to help the team members stay on track, overcome issues, and continually improve their skills. Coaching is done at 2 levels: the team and the individual team members.
As you can see team coaching happens more at the iteration boundaries because that’s when the team assembles for events like iteration planning, reviews, and retrospectives. These are the best time to make sure the team’s practices are working well and help the team embody their agile goals. It’s also important to note that any process changes needs to take place either before or after the iteration as the midpoint is the time that is dedicated for the team to deliver and we need to make sure the environment is stable.
During the iteration, individual coaching can take place and it usually happens if individuals have problems they need help with. Here are a few guidelines for one-on-one coaching:
- Meet them a half step ahead. Don’t try to push people directly to the endpoint.
- Guarantee safety. Tell your team members that the all coaching conversations will be kept confidential and make sure that they are!
- Partner with managers. In case the managers are not involved in the project or not aware of agile values and goals, the team members contributions may not be properly reported. This will ensure all parties are on the same page.
- Create positive regard. We may not like everyone we coach but we must coach everyone equally.
Creating Collaborative Team Spaces
if you recall, agile methods recommend face-to-face interaction as the preferred means of communication. And so co-locating team members is highly recommended. An agile team is only considered to be co-located if all its members are working within 10 meters of each other without any barriers such as walls or doorways between them. But co-locating is not always possible as teams may be geographically dispersed. The team may use digital tools to duplicate the effects of physical co-location as much as possible. In such cases, we call this setup virtual co-location.
As mentioned above, co-located teams members need to actually be in the same space. This is the team space (or “war room“). The area should have plenty of wall space for whiteboards during a collaborative discussion as well as room to post information radiators of project metrics. Other things to consider: sticky notes, video conf. capabilities, food, snacks, and toys.
Caves and Common
One of the challenges of working in an open area without barriers is the lack of privacy and quiet time. To address this, agile team spaces follow a “caves and common” model. Most of the work is done in the “common” area where the team works together as a group, however, they also have access to private spaces, “caves”, where they can take a call, have private conversations, or just work by themselves for a short time.
Tacit knowledge is the unwritten information that is collectively known by the group, such as how to restart the printer when it jams. Although instructions may not have been written down, since the team is in the same common area and hears how others are dealing with such issues, it becomes common knowledge. Tacit knowledge works best for small, co-located teams. A larger team needs to commit more things to write to keep everyone informed.
Osmotic communication refers to the useful information that flows between team members who are working in close proximity to each other as they overhear each other’s conversations. For example, 2 team members are discussing a server restart and the 3rd team member overhears this. It so happens that the 3rd team member is using the server and could lose her work if the restart takes place. She could intervene and prevent a potential conflict. Again only teams that are co-located can benefit from osmotic communication. This is why it’s important to have no barriers to communication and have all team members working closely.
Global, Cultural, and Team Diversity
It’s not uncommon to have team members from 3 or 4 continents working on the same project. Although different cultures bring challenges, they can also bring more efficiency to a project because there is a broader pool of resources to choose from. Since knowledge work is invisible, agile teams rely on coordination and communication to share information. However, globally distributed teams face special challenges in this area that needs to be addressed:
- Different time zones: Team members may be working at different times of day, which can impede their ability to get to know each other and achieve unity. If this is the case we may need to spend more time coordinating their communication.
- Different cultures: Many societies are more hierarchical than western culture, and they may consider it rude to make suggestions, give candid feedback, bring up problems, or disagree openly. In this case, we may need to explicitly encourage this behavior and explain that this kind of transparency is required for an agile to work smoothly.
- Different communication styles: Different cultures may have different communication norms. To address this, we may need to train the entire team about each others communication style. We can also watch out for misunderstandings, inappropriate jokes, culturally sensitive terminology, and clashing assumptions about gender roles.
- Different native languages: Different languages may lead to miscommunication about the work being done. To address this, We may need to take steps to ensure a shared understanding of the acceptance criteria and confirm that everyone on the team has the same understanding of what needs to be done. We may also need to provide more detailed instructions and documentation.
Diverse city issues may need to be addressed on coal located teams too. In this case, the XP practice of pair programming can be used. Working together on a task gives teams a great opportunity to Yet to know each other better, work as a unit, and become comfortable handling conflict, raising problems, communicating progress, and brainstorming.
Distributed teams are teams that have at least one team member working offsite. Agile methods work better for distributed teams than non-agile approaches because of the following factors:
- The short iterations used in agile development force continuous close collaboration and coordination.
- The project will be easier to control because a releasable product is built each iteration.
In other words, if you have to manage in a distributed team, it is best to use an agile approach, because the frequent feedback is more helpful than just piling on documentation to keep the team on track.
Exam Tip 3: Note that a distributed team is not the same as outsourcing. Distributed projects basically have multiple development sitesThat can spend buildings, cities, or countries. Outsourced projects involve multiple legal entities, therefore contracting, contract administration, and dealing with different development infrastructures are added to the teams workload.
One aspect of distributed teams to keep in mind is that the team formation phases of Storming and Norming are more difficult when team members are not co-located. One best practice that will help the members of a distributed team communicate better is to start by holding a face-to-face kickoff meeting. It’s even better if we can extend this face-to-face kickoff meeting so that team members can work together for the first one or two iterations before they return to their respective countries. One other way could be to have a rotating temporary assignment of team members between locations to give the team members in each region an opportunity to work in person with the people from the other teams and experience their cultures.
The big challenge for distributed agile teams is finding ways to create virtual co-location. In other words, trying to replicate the benefits of face-to-face collaboration, osmotic communication, tacit knowledge, and improving relationships that come from working In close proximity to each other. The key is to find tools that could help you in achieving your goal of creating a virtual co-location.
Tracking Team Performance
Now let’s examine how agile teams monitor their progress and performance. (note I will go into more detail on each of the following tools in the next post as the play a key role in agile planning and estimating.) We’ll look at burn charts and velocity.
We’ve seen that agile teams rely on low-tech, high-touch tools displayed on highly visible information radiators – and burn charts are one of the most common tools displayed in this way. Burn charts are important because they make the team’s progress visible at a glance and make it easy to forecast when the project will be complete. There are 2 kinds of burn charts: burndown and burnup. Burndown charts show the estimated effort remaining on the project, and burnup charts show the features that have been delivered already.
A burndown chart tracks the work that remains to be done on a project. As work is completed, the progress line on the chart will move downward, reflecting the smaller amount of work that is still needed to be done. The most common use of burndown charts is for measuring the team’s progress in completing the project work.
Typically, burn down charts show either the estimated time remaining or estimated story points remaining. Teams can also forecast the effort they plan to do to complete the project on time and putting it to on the same chart will help us track their progress.
Burnup charts track the work that has been completed. Therefore, over the course of the project, the progress line on a burner chart will move upward, showing the increasing amount of work that has been completed. The big advantage of using a burnup chart is that it can show changes in scope, making the impact of those changes invisible.
On the chart above we can see that the scope increased after the 5th Sprint from 352 story points to 472 story points. We can also see the original plan vs. actual effort by the team and the estimated effort required to complete all story points. But what about working progress? We can add work in progress to our burnup chart to track both work started and work completed. When you do that, we create a cumulative flow diagram (CFD), as discussed in part 2 of this post.
Velocity is defined as the measure of a teams capacity for work per iteration. This powerful me trick allows the team to gauge how much work they will be able to do in future iterations based on the amount of work day completed in the past. This provides a way to track and communicate what they have accomplished, anticipate what they will be able to accomplish in the future, and forecast window project or release is likely to be done.
Velocity usually varies the most in the first few iterations and then begins to stabilize. This is because the team has to get used to working together, familiarize themselves with the project tools, and get comfortable interacting with the project stakeholders. While it may seem logical to predict ever-increasing velocity as a team gains experience, velocity does typically plateau. One reason for this is that, as the product gets bigger, there is more to maintain, refactor, and possibly support if early versions of the product have been deployed. In general, knowledge work projects tend to increase in complexity as the work is being done.
The fact that velocity tends to stabilize over time makes it a very powerful tool for planning and estimating. Once a team has tracked their velocity over multiple iterations, they can use their average velocity to estimate when the next release or project will be done. For example, Let’s say there are 50 story points of undeveloped work remaining in the backlog for the first release. The team has already completed 10 iterations for that release, and they have been averaging about 20 story points per iteration. We can divide the remaining work by the teams average velocity per iteration (50/20=2.5), to estimate that it will probably take the team 3 more iterations to complete the release.