Agile Team Roles 2019
This blog explains 60+ Agile team Roles used in 2019. The scrum framework defines common agile roles in an especially succinct manner. All the agile team roles and responsibilities are as follows:
Establishing New Agile Values
Lots of organizations post their core values on the wall. In this section, however, we are talking about values that represent a way of working together every day, supporting each other, and doing whatever it takes to achieve the scrum team’s commitments.
In addition to the values from the Agile Manifesto, the five core values for scrum teams are
The following sections provide details about each of these values.
Commitment implies engagement and involvement. On agile projects, the scrum team pledges to achieve specific goals. Confident that the scrum team will deliver what it promises, the organization mobilizes around the pledge to meet each goal.
Agile processes, including the idea of self-organization, provide people with all the authority they need to meet commitments. However, commitment requires a conscious effort. Consider the following points:
Scrum teams must be realistic when making commitments, especially for short sprints. It is easier, both logistically and psychologically, to bring new features into a sprint than it is to take unachievable features out of a sprint.
Scrum teams must fully commit to goals. This includes having a consensus among the team that the goal is achievable. After the scrum team agrees on a goal, the team does whatever it takes to reach that goal.
The scrum team is pragmatic but ensures that every sprint has a tangible value. Achieving a sprint goal and completing every item in the goal’s scope is different.
For example, a sprint goal of proving that a product can perform a specific action is much better than a goal stating that exactly seven requirements will be completed during the sprint. Effective scrum teams focus on the goal and remain flexible in the specifics of how to reach that goal.
Scrum teams are willing to be accountable for results. The scrum team has the power to be in charge of the project.
As a Scrum team member, you can be responsible for how you organize your day, the day-to-day work, and the outcome. Consistently meeting commitments is central to using agile approaches for long-term planning.
We all experience fear. We all have certain things we don’t want to do, whether asking a team member to explain something we don’t understand or confronting the boss.
Embracing agile techniques is a change for many organizations. Successfully making changes requires courage in the face of resistance. Following are some tips that foster courage: Realize that the processes that worked in the past won’t necessarily work now.
Sometimes you need to remind people of this fact. If you want to be successful with agile techniques, your everyday work processes need to change to improve. Be ready to buck the status quo.
The status quo will push back. Some people have vested interests and will not want to change how they work. Temper challenge with respect. Senior members of the organization might be especially resistant to change; they often created the old rules for how things were done.
Now you’re challenging those rules. Respectfully remind these individuals that you can achieve the benefits of agile techniques only by following the 12 agile principles faithfully. Ask them to give change a try.
Embrace other values. Have the courage to make commitments and stand behind those commitments. Have the courage to focus and tell distracters “no.”
Have the courage to be open and to acknowledge that there is always an opportunity to improve. And have the courage to be respectful and tolerant of other people’s views, even when they challenge your views.
As you replace your organization’s antiquated processes with more modern approaches, expect to be challenged. Take on that challenge; the rewards can be worth it in the end.
Working life is full of distractions. Plenty of people in your organization would love to use your time to make their day easier. Disruptions, however, are costly. Jonathan Spira, from the consulting firm Basex, published a report called “The Cost of Not Paying Attention: How Interruptions Impact Knowledge Worker Productivity.”
His report details how businesses in the United States lose close to $600 billion a year through workplace distractions. Scrum team members can help change those dysfunctions by insisting on an environment that allows them to focus.
To reduce distractions and increase productivity, scrum team members can Physically separate themselves from company distracters.
One of our favorite techniques for ensuring high productivity is to find an annex away from the company’s core offices and have that be the scrum team’s work area. Sometimes the best defense is distance.
Ensure that you’re not spending time on activities unrelated to the sprint goal. If someone tries to distract you from the sprint goal with something that “has to be done,” explain your priorities. Ask, “How will this request move the sprint goal forward?”
This simple question can push a lot of activities off the to-do list. Figure out what needs to be done and do only that. The development team determines the tasks necessary to achieve the sprint goal. If you’re a development team member, use this ownership to drive your focus to the priority tasks at hand.
Secrets have no place on an agile team. If the team is responsible for the result of the project, it only makes sense that they have all the facts at their disposal. Information is power, and ensuring that everyone has access to the information necessary to make the right decisions requires a willingness to be transparent.
To leverage the power of openness, you can Ensure that everyone on the team has access to the same information. Everything from the vision for the project down to the smallest detail about the status of tasks needs to be in the public domain as far as the team is concerned.
Use a centralized repository as the single source for information, and then avoid the distraction of “status reporting” by putting all status (burndowns, impediment list, and so forth) and information in this one place.
We often send a link to this repository to the project stakeholders and say, “All the information we have is a click away. There is no faster way to get updated.
Be open and encourage openness in others. Team members must feel free to speak openly about problems and opportunities to improve, whether the issues are something that they’re dealing with themselves or see elsewhere in the team. Openness requires trust within the team, and trust takes time to develop.
Defuse internal politics by discouraging gossip. If someone starts talking to you about what another team member did or didn’t do, ask him or her to take the issue to the person who can resolve it. Don’t gossip yourself. Ever.
Always be respectful. Openness is never an excuse to be destructive or mean. Respect is critical to an open team environment. Small problems unaddressed often grow to become crises.
Use an open environment to benefit from the input of the entire team and ensure that your development efforts are focused on the project’s true priorities.
Each individual on the team has something important to contribute. Your background, education, and experiences have a distinctive influence on the team. Share your uniqueness and look for, and appreciate, the same in others. You encourage respect when you Foster openness. Respect and openness go hand in hand.
Openness without respect causes resentment; openness with respect generates trust. Encourage a positive work environment. Happy people tend to treat one another better. Encourage positivity, and respect will follow.
Seek out differences. Don’t just tolerate differences; try to find them. The best solutions come from diverse opinions that have been considered and appropriately challenged.
Treat everyone on the team with the same degree of respect. All team members should be accorded the same respect, regardless of their role, level of experience, or immediate contribution. Encourage everyone to give his or her best. Respect is the safety net that allows innovation to thrive.
When people feel comfortable raising a wider range of ideas, the final solution can improve in ways that would never be considered without a respectful team environment. Use respect to your team’s advantage.
Changing Team Philosophy
A traditional approach to resource allocation (we prefer the term talent allocation) is to allocate portions of team members’ time across multiple teams and projects to get to full 100 percent utilization to justify the expense of employing team members.
For management, knowing that all hours of the week are accounted for and justified is gratifying. However, the result is lower productivity due to continual context switching — the cost associated with cognitive demobilization and remobilization to switch from one task to another.
Other common talent allocation practices include moving a team member from team to team to temporarily fill a skill gap or a manpower gap and tasking a team with multiple projects at once. These tactics are often employed to try to do more with less, but all the input variances make it nearly impossible to predict outputs.
These approaches have similar results: a significant decrease in productivity and an inability to extrapolate performance. Studies clearly show a minimum of 30 percent increase in the time required to complete projects run in parallel instead of serially.
Thrashing is another term for context switching between tasks. Avoid thrashing by dedicated team members to a single project at a time.
The following results occur when you dedicate scrum teams to work on only one project at a time:
More accurate release projections: Because the same people are consistently doing the same tasks every sprint with the same amount of time allocated to the project from sprint to sprint, scrum teams can accurately and empirically extrapolate how long it will take to complete their remaining backlog items with more certainty than traditional splintered approaches.
Effective, short iterations: Sprints are short because the shorter the feedback loop, the more quickly scrum teams can respond to feedback and changing needs. There just isn’t enough time for thrashing team members between projects.
Fewer and less costly defects: Context switching results in more defects because distracted developers produce lower quality functionality. It costs less to fix something while it is still fresh in your mind (during the sprint) than later when you have to try to remember the context of what you were working on.
Studies show that defects cost 6.5 times more to fix after the sprint ends and you’ve moved on to other requirements, 24 times more to fix when preparing for release, and 100 times more to fix after the product is in production.
If you want more predictability, higher productivity, and fewer defects, dedicate your scrum team members. We’ve found this to be one of the highest factors of agile transition success.
Cross-functionality makes development teams more efficient. For example, suppose a daily scrum meeting uncovers testing as the highest priority task to complete the requirement.
A programmer might help test to finish the task quickly. When the development team is cross-functional, it can swarm on product features, with as many people working on a single requirement as possible, to quickly complete the feature.
Cross-functionality also helps eliminate single points of failure. Consider traditional projects, where each person knows how to do one job. When a team member gets sick, goes on vacation, or leaves the company, no one else may be capable of doing his or her job.
The tasks that the person was doing are delayed. By contrast, cross-functional agile development team members are capable of doing many jobs. When one person is unavailable, another can step in.
Cross-functionality encourages each team member to Set aside the narrow label of what he or she can do. Titles have no place on an agile team. Skills and an ability to contribute are what matter. Start thinking of yourself as a Special Forces commando — knowledgeable enough in different areas that you can take on any situation.
Work to expand skills. Don’t work only in areas you already know. Try to learn something new each sprint. Techniques such as pair programming — where two developers work together to code one item — or shadowing other developers can help you learn new skills quickly and increase overall product quality.
Step up to help someone who has run into a roadblock. Helping someone with a real-world problem is a great way to learn a new skill.
A willingness to be flexible helps to balance workloads and makes the team more likely to reach its sprint goal. With cross-functionality in place, you avoid waiting for key people to work on tasks.
Instead, a motivated, even if somewhat less knowledgeable, a development team member can work on a piece of functionality today. That development team member learns and improves, and the workflow continues to be balanced.
One big payback of cross-functionality is that the development team completes work quickly. Post-sprint review afternoons are often celebration time. Go to the movies together. Head to the beach or the bowling alley. Go home early.
Self-management is closely related to self-organization. Agile development teams have a lot of control over how they work; that control comes with the responsibility for ensuring the project is successful. To succeed with self-management, development teams. Allow leadership to ebb and flow.
On agile projects, each person on the development team has the opportunity to lead. For different tasks, different leaders will naturally emerge; leadership will shift throughout the team based on skill expertise and previous experiences.
Rely on agile processes and tools to manage the work. Agile methods are tailored to make self-management easy.
With an agile approach, meetings have clear purposes and time limits, and artifacts expose information but rely on minimal effort to create and maintain. Taking advantage of these processes allows development teams to spend most of their time creating the product.
Report progress regularly and transparently. Each development team member is responsible for accurately updating work status on a daily basis. Luckily, progress reporting is a quick task on agile projects. Keeping status current and truthful makes planning and issue management easier.
Manage issues within the development team. Many obstacles can arise in a project: Development challenges and interpersonal problems are a couple of examples. The development team’s first point of escalation for most issues is the development team itself.
Create a teaming agreement. Development teams sometimes make up a teaming agreement, a document that outlines the expectations each team member will commit to meet.
Working agreements provide a shared understanding of behavioral expectations and empower the facilitator to keep the team on track according to what they’ve already agreed together.
Inspect and adapt. Figure out what works for your team. Best practices differ from team to team. Some teams work best by coming in early; others work best by coming in late.
The development team is responsible for reviewing its own performance and identifying techniques to continue and techniques to change. Actively participate. As with self-organization, self-management works only when development team members join in and commit to guiding the project’s direction.
Ideally, agile development teams have the least number of people necessary to be self-encapsulated (can do everything necessary to produce the product) and not have single points of failure.
To have skill coverage, teams typically won’t be any smaller than three people. Statistically, scrum teams are fastest with six developers, and cheapest with four to five developers. Keeping the development team size between three and nine people helps teams act as cohesive teams, and avoids creating subgroups, or silos.
Limiting development team size
Encourages diverse skills to be developed
Facilitates good team communication
Maintains the team in a single unit
Promotes joint code ownership, cross-functionality, and face-to-face communication
When you have a small development team, a similarly limited and focused project scope follows. Development team members are in close contact throughout the day as tasks, questions, and peer reviews flow back and forth between teammates. This cohesiveness ensures consistent engagement, increases communication, and reduces project risk.
When you have a large project and a correspondingly large development team, split the work between multiple scrum teams. For more on scaling agile projects across the enterprise.
Take the initiative. Instead of waiting for someone else to tell you what to work on, take action. Do what is necessary to help meet commitments and goals.
Succeed and fail as a team. On agile projects, accomplishments and failures alike belong to the project team. If problems arise, be accountable as a group, rather than finding blame. When you succeed, recognize the group effort necessary for that success. Trust the ability to make good decisions.
Development teams can make mature, responsible, and sound decisions about product development. This takes a degree of trust as team members become accustomed to having more control in a project.
Behavioral maturity and ownership don’t mean that agile development teams are perfect. Rather, they take ownership of the scope they commit to, and they take responsibility for meeting those commitments.
Mistakes happen. If they don’t, you aren’t pushing yourself outside your comfort zone. A mature development team identifies mistakes honestly, accepts responsibility for mistakes openly, and learns and improves from its mistakes consistently.
Create a Successful Agile Team
What kind of product do you have?
If you have a product with a database, you need people with database skills on your team. You might need database administration or data modeling skills. If your product includes user documentation, you might need the skills for creating that documentation.
What if your product is based on performance or reliability? You might need architecture or design leadership skills. (I prefer that the team learn how to assess performance or reliability or any other system quality by itself, without needing an external architect or designer.)
Because your product and organization are unique, I can’t tell you exactly who should be on your team. For example, all projects need project-management skills, but your team might not need a specific project manager. I do recommend your agile team has a full-time product owner with sufficient time to dedicate to the team.
The product owner is a Scrum term. And because it’s so pervasive in the industry, I’ll use it here to describe the one person who interacts with the team to create and rank the backlog.
Many agile approaches say, “The team has all the roles it needs.” That might mean the team has many people because no one has overlapping roles.
Instead of roles, think “capabilities” and “generalizing specialists.” People can have more than one capability. Both The Nature of Software Development and More Agile Testing: Learning Journeys for the Whole Team discuss the idea of capabilities and skills rather than roles.
Developers might not be good system testers, but they might be able to contribute to creating test-automation frameworks and being able to develop and think about testing through the architecture.
Maybe someone on the team has talents in the UI and can extend those skills to working through the application layer into the middleware. Maybe a platform person can also work in the database area.
Each of us has areas we prefer. In addition to those preferences, can we add more capabilities to our expertise?
Your team might also benefit from a coach, especially if the team is new to agile techniques. Agile approaches require people to change their mindsets and culture. Many people find a new culture a challenge: how to integrate the new thinking and the new practices?
Cross-functional teams have—at a minimum—developers and testers. Think about the skills and capabilities your team needs to deliver the product often. If you don’t have all the skills and capabilities on your team to release shippable product, that’s an impediment.
It might not be easy to remove that impediment. If you have cross-functional teams but not feature teams, consider measuring the time it takes for people to cycle through the features. Refer to Visualize Your Project’s Delays, to understand the effects of not having feature teams.
I call everyone on the team “developers” because that helps people realize their job is product development. Some people write code that ships. Those people are software developers.
Some people write code that stays. Those people are testers. Some people write documentation. Some people help the team integrate. But everyone has a single purpose: to enable the entire team to release features on a frequent basis.
If you have a nonsoftware team, you have people who develop the product (or event) and people who check to make sure the product is working properly.
Team Size Matters
[Note: You can free download the complete Office 365 and Office 2019 com setup Guide for here]
Beware of Too-Small Teams
Too-small teams—three or fewer people—might not have enough diversity to solve their problems. They don’t have enough ideas. Too few people can be just as bad—although differently bad— then too many people.
Collaborative teams need pair-wise communication, where everyone talks to everyone else. There is no restriction on communication, and we want people to talk to each other. Following is a picture of the paths in a six-person team. I numbered the paths going around and then from the top to the bottom, starting on the left side of the image.
The number of communication paths in the team does not increase linearly as the team size increases. Team communication paths square when the team increases linearly.
Here is the calculation where N is the number of people on the team: Communication Paths = N*(N-1)/2. That means you have these communication paths for these team sizes:
Team Members Communication Paths
4 people (4*3)/2=6
5 people (5*4)/2=10
6 people (6*5)/2=15
7 people (7*6)/2=21
8 people (8*7)/2=24
9 people (9*8)/2=36
10 people (10*9)/2=45
Five people require a total of 10 communication paths. Eight people require 24 communication paths. Once we get past 21 paths, many of us don’t talk with the entire team—we choose who to work with and who to ignore. Once a team gets to 10 people, the number of paths is 45, which is unmanageable for most of us.
Can some people manage this number of communication paths? Sure. But not many of us, which is the problem. That’s why “teams” of 10 people don’t work.
If you have a group of 10 people, they will naturally divide into smaller subteams of people who can work together. They will not divide themselves evenly, as in five and five.
Oh no, that would make life too easy. If you are lucky, they will divide by features. If you are not lucky, they will divide by architecture or by function, or even worse, by clique.
What do you do if you have a large team? Organizations create large teams for any number of reasons: they envision large features or the necessary expertise is distributed throughout the organization.
Sometimes the organization has a program, a collection of projects that fulfill one business objective. Often it’s easier to organize the features so that smaller feature teams can deliver the results than it is to create a larger team.
Consider these alternatives to create smaller cross-functional teams:
Make the stories smaller so the team can be smaller. Organize by feature or feature set. If you’ve been organizing by architecture, reorganize the teams to be feature teams. Aim for a feature team size of no more than six.
For example, think about these feature sets: search, admin, billing. Each of those feature sets might need just one team.
If your feature set is too large for one team, consider organizing as a program around smaller feature sets. For example, you might need a feature set for “simple search” and another feature set for “search within results.” Both would be search feature sets and the team members might need to work or speak with each other.
If you have already organized by feature and the team is still larger than nine, check for team skills and capabilities. The team members might not realize that it’s great if they “cover” other areas of the code or tests.
Should this team break into several other teams and organizations as a program? Sometimes when teams become large, it’s time for each team to take a feature set (or two) and focus on those features.
If you still need a large team, consider measuring the team’s throughput and see if the team waits for people outside the team or for people on the team. That will help you see if there is a problem with experts, as discussed in Trap: The Team Consists of Narrow Experts.
Ask Teams to Organize Themselves
Why Shouldn’t Managers Assign People to Teams?
If you have everyone on one campus, consider asking them to come to a large room. Explain the feature teams you expect: Admin, Diagnostics, Search, and so on. Label flip charts in different areas of the room with the names of the features. Ask people to stand near the flip chart they would like to work on.
Ask people to add their names to the flip chart. When the people are done moving around, see what you have. Ask each team to see if they are missing any capabilities on their team. Encourage the people around each flip chart to write down their capabilities and see where they are.
Facilitate organizing teams who have “too few” of any capabilities. In my experience, teams might be missing product owner, UI/UX, or testing capabilities.
If you can’t get everyone in the same physical location, ask people to do the same exercise virtually. The virtual exercise works especially well if people want to work with a particular product owner. People may have worked with this person before, so the product owner attracts a team to work with him or her.
If your organization has optimized for resource efficiency, don’t be surprised if you have teams that are not full-featured teams.
In that case, ask the team members to work in pairs (two people working together on one feature), and preferably as a mob (the entire team works together on one feature) so they can collaborate as a team.
As they collaborate, they will learn—as a team—which other people will need to create features. Teams can start the hiring process, regardless of whether that means extending an invitation to someone inside the organization or hiring from outside.
In my experience, teams of four to six people are just about the right size. In agile terms, that’s a couple of developers, a tester, and a product owner. Your experience might be different, so consider running experiments to see what the right team size is for different areas.
Ask the Team to Consider Its Values
Values are how people treat each other. Team members might explore how transparent they are with each other, what they focus on, and what they commit to. Instead of starting with a premade list of values.
1. Ask everyone to meet for about 30 minutes.
2. Provide everyone with index cards and a large, dark marker. The team members will need to see each other’s cards after writing them.
3. Ask each person to fill in this sentence: “I don’t like it when someone/people….” Each person might write down anywhere from two to five of these sentences.
4. Divide the team into pairs.
5. In pairs, select one card. Work with your partner to write down a statement that counters the negative statement.
For example, if you said, “I don’t like it when some people tell me what to do,” you might write a statement that says, “I like it when people discuss our technical approach as a team.” Continue until each pair addresses all its cards.
6. Ask the pairs to read each “I like it” card out loud. As the team members read the cards, capture what they say on a flip chart to post in the team area. (Note: the facilitator does not read the “I like it” statements. The team members read them.)
Now your team has described its values in a positive way. It’s time to create the team’s working agreements.
Ask the Team to Develop Working Agreements
Working agreements define the ways team members work together. These definitions might include what “done” means, ground rules of meetings, and team norms. For example, here are some working agreements to determine:
Core hours—Does the team need to commit to core hours so everyone knows when members are available?
What “done” means—Does the team know what “done” means for a story?
How the team treats meeting times—What will the team do if people are late to meetings or don’t attend at all?
What the team automates and when—It’s not possible to automate all testing. On the other hand, it is possible to automate much of it. What does this team need to automate and when?
How the team responds to urgent requests—If the team needs to respond to production support requests, it needs to know what those parameters are. So does the rest of the organization.
As the team members work together, they might realize they need working agreements in other areas. I have seen a number of teams decide that they need to timebox all their work, not just use timeboxes for an iteration. Your team might not need to do that. Working agreements make it easier for a team to collaborate to deliver.
Agile Teams Become Self-Organizing
Keep Teams Together
When developers work together, they often decide on a particular way of commenting code or how long a class or routine of some sort should be.
When testers work together, they often decide how much to automate when. When the entire team works together, it learns who makes which kinds of mistakes—and how to look for those problems. The team learns who must have the last word. The team learns how to provide each other with feedback and support.
Performing is where team members can learn to excel as a team. The team can be in flow together. They—almost instinctively—know who will react in which way. They can manage problems as a team, regardless of the kind of problems they have.
You want your teams to at least get to norming, and preferably to performing. It takes time for a team to learn how to norm and then perform. There is no substitute for working together on their work to move to the norm and performing. That means it takes time for teams to learn how to be effective together.
The more the team can work together, the faster they will norm and then perform. Your managers might be focused on utilization. Because teams take a while to learn to work together, keep the team together. In fact, consider making the team a product team, where the organization
Recognize Team Traps
As you try to create collaborative cross-functional teams, you may encounter problems such as these:
Your team is a component team.
Everyone on your team is a narrow expert.
The developers and testers don’t work together, but rather in staggered iterations.
The team’s membership isn’t stable, so the team has trouble learning to work together.
The team pushes to finish work.
The team cannot solve its own problems.
Team members have a history and culture of individual work, not collective work.
You can work to overcome these traps. Here are ways that might work for you.
Trap: Your Teams Are Component Teams
You have a cross-functional team, but the team works across the layers of the architecture. Or you have a cross-functional team that is missing some scarce person, possibly a DBA or a UX person. These teams need help from other teams or other people to finish features. When you are missing, your team cannot deliver a feature through the architecture.
Here’s what you can do:
Ask the person you are missing to join your team full-time for several weeks. While that person works with your team, pair or mob on everything that person touches.
If you’re like me, you might not become an expert in that person’s area of expertise, but you will have more understanding. You might need that person less often. I have seen this work with UX and DBA positions.
Explain to your management that you are missing a person with specific expertise. Your team doesn’t have all the roles it needs. Maybe you can hire someone to join your team.
It’s possible you don’t have enough people because your managers are stuck in resource-efficiency thinking. Create a kanban board showing cycle time, as illustrated in the diagram here.
I do not recommend a relatively popular alternative: adding “visitors” to a team. Visitors interfere with the team’s collaboration. The team will have to explain to each new visitor how it works. And the team will have to reform as it learns how to work with other people. See Keep Teams Together, for maximum teamwork and learning capability.
Trap: The Team Consists of Narrow Experts
For years, managers hired and rewarded people based on their ever-narrowing expertise. In agile, we need people with expertise in multiple areas, called generalizing specialists.
Experts have one deep capability. Often, the more expertise, the deeper their capability in an ever-more-narrow area. Generalizing specialists have varying expertise in several areas, as illustrated by the following diagram.
Everyone has preferences for what they like to do. When I was a developer, I preferred to work on the operating system (also known as the platform level) and algorithms, what we might call the middleware level in a several-tier architecture.
I could work on the user interface, but I wasn’t as comfortable there. I could test other people’s code, but not mine—certainly not very well —at the system level.
I was a generalizing specialist with expertise in several areas. Did I have a preference? Of course. Was I willing to work with the entire team to complete a particular feature or set of features? Yes. Encourage that kind of thinking in your team. You might be able to have fewer people on the team.
Here are some ideas to encourage that kind of thinking.
Make sure your managers and reward system recognize flow efficiency, not resource efficiency. See Managers Move from Resource-Efficiency to Flow-Efficiency Thinking.
Ask the team to limit its work in progress, so that the team has to work together to finish features. You can measure cumulative flow to see how much work in progress the team has for a given time and for the project.
If you find it useful, consider lunch-and-learns. At a lunch meeting, one person at a time presents his or her area of deep expertise.
Consider pairing or mobbing to avoid reinforcing expertise. I have found it useful to make sure experts work with other people in some way.
Trap: Developers and Testers Work in Successive or Staggered Iterations
I’ve worked with and seen many teams where the developers and testers were not united in a single cross-functional team. The developers finish their work in the first two-week iteration.
The testers might even start their testing in that iteration, but they don’t finish in the same iteration. As illustrated by the diagram, the testers on this team were at least two weeks “behind.”
Here’s the problem. The iteration duration is the duration of development and testing, and whatever else you need to complete the work.
When developers finish first, they create WIP for the testers. They may also become interrupted when the testers find problems. That means the developers create WIP for themselves, which might be invisible WIP because it’s not predictable.
Sequential work based on expertise makes your iterations longer. What would it take for you to work as a team on stories and reduce the lag between the time the development is done and the testing is done?
Consider these possibilities to help create cross-functional feature teams:
Create and use a kanban board to see where the work is waiting for people or specific skills/capabilities. Now you can see who you need. Measure the WIP to see how much work is waiting for which kinds of people or teams. Maybe that will encourage cross-functional team organization.
If you have functional teams, see the suggestion in Ask Teams to Organize Themselves.
Staggering development and testing are not agile or lean. It might be better than what you did before, but it’s not an agile approach.
Trap: Team Membership Is Not Stable
Some managers are concerned that the team is not working at maximum output. Those managers ask team members to work on a couple of teams or on several projects. Those managers are stuck in resource-efficiency thinking. See the discussion in Managers Move from Resource-Efficiency to Flow-Efficiency Thinking.
The more stable the team membership is, the easier it is for a team to become a norming or performing team. The team doesn’t incur a cost of re-forming itself every time someone enters or leaves the team.
The team members learn how to trust each other. Every time a team changes the membership, the team incurs a decrease in throughput. That’s because the team starts back at forming again.
Keep stable teams together.
Sometimes teams push themselves. Sometimes managers want to push the team into doing “more.” Here’s how you can tell if your team is working at an unsustainable pace:
The team pushes to complete work just before a demo.
The team wants a break between one chunk of work and the next. (In iteration-based agile approaches, teams want days or a week between iterations. Inflow, the team members want a break between the work they complete and the next item on the board.)
The team is working overtime all the time.
Developing great products requires everyone to be their best at all times. Don’t expect or ask people to work overtime. In my experience, that’s the fastest way to destroy technical excellence and creativity. Instead, ask people to collaborate at a sustainable pace.
Trap: Team Members Are Wary of Collaboration
Each person has his or her own preferred culture and way of working. Sometimes you can see these cultural preferences, as covered in Cultures and Organizations: Software of the Mind, Third Edition.
Some people enjoy working as part of a team. Some hate it. Sometimes people hate being a part of a team because the corporate culture creates incentives around individual work.
Regardless of where the wariness arises, you cannot tell people, “Let’s all be a team now!” Nothing you say will make a difference. On the other hand, there are things you can do:
You can ask people to experiment in short timeboxes for how they can work together.
If your organization still rewards people only for individual work, your attempts to use agile approaches are likely to fail. You have an impediment to an agile culture. Add this impediment (individual rewards) to your impediment list, and escalate that to management. See Visualize Problems with a Board.
Consider discussing the difference between flow efficiency and resource efficiency, as discussed in Managers Move from Resource-Efficiency to Flow-Efficiency Thinking, with team members. Conduct one-on-one to understand each person’s concerns. Once you do, you can start to address those concerns.
Whatever you do, don’t tell people they shouldn’t feel a certain way. People own their feelings and beliefs. You might have a person or even a team that is not interested in agile approaches.
Do not force agile approaches on them. Work with them for some reasonable amount of time. Help create a system of work that invites people to agile approaches. If that doesn’t work, be honest. Are agile approaches for right this team now? Maybe not.
Build Teamwork with Interpersonal Practices
The people on the team reflected his values. They treated each other as resources. They hated to ask for help. They knew they would be ranked against each other, so they competed, not collaborated.
Not surprisingly, they weren’t a team.
Humans comprise the product-development team. Not resources, although the people are resourceful. I have found that when people stop talking about resources and start talking about humans, people in the organization start to change their mindset and, therefore, the culture.
Because agile is a human-centric, collaborative approach to product development, your team needs to build its ability to work as a team using interpersonal skills.
In addition, managers need to change their language and team culture. How Managers Help Agile Teams, for an introduction to thinking about humans instead of “resources.”
Many technical people didn’t decide to work in technology because they had terrific interpersonal skills. They started their jobs because they liked solving problems.
In organizations, many people realize they need to learn to build their interpersonal skills so they can collaborate on building the product. They build a little, get some feedback to inform the next part of the work, build a little more, and get some feedback.
Successful agile teams use their agile mindset—that build, feedback, learn loop—for their interpersonal skills, too.
People work as team members and take risks when they are capable of providing feedback and coaching to each other. And leaders need to create safe environments for people to work as a team.
“soft” skills Interpersonal Skills Are Not “Soft”
Many people refer to interpersonal skills as “soft” skills. I don’t recommend that. “Soft” has the connotation of “easy,” or “not deep.” On the contrary, interpersonal skills require deep skill: understanding, practice, and learning.
Many of us discover that it’s much easier to learn technical skills than to learn and practice interpersonal skills. Consider calling these skills “interpersonal,” not soft.
Agile team members require at least two interpersonal skills: the ability to receive and provide feedback and coaching. When team members can provide each other feedback and coach each other, the team members can create a safe environment for the collaboration necessary for experimentation.
Those abilities help the team members learn from their work, as individuals, and as a team and help the team learn to deliver small increments of value often.
First, let’s think about what is similar about many agile team members.
How Agile Team Members Are Similar
Your agile team is unique. That said, successful agile team members tend to exhibit these interpersonal qualities:
Team members collaborate with each other.
Team members can ask each other for help.
Team members are adaptable, willing to work on whatever is next and possibly outside of their expertise.
In addition, many agile team members exhibit these preferences:
Do something good enough for now (as opposed to waiting for perfection).
Create experiments to try something and receive feedback on the product or the team’s process.
Be willing to work outside their preferences as a generalizing specialist to help the entire team deliver.
When team members and teams exhibit these qualities and preferences, they are able to persevere. They have the courage to try something and to continue their work even when the work is quite difficult. They are able to set long-term goals and persevere to achieve them, one small step at a time.
Team Members Practice Continual Feedback
I explained how to provide feedback, especially how to agree on the data. One of the team members asked what happened if they didn’t agree on the data.
I explained about “going meta”—starting at a higher level of abstraction—if they couldn’t agree on the data. That seemed to help.
They practiced with each other in the meeting, to make sure they knew how to provide and receive feedback. They went back to working on the product.
It took them about a week of practicing every day, multiple times a day, to get comfortable with feedback. Once they did, though, wow. They were able to release value as often as we wanted.
They took the idea of feedback and applied it to everything. Best thing I ever did. Peer-based feedback helps team members collaborate, learn, and adapt to what the team needs to finish work now.
As defined in What Did You Say? The Art of Giving and Receiving Feedback, feedback is “Information about past behavior, delivered in the present, which may influence future behavior.”
Consider using the peer-to-peer model of feedback, as explained in Behind Closed Doors: Secrets of Great Management:
Create an opening to deliver feedback.
Describe the behavior or result in a way that the person can hear.
State the impact of using “I” language.
Make a request for continued or changed behavior.
It doesn’t matter if you want to ask someone to continue to do something great (reinforcing feedback) or to ask someone to change (change-focused feedback). This approach works.
Here’s how feedback works in practice. Imagine you have a product that requires internationalization and localization to support multiple languages. A new tester, Dave, joins the team and discovers a problem in the English version.
He checks the French and Spanish languages—and yes, the problem is there, too. He opens three defect reports, one for each language. Judy, the developer, has this conversation with him:
Judy: Hey, Dave, got a sec? I want to talk to you about these defects.
Dave: Oh, okay.
Judy: Okay, let’s take this conference room. I’m not sure if you know about how we have reported internationalization problems in the past, but we report one problem against all the languages. You reported three problems that are the same. Did you realize that?
Dave: Uh, no. Is that a problem?
Judy: Well, it’s not earth-shattering, but it’s not how we work here. Can you make all these defects link to each other, and then only report one in the future?
Dave: Well, I can. But what about when I find three real problems?
Judy: Oh, report them! Don’t worry. You know, if you’re not sure, just ask me. I’ll tell you if I think it’s three problems. Actually, you can ask anyone on the team. You don’t have to ask me, in particular.
Dave: That’s okay? I thought I was responsible for the quality.
Judy: Aha! Nope, we’re all responsible for making sure the entire product works. Your job is to expose problems for us. You did. You just reported three instead of one. That’s the only issue here. Okay?
Dave: Oh, okay. Thanks.
Dave had made a mistake. Judy explained with feedback and offered to coach on the tester’s role. That’s all. Feedback is even more important when you have personal issues. Dirk had terrible body odor. Selma was supposed to pair with him and just couldn’t take it. Here’s how Selma handled the conversation.
Dirk: You ready to pair again, Selma?
Selma: Maybe. We have something more important to discuss. Please sit and let’s talk.
Dirk: Now you’re making me nervous.
Selma: Well, I’m kind of nervous bringing this up. Dirk, I have to tell you this. You have terrible body odor. I didn’t want to tell you, but I’m having trouble working with you, sitting next to you.
Dirk: Oh, that’s terrible. How long have you noticed this?
Selma: Since last month.
Dirk: You’re only telling me now? Well, at least you’re telling me now. Well, I did several things last month. I changed what I ate, I changed my deodorant, and I changed my laundry detergent. I don’t think my clothes are that clean, and I can change back. Should I go home and fix this now or do you think we can pair?
Selma: I think you should take a couple of hours to get your old deodorant and take a shower and wash your clothes.
Dirk: Okay, I’ll tell the boss.
You might think this is an extreme example. However, I have had to tell people their breath stank or that their body odor interfered with our ability to work together.
People on agile teams need the ability to provide and receive feedback about the work and the work environment. That includes us as humans.
Whatever you do, separate change-focused feedback from reinforcing feedback. Often, team members need both kinds of feedback and they don’t need them
Team Members Coach Each Other
Team members learn from one another and ask each other for feedback—not necessarily in the formal form. If you don’t hear these kinds of conversations (or see in virtual conversations) you may have the Trap: Not Enough Feedback.
That learning is where team members might coach each other. No one has an obligation to coach another, but the team members might offer to coach.
Coaching is offering options with support. Not everyone wants coaching from everyone else, so coaches must have permission before they start to coach. Otherwise, the coach inflicts help on the other person. That doesn’t help anyone.
Especially when coaching around new skills, I find it helpful to ask the other person to generate options. I don’t want to be the know-it-all or default to teaching when coaching is so much more than that.
When the other person can’t generate more options, I might prompt with one option and then see if the other person can generate more. I use the Rule of Three as defined in Behind Closed Doors: Secrets of Great Management to help people generate options before we evaluate possibilities.
In an agile project, the team members take responsibility for completing work together. They coach each other to help move the work across the board. When team members realize they don’t know something about how to work or how to solve a problem, they may ask for more training or coaching. As a leader, you might be able to help. You might not.
Recognize When the Team Needs an External Coach
Software development is a collaborative effort. It is—so far—the most challenging type of work. When I want to improve my skills, I attend workshops where I can obtain guided practice. Sometimes I need more than a workshop can provide me, so I engage a coach for more help over time.
What kind of coach does the team need? Consider asking the team what kind of help it wants. Different coaches coach at different levels for different areas. Very few coaches can coach at the three levels: inside the team, for the team, and for the organization. Use the retrospective data to see where the team needs assistance first.
Teams new to collaborative work might need coaches who can help the team teach or facilitate or partner with some practices such as continuous integration, test-driven development (TDD), or even pairing.
If the team is working well as a team but has internal impediments, the team (and you, as a servant leader) might need help seeing options for the team’s process.
If the team discovers that its impediments are from the culture or organizational processes, the team might need a coach at the organizational level. For more information about servant leadership, see How Leaders Serve the Team.
Does the Team Need to Track Collaboration?
Feedback and coaching improve a team’s collaboration capability. Team members don’t need to track their collaboration. However, if explicit collaboration is a new practice for your team, they might want to track their collaboration.
Tracking collaboration helps if the team members don’t collaborate to take stories together, or if they optimize in some other way for individuals and not the team. If the team wants to track collaboration, it might start with designing its own board, such as the example board shown in the figure.
The team on this board started to track with A (Ask for help) and O (Offer help). They decided different-colored stickies would be even better. Because this is data for the team and no one else, they could change their data collection at will. They found different colored stickies better than As and Os.
The stickies helped them see the distribution of asking and offering help more easily than the As and Os did.
Encourage your team to find a way to track how well it collaborates with a team. The team members might decide to start with creating WIP limits to see how well they—as a team—move work across their board.
I have worked with some teams that decided to track asks and offers for help as a way to encourage the team members to work together. Your team might need something else. You and your team might see other possibilities.
Create a Team Environment of Safety
There’s a bit of a chicken-and-egg problem with interpersonal skills. Teams need safety to build their skills. And building skills help the team members provide a safe environment for each other.
Amy C. Edmondson, in Teaming: How Organizations Learn, Innovate, and Compete in the Knowledge Economy, discusses the need for psychological safety in interdependent collaborative teams. Safety allows team members to discuss, explore together, and learn.
I initially pooh-poohed the idea of psychological safety. Then I realized that some of our teams had substantially more throughput than other teams. I had lunch with different team members and found a significant data point. Every single team with less throughput had at least one person as a “lead” of some sort.
I had created architectural leads, development leads, even test-architecture leads. I even called them my “indispensable” people. What a mistake. Those people imposed their agendas on the teams.
No one else on the team felt safe to say something that disagreed with those leads. They were concerned about other peoples’ possible negative perceptions of them.
I realized my mistake. I had one-on-ones with the leads and explained the problem. They agreed to each try experiments that removed them from the know-all position. One architect told me it was such a relief—he no longer had to know “everything.”
I explained the difference in how we thought about people. We created “communities of practice” and ways for these people to explore their influence on the business value of the architecture, automation, refactoring patterns, everything.
In addition, I focused on learning early. What small experiments could we run that would allow our teams to learn together, safely? That changed the culture over time.
It took about six months before I saw a fight between an architect and a tester. I was thrilled. That meant these two people felt comfortable enough to disagree and still be able to work together.
As a by-product, I have many more “indispensable” people now, but I no longer have a bus factor of one. Our entire organization is more adaptable and flexible in the work they do and in what they understand.
I now understand the need for safety. People have to be able to ask questions, challenge assumptions, and find new ways of working together. I’m not big on the kumbaya nonsense. I want results in the best possible product as early as we can deliver it. Psychological safety allows the teams to do that.
In agile terms, safety allows the team to manage the ambiguity and uncertainty about anything: the stories, the architecture, the tests. Safety allows the team to learn early by creating small experiments. Safety helps people admit and look for mistakes.
We create safety when we encourage learning from small experiments, use clear and direct language, admit when we don’t know, acknowledge when we fail, and set boundaries for what is a person or team decision and what is not. One of the best ways to create team safety is to create an environment in which team members feel safe to take risks.
Safety Helps the Team Evaluate and Recover from Risks
In more traditional projects, the project manager or the manager manages risks. That risk management often takes the form of “This could happen. How will we guard against it?”
Sometimes the team learns (late) that it didn’t manage risk. Safe teams mistake-proof their work. Sometimes the leader leads the mistake-proofing. Sometimes team members do. It doesn’t matter who leads it, as long as teams create ways to mistake-proof their work.
We were rolling along, releasing features into the code base every two weeks. We high-fived each other at every retro because we were so freaking awesome. I didn’t realize that we each had specific roles in the release and we didn’t know each other’s roles.
Joe put together the release notes. He also did some manual checks, which I didn’t realize. He went on vacation during the summer and we released as normal. We had Susie write the release notes.
The release notes were fine. The release didn’t work. We had to back it out and we had egg on our face. It didn’t matter that the previous 20 releases had gone well. This one didn’t. I looked into what happened.
Joe had been doing manual checks for several items. He hadn’t documented them. I hadn’t realized and neither had Susie. We decided to re-create the manual checks with automation so we wouldn’t make the same mistake again.
We didn’t blame each other. We acted to make sure this problem didn’t happen again for release. We took this opportunity to mistake-proof other areas in the team. We’re so much more robust now. We have a side-benefit, too: we can release more often and faster.
In agile projects, team members are more likely to ask this question: “How can we recognize risks when they are small, and if they do occur, how can we recover from them?”
Those are two different attitudes about risks. More traditional projects want prediction and control. Agile projects provide resilience. You will find ways to build resilience into your projects. Consider these two ways to build resilience: the team’s ability to manage its team membership and its ability to learn early.
Teams Manage Their Own Membership
Many organizations have a defined process for hiring: The manager fills out a requisition. The manager writes the job description. The manager phone-screens candidates. The manager decides who will interview the candidate. The manager decides who to hire.
If you want a collaborative, high-performing team, ask the manager to facilitate the hiring process, not manage it. Instead, ask the team to manage the hiring process. The more you want a collaborative team, the more the team has the ability to decide who is—and who is not—on the team. When managers decide, the team has less power to manage itself.
Teams who can manage their own membership help the team grow and deliver. They already know they want these people. The team is willing to invest time and energy in providing feedback and coaching to the team members.
Teams who don’t have a say in their team members might try to collaborate. However, I don’t see these teams sustain their collaboration when team members don’t fit.
Too often, we hire for technical skills and fire for interpersonal skills. See Hiring Geeks That Fit for more information about how to hire the for interpersonal skills your team needs.
Learn Early Instead of Failing Fast
One of the common phrases about agile is “fail fast.” The problem with “failing” is that it is an emotionally loaded word. We have decades of experience in organizations that require us to not fail.
Instead of failing fast, consider learning early. I find that learning early creates a different mindset for me. I now create small, safe-to-fail experiments. I manage my ambiguity around the entire deliverable by creating small steps.
I might be unique with my concern about the “fail fast” metaphor. If your team members have trouble with the idea of failing, consider asking them what they can learn and how early they can learn it. When teams decide to learn early, they might select more small experiments to provide the information. That information builds resilience in the team.
Team collaboration and learning helps the team build safety and resilience.
No one “bets the farm” on any one idea or one feature.
Safety Allows the Team to Build Respect
Feedback, coaching, and managing team membership helps the team create an environment in which people can work together, including experiment together, with safety.
One way to think about safety is to consider David Rock’s SCARF model (SCARF: A Brain-Based Model for Collaborating with and Influencing Others). SCARF stands for Status, Certainty, Autonomy,
Relatedness, and Fairness.
Here are some anti-collaboration patterns in terms of SCARF:
When the team’s status is uneven, such as when the manager is part of the team. People are reluctant to take a risk in front of their managers; see Weird Ideas That Work: How to Build a Creative Company.
When the team feels uncertain about its next steps. The larger the feature is, or the more uncertainty around a feature, the less certainty a team has about how to do the next work. When the team has insufficient autonomy to work the way it wants to. The team might feel bound by decisions from outside the team.
When the team doesn’t know or can’t manage its team membership—the team’s relatedness. If managers pluck people from or add people to a team, the team members don’t have the ability to develop their relationships.
When the team members sense unfairness in how they are treated, as individual members or as a team. Agile approaches invite team recognition and rewards to address this potential unfairness.
It’s not just a management status that can reduce collaboration; it might be other hierarchy, such as technical architecture. Architects can help keep the codebase coherent. Good architecture practices can help with refactoring and improve the performance of the product. The problem arises when the architect is external to the team.
When the organization creates an architectural career path where the architects don’t work on teams, the organization creates a hierarchy in the product-development organization.
That creates safety issues and often code (or test) issues. Agile teams move fast, building just enough for now and verifying that what they built works. The team can’t safely do that if they have to accommodate someone else’s (well-meaning) architecture or design.
The reason architects exist is that they know a tremendous amount about how systems work. That expertise might be quite helpful to the team members. Consider building communities of practice, open to whoever is interested. You might need these to start:
Technical practices that increase collaboration
Help your team increase its safety with equality on the team, certainty about its next steps by having small stories, autonomy for the team around its management and membership, and fairness in how the team members treat each other and how the organization treats them.
Trap: Not Enough Feedback
Collaborative teams learn how to work with each other. They talk about the product and the process on a regular basis. Healthy teams have team members who feel safe enough to ask for help and to discuss what’s going on for them. If you have ever encountered a problem where you got stuck and you asked for help, you used feedback.
For years, organizations recognized and rewarded people for individual work. That meant we had incentives to work alone, plug along, and solve the problem, however, we could. It also meant we worked alone for as long as possible, because the more difficult the problem, the more we might receive as recognition or reward.
That working-alone mindset is in stark opposition to a great agile team. Agile teams work together, to move work across the board, to help each other finish work, to work as generalizing specialists. Instead of being rewarded for individual work, we move to rewarding teams for teamwork.
That means even if people work alone on some chunk of work, we don’t want team members to be stuck and not ask for help or feedback. If you see team members working alone and being stuck, consider offering these options to your team:
Consider a team working agreement for how long people work alone without making progress. I like a timebox of no more than 15 minutes for being stuck. Then it’s time to ask for help. The stuck person can explain what he/she has done up until now, and then ask for feedback and coaching.
Talk to the Duck. Rubber-duck debugging works even better when the stuck person pairs with someone else.
Suggest that the team pair or mob on the problem. Everyone has different expertise. Consider inviting the team to use its wisdom together. If several people get stuck on test-driven forms of development or how to create small stories, you know to consider a workshop or coaching.
If you don’t hear a steady buzz, either in a team room or on some form of the communication channel, consider asking your team members if they receive enough feedback from each other. Consider the feedback board in Does the Team Need to Track Collaboration?, as a start to see what’s going on.
Trap: Inflicting Help
Everyone on your team is smart. In fact, if your team members are like some of the teams I’ve worked with, some of those people are super-smart. They have a ton of experience. They’re not afraid to help people, even if the people don’t want the help.
That’s a trap. While people may offer feedback or coaching, no one has the right to coach without explicit permission from the other person.
You have several options if you see this:
Provide feedback to the coach about what you see. That might be enough of a conversation.
If the coach agrees with your feedback, ask, “Would you like some discussion of what else you might do?” If the coach agrees, remind the coach of the possible stances as outlined in the graphic here. Together, you and the coach can discuss what might be a better alternative.
Ask the person being coached if he or she would like some help. You don’t want to inflict help either!
Make sure you have all the data if you think someone is inflicting help. You can try feedback from the people and then follow up with meta-coaching if they want you to do so.
Trap: The Feedback Sandwich
Feedback training isn’t very common, so people think about feedback in a variety of ways. One way that people have encountered is the “feedback sandwich.” That’s where Person A provides reinforcing feedback, followed by change-focused feedback, followed by reinforcing feedback.
When someone does this to me, I feel whiplash. I would rather receive all the changed-focused feedback at a different time than all the reinforcing feedback.
How Leaders Serve the Team
If you are accustomed to traditional project management, you might wonder who tells people what to do and when. The short answer is the team decides what to do as a team. The team takes its work in the way the team prefers. No one assigns work to anyone else.
When one person assigns work to another, that’s called “command and control.” It’s inefficient and often leads to less-than-desired outcomes. Agile teams are in charge of their own deliverables and interactions. The product owner explains the results he or she wants. Then, the team decides how to perform the work.
Agile project managers, coaches, product owners, and even managers are all servant leaders. These people serve the team, not the other way around.
In The Case for Servant Leadership, Kent Keith defines seven practices of servant leaders:
1. They are self-aware.
2. They listen.
3. They serve the people who work “for” them. (Keith calls this “changing the pyramid.”)
4. They help other people grow.
5. They coach people, not control them.
6. They unleash the energy and intelligence of others.
7. They work to develop their foresight so they can act, not react.
Servant leaders serve the team by facilitating the team’s work.
I Serve the Team, Not Management
by James, New Product Owner
I got training as a product owner, but it was nothing like what awaited me at work.
My team didn’t have anyone in a position of leadership except for me. The functional managers thought it was just fine for them to add to any given person’s backlog instead of telling me what they wanted.
I got fed up and called a meeting. I told them that adding more work to anyone’s list of work was no longer acceptable. They would funnel requests through me or the team wouldn’t do any of that work.
One of the managers asked, “Aren’t you a servant leader?” I said I was. The manager then said, “Well, you need to serve us.”
I saw red. I said, “No, I serve the team. You want me to serve you? Act as a team.” I walked out.
After I took a walk around the block, I went back and knocked on my manager’s door. I told him what I’d done. He said, “Good for you!” We discussed who served whom more and I was much happier about the entire situation. Oh, and we got someone to be the agile project manager so I didn’t have to fight those battles.
Servant leaders are not wimps or pushovers. They serve the team, doing what the team needs them to do. Most people don’t need to manage the management team. On the other hand, don’t be afraid to do so. Your team will thank you for your service.
Agile Project Managers Facilitate to Serve
Managing sponsor expectations. Too many senior managers think agile is a way to get “more, faster, cheaper” without realizing the team needs to learn—to learn how the product needs to work and to learn how to work as an agile team.
Managing the project portfolio so the team has no context switching and is cross-functional and stable.
Obtaining more funding if necessary. Making sure the long-lead-time items show up on time. This is especially helpful for projects with hardware or mechanical parts.
In addition, sometimes it makes sense for an agile project manager to represent the team and its status to more senior management. This is not an exhaustive list. You might need other actions from your agile project manager.
If you use Scrum, you might say the agile project manager is a Scrum master. That is correct. I am not fond of “master” or “chief” names for roles. And if you use any other approach to agile, aside from Scrum, you can still use the term “agile project manager” for the role.
I was accustomed to asking people what they would do and when we would see their deliverables. I didn’t demand that people do anything, but I did ask for dates and status.
When we moved to agile, I had to change everything I did. It took me a while to figure it out. I started to ask the product owner about the sequencing of the features in the roadmap and the backlog. I made sure he understood the difference between feature sets and features. We wanted features!
I had to educate my management about what they could expect from me and from the team. No more Gantt charts; they could see the roadmap. No velocity charts; we had product backlog burnup charts.
I did have to nudge—okay, push—my management to give us our own UX person. I had to explain about flow efficiency, which blew their minds.
I’m sure I did more. I think it took me about three months to change my expectations of myself. I was no longer the center of the team in terms of my deliverables. Instead, I made it possible for other people to deliver their work.
Controlling project managers? Not so helpful.
Does Every Team Need an Agile Coach?
Agile coaches are pervasive in the industry. Does your team need one?
Let’s talk about the difference between knowing how to do something, such as automated testing, and how to do it here.
If your team doesn’t know about some useful practices, it needs training. If the team doesn’t see how to use those practices here, it needs coaching.
As an example, if the team knows how to workshop stories or write automated tests at all levels, it doesn’t need training. And if the team doesn’t seem to be able to make time for story writing or automated test writing, it might need coaching.
Training helps people understand and, with any luck, practice a new skill. Coaching helps people see options as to how to use the skills they have. Or to realize they need more training because they are missing skills.
I often recommend a coach to help the agile transformation team. The agile transformation team often includes middle and senior managers. Those people rarely have experience with an agile mindset. Or if they know about the agile mindset and culture, they may have trouble understanding why things aren’t working here.
Consider coaching for your new-to-agile teams and the managers who want teams to use agile approaches.
Consider Your Team’s Need for Management
For too long, project managers “herded,” “managed,” or “controlled” the team or its output. I have seen people attempt to exert their will on others. I was never successful with these approaches. I didn’t like treating people like animals, or managing them like tasks, or controlling them as if they were robots.
Instead, I realized long ago I was much more successful if I treated people as if they were adults. If I respected them, helped them when they needed help, and explained the results I wanted, I more often than not getting the results I wanted.
Your team might not need any form of “management.” On the other hand, I have seen many teams that needed someone to help the team remove impediments and serve the team.