Agile Project management Roles 2019
The scrum framework defines common agile roles in an especially succinct manner. We use scrum terms to describe agile roles throughout this blog. These roles are
Development team member
The product owner, development team, and scrum master together make up the scrum team. Each role is a peer to the others — no one is the boss of anyone else on the team. The following roles are not part of the Scrum framework but are still critically important to agile projects:
The scrum team together with the stakeholders make up the agile project team. At the center of it all is the development team. The product owner and scrum master fulfill roles that ensure the development team’s success.
The product owner, sometimes called the customer representative in non-scrum environments, is responsible for bridging the gaps between the customer, business stakeholders, and the development team. The product owner is an expert on the product and the customer’s needs and priorities.
The product owner, who is a peer member of the scrum team, shields the development team from business distractions, works with the development team daily to help clarify requirements, and accepts completed work throughout the sprint in preparation for the sprint review. Product owners make the decisions about what the product does and does not include. Add to that the responsibility of deciding what to release to the market and when to do it, and you see that you need a smart and savvy person to fill this role.
On an agile project, the product owner will
Develop a strategy and direction for the project and set long- and short-term goals.
Provide or have access to product expertise.
Understand and convey the customer’s and other business stakeholders’ needs to the development team
Gather, prioritize, and manage product requirements.
Take responsibility for the product’s budget and profitability.
Decide when to release completed functionality.
Work with the development team on a daily basis to answer questions and make decisions.
Accept or reject completed work — as it’s completed — during the sprint.
Present the scrum team’s accomplishments at the end of each sprint, before the development team demonstrates these accomplishments.
What makes a good product owner? Decisiveness. Good product owners understand the customer thoroughly and are empowered by the organization to make difficult business decisions every day. Although able to gather requirements from stakeholders, product owners are knowledgeable about the product in their own right. They can prioritize with confidence.
Good product owners interact well with the business stakeholder community, the development team, and the scrum master. They are pragmatic and able to make trade-offs based on reality. They are accessible to the development team and also ask for what they need. They are patient, especially with questions from the development team.
The product owner takes on a great deal of business-related responsibility during the project. Although the project sponsor funds and owns the budget, the product owner manages how the budget is spent. With a dedicated and decisive product owner, the development team has all the business support it needs to turn requirements into working functionality. The following section explains how the product owner helps ensure that the development team understands the product it will create.
Development team members
Development team members are the people who create the product. In software development, programmers, testers, designers, writers, data engineers, and anyone else with a hands-on role in product development are development team members. With other types of product, the development team members may have different skills. On an agile project, the development team is Directly accountable for creating project deliverables.
The development team members determine their own tasks and how they want to complete those tasks.
Collectively, the development team possesses all the skills required to elaborate, design, develop, test, integrate and document requirements into working functionality.
Development team members are versatile — they’re not tied to a single skill set. They have existing skills to immediately contribute at the beginning of the project, but they are also willing to learn new skills and to teach what they know to other development team members. Ideally dedicated to one project for the duration of the project.
The team should be working together in the same area of the same office.
A scrum master sometimes called a project facilitator in non-scrum agile environments, is responsible for supporting the development team, clearing organizational roadblocks, and keeping processes true to agile principles.
A scrum master is different from a project manager. Teams using traditional project approaches work for a project manager. A scrum master, on the other hand, is a servant-leader peer who supports the team so that it is fully functional and productive. The scrum master role is an enabling role, rather than an accountability role.
On an agile project, the scrum master will Act as a process coach, helping the project team and the organization follows scrum values and practices.
Help remove project impediments — both reactively and proactively — and shield the development team from external interferences.
Foster close cooperation between stakeholders and the scrum team.
Facilitate consensus building within the scrum team.
Protect the scrum team from organizational distractions.
We compare the scrum master to the aeronautical engineer whose job is to reduce drag on the aircraft. Drag is always there but can be reduced through innovative and proactive engineering. Likewise, all projects have organizational impediments creating a drag on the team’s efficiency, and there is always another constraint that can be identified and removed. One of the most significant parts of a scrum master’s role is removing roadblocks and preventing distractions to the development team’s work.
A scrum master who is good at these tasks is priceless to the project and to the team. If a development team has seven people, the effect of a good scrum master is timed seven. The product owner may never have participated in an agile project, but the scrum master likely has. As such, a scrum master may coach new product owners and development teams and does everything possible to help them succeed.
What makes a good scrum master? A scrum master doesn’t need project management experience. A scrum master is an expert in agile processes and can coach others. The scrum master must also work collaboratively with the product owner and the stakeholder community. Facilitation skills cut through the noise of group gatherings and ensure that everyone on the scrum team is focused on the right priority at the right time.
Scrum masters have strong communication skills, with enough organizational clout to secure the conditions for success by negotiating for the right environment, protecting the team from distractions, and removing impediments. Scrum masters are great facilitators and great listeners. They can negotiate their way through conflicting opinions and help the team help itself.
Clout is not the same thing as authority. Organizations need to empower their scrum masters so they can influence change in the project team and organization, but clout involves earned respect, often through success and experience. Some types of clout that empower scrum masters come about through expertise (usually a niche knowledge), longevity (“I’ve been at the company a long time and know its history first hand”), charisma (“people generally like me”), or associations (“I know important people”). Don’t underestimate the value of a scrum master with clout.
The members of the scrum team the product owner, development team, and scrum masterwork together on the project every day. As we mention earlier in the blog, the scrum team plus stakeholders make up the project team. Sometimes stakeholders have less active participation than scrum team members but still can have a considerable effect and provide a great deal of value to a project.
Stakeholders are anyone with an interest in the project. They are not ultimately responsible for executing the product, but they provide input and are affected by the project’s outcome. The group of stakeholders is diverse and can include people from different departments or even different companies. On an agile project, stakeholders May include technical people, such as infrastructure architects or system administrators.
Stakeholders may help provide key insights into the product and its use. Stake-holders might work closely with the product owner during the sprint and will give feedback about the product during the sprint review at the end of each sprint.
Stakeholders and the part they play vary among projects and organizations. Almost all agile projects have stakeholders outside the scrum team. Some projects also have agile mentors, especially projects with project teams that are new to agile processes.
A mentor is a great idea for any area in which you want to develop new expertise. The agile mentor, sometimes called an agile coach, is someone who has experience implementing agile projects and can share that experience with a project team. The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a higher level.
On an agile project, the agile mentor Serves in a mentoring role only and is not part of the scrum team Is often a person from outside the organization, and can provide objective guidance, without personal or political considerations Is an agile expert with significant experience in implementing agile techniques and running agile projects of different sizes
You may want to think of an agile mentor the way you think of a golf coach. Most people use a golf coach not because they don’t know how to play the game of golf but because a golf coach objectively observes things that a player engaged in the game never notices. Golf, like implementing agile techniques, is an exercise where small nuances make a world of difference in performance.
Establishing New 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 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 the 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
An agile development team operates differently from a team using a waterfall approach. Development team members must change their roles based on each day’s priorities, organize themselves, and think about projects in a whole new way to achieve their commitments. To be part of a successful agile project, development teams should embrace the following attributes:
Dedicated team: Each scrum team member works only on the project assigned to the scrum team, and not with outside teams or projects. Projects may finish and new projects may start, but the team stays the same.
Cross-functionality: The willingness and ability to work on different types of tasks to create the product.
Self-organization: The ability and responsibility to determine how to go about the work of product development.
Self-management: The ability and responsibility to keep work on the track.
Size-limited teams: Right-size development teams to ensure effective communication. Smaller is better; the development team should never be larger than nine people.
Ownership: Take initiative for work and responsibility for results. The following sections look at each of these ideas in more detail.
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.
On traditional projects, experienced team members are often typecast as having a single skill. For example, a .NET programmer may always do .NET work, and a tester may always do quality control work. Team members with complementary skills are often considered to be part of separate groups, such as the programming group or the testing group.
Agile approaches bring the people who create products together into a cohesive group — the development team. People on agile development teams try to avoid titles and limited roles. Development team members may start a project with one skill, but learn to perform many different jobs throughout the project to help create the product.
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, 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.
Agile techniques emphasize self-organizing development teams to take advantage of development team members’ varied knowledge and experience. Self-organization is an important part of being agile. Why? In a word: ownership. Self-organized teams are not complying with orders from others; they own the solution developed and that makes a huge difference in team member engagement and solution quality.
For development teams used to a traditional command-and-control project management model, self-organization may take some extra effort at first. Agile projects do not have a project manager to tell the development team what to do. Instead, self-organizing development teams Commit to their own sprint goals. At the beginning of each sprint, the development team works with the product owner to identify an objective it can reach, based on project priorities. Identify their tasks.
Development team members determine the tasks necessary to meet each sprint goal. The development team works together to figure out who takes on which task, how to get the work done, and how to address risks and issues. Estimate the effort necessary for requirements and related tasks. The development team knows the most about how much effort it will take to create specific product features.
Focus on communication.
Successful agile development teams hone their communication skills by being transparent, communicating face-to-face, being aware of nonverbal communication, participating, and listening.
The key to communication is clarity.
With complex topics, avoid one-way, potentially ambiguous modes of communication, such as email. Face-to-face communication prevents misunderstandings and frustration. You can always summarize the conversation in a quick email later if details need to be retained.
Collaborate. Getting the input of a diverse scrum team almost always improves the product but requires solid collaboration skills. Collaboration is the foundation of an effective agile team.
No successful project is an island. Collaboration skills help scrum team members take risks with ideas and bring innovative solutions to project problems. A safe and comfortable environment is a cornerstone of a successful agile project.
Decide with consensus. For maximum productivity, the entire development team must be on the same page and committed to the goal at hand. The scrum master often plays an active role in building consensus, but the development team ultimately takes responsibility for reaching agreement on decisions, and everyone owns the decisions.
Actively participate. Self-organization may be challenging for the shy. All development team members must actively participate. No one is going to tell the development team what to do to create the product. The development team members tell themselves what to do. And when. And how.
In our agile coaching experience, we’ve heard new agile development team members ask questions like, “So, what should I do now?” A good scrum master answers by asking the developer what he or she needs to do to achieve the sprint goal, or by asking the rest of the development team what they suggest. Answering questions with questions can be a helpful way to guide a development team toward being self-organizing.
Being part of a self-organizing development team takes responsibility, but it also has its rewards. Self-organization gives development teams the freedom to succeed. Self-organization increases ownership, which can result in better products, which can help development team members find more satisfaction in their work.
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.
Agile development teams are intentionally small. A small development team is a nimble team. As the development team size grows, so does the overhead associated with orchestrating task flow and communication flow. 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.
Being part of a cross-functional, self-organized, self-managing development team requires responsibility and ownership. The top-down management approaches on traditional projects do not always foster the maturity of ownership necessary for taking responsibility for projects and results.
Even seasoned development team members may need to adjust their behavior to get used to making decisions on agile projects. Development teams can adapt behavior and increase their level of ownership by doing the following:
Take 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 for 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
The cross-functional team is the heart of an agile approach. Cross-functional teams can deliver a working product. When you don’t have a cross-functional team, delivering anything seems impossible. Let’s see how to create the cross-functional team your project needs.
The Project Team Is a Product-Development Team
You may think you have a project team or a feature team. A feature team can deliver features without depending on anyone else across the organization.
One way to make sure your team can deliver features is to think of your team as a product development team. When people think about product development instead of projects, they often realize that they need other skills and capabilities (possibly in the form of other people) on the 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.
Agile teams fulfill these requirements:
The team has all the people (with their skills and capabilities) it needs to complete the work.
The team does not change people for a given feature.
The team has a shared goal for its project.
The team “owns” its work. Members commit to their work and they own their artifacts, including the code and tests.
The team does not change people inside an iteration.
The team is stable, so the people can learn to work together and can learn their product area(s).
If the team uses iterations, no one changes what the team commits to for that iteration.
Your feature team needs enough product developers and product testers to maintain technical excellence as it delivers working product frequently. Who you need depends on the kind of product you are working on.
Do I Need to Have Stable Feature Teams?
If your organization is based on resource efficiency, you may have trouble convincing your management that you need to have stable, cross-functional teams to release features. However, the more you change team composition, the more the team will revert to forming or storming. It takes time for people to learn to work together and trust each other. The more you change team composition, the more each feature costs.
If you have cross-functional, component teams, someone or some team still has to integrate work so that you can release features. You will incur a cost of waiting for the experts you need.
Stable, cross-functional feature teams that work through the architecture can develop and release features faster than any other team.
Agile Changes Team Roles
You might be accustomed to projecting managers who decide on dates. You might not have seen a product manager since the last millennium. That all changes in agile. In agile, the product owner or customer decides which features (including technical debt or defects) the team will work on and when.
The team then is in charge of how the team does the work. The team makes all the architectural and design decisions. The team is free to attempt to change the product owner’s mind about when to do something to make it easier to implement a feature.
No one outside the team designs for the team. That includes UX people, product managers, and architects outside the team. The team makes its own decisions.
There is a role for architects and project managers in an agile project. They are part of the team and deliver code as part of the team. Because the team delivers on its own, the team needs to be a reasonable size for the team to work together well.
Team Size Matters
I like small teams, between four and six people. Here’s why.
I’ve observed over the years that teams of more than nine people didn’t have what I call the “intimacy” of smaller teams. Teams of three people or smaller didn’t always have the ideas needed, but teams larger than nine people lost something that was common to smaller teams—an ability to easily communicate with each other. There is a reason for that: the number of communication paths in the team.
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
If your organization has always organized by function (development, testing) or by architecture (front-end, back-end, middleware), consider asking the teams to organize themselves to become feature teams.
Too often, managers want to assign people to cross-functional teams. Instead, ask the people to discover how to create feature teams that make sense for them.
Why Shouldn’t Managers Assign People to Teams?
Too often, managers don’t have enough information about the people. Managers might not know what a team member wants to learn. They only know what a person has done since that person started to work for that manager. People have many more capabilities and skills.
When team members self-select their areas of interest, they have a purpose. They start to exercise their autonomy so they can build more mastery. When managers assign people based on expertise, those managers reinforce the problem of resource efficiency.
Let the team members decide what features to work on and whom to work with. You will see better throughput and more of a chance at technical excellence. See Creating Great Teams for more information.
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 they 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.
Facilitate the Team’s Social Contract
Once the team has some people, it’s time to help it create its agile culture. That culture helps the team members work together and deliver as a team.
Edgar Schein, in Organizational Culture and Leadership, defines organizational culture as what people can say, how they treat each other, and what the organization rewards. (The team might reward differently than the organization, especially if your organization has just started its agile journey.)
One way to think about the team’s culture is to think of the team as a social contract. Agile teams might be able to work with implicit contracts. I have found that because agile is so different than the team’s previous ways of working, it helps the team to explicitly create its own social contract.
In turn, that social contract helps team members articulate how they are willing to work in the form of values and working agreements. Your team might realize that it says one thing and does another, which doesn’t help anyone finish any work.
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, consider this activity, described by Dhaval Panchal, to flesh out your team’s 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
Teams need time to learn how to work together. Many technical practices and interpersonal practices help teams learn how to work together. And this learning takes time.
People learn together by working together. Don’t waste time on fake team-building activities such as anything physical. Those activities might be fun for some people, but they don’t help people learn how to work together at work.
The team forms, whether the members select each other or someone decides they should work together. They are polite to each other and attempt to work together.
As they try to work together, the storm. One person doesn’t like the way another person makes decisions. Or they disagree on the outcome. Whatever the issue, the team members learn how to work together.
After a while, they start to normalize. 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 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 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.
Staggered 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 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: The Team Requires Permission from Distant Managers to Solve Problems
Your organization might have powerful functional managers (development, quality assurance, and others) or a powerful PMO (project management office). Those people dictate who works on your team and when, and what your team can do. Too often, those managers—while they mean well—do not understand the problems the team encounters.
The functional managers think of people as a “pool” of resources, as in the “Shared Services” Often Aren’t approach to people. And too often, the PMO dictates the project documents or the approach to the project the team should take.
Too often, these folks want to dictate solutions for your team.
Consider this: these people want to do the right thing. Their experience shows them that the “right” thing is different from what an agile team needs. As a leader, you have at least these options:
Ask these people to take a chance and allow the team to experiment with its process.
Ask these people to empower you as the person who can facilitate the team’s problem-solving process.
Build your influencing and upward-coaching skills so you can work with these people over time to help them understand what agile approaches buy the team, them, and the organization.
And you always have the option of not using agile approaches. See Manage It! for a thorough discussion of life cycles that might be easier than using agile approaches.
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. See blog 16, 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
Too many people receive feedback once a year from their manager in the form of a performance evaluation. Too often, the data—if there is any—is too vague or late to be useful. And rarely do people on teams have a chance to practice feedback with each other or with their managers. Feedback seems to flow downhill, just as mud does. Infrequent muddy feedback from people outside the team is useless. Frequent, data-based feedback from peers is helpful.
We had a team who was accustomed to the waterfall, a sequenced approach to projects with one delivery at the end of the project. I knew we had to get good at releasing small deliveries to get feedback on our work, both on the product and how we worked together.
I explained to the team that I wanted us to know we could deliver useful chunks at least as often as every week. Were they willing to do that? Yes, they each said. I explained we would probably make mistakes along the way. Were they willing to provide feedback to each other? Not blaming, just the facts.
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 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 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
In a cohesive agile team, you see feedback everywhere. Team members experiment together and separately, learning different areas of the product and learning how to make the product work. You’ll hear things like this:
“Did you know if you refactor like this, you can see that?” “Oh, no, I didn’t. Show me more.”
“Hey, does anyone know why this test returned those results?” “Oh, we haven’t fixed that part yet. Let’s look at it together.”
Fist-bump. “Thanks for showing me how to do that.”
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.
Help the Team Members Build Trust
Stable teams can learn to build trust when they work together. Team members who focus on the work, who learn how to give and receive feedback, who can coach each other and receive coaching, can create trusting relationships.
If people are new to stable teams, they may never have worked at building trust with each other before. In Building Trust in Business, Politics, Relationships, and Life, Robert C. Solomon suggests people are trustworthy when they do the following:
Deliver what they promise to deliver
Are consistent in their actions and reactions
Make integrity a cornerstone of their work
Are willing to discuss, influence, and negotiate
Trust in themselves and their colleagues
Agile approaches help teams and team members see what they promise to deliver. Being able to give and receive feedback and coaching can help people manage small problems before those problems become large. When people use technical practices that support ongoing work, they can create work that has integrity.
Interpersonal skills, by themselves, won’t guarantee the team can learn to trust each other. However, more team members can build trust when they have the interpersonal skills to manage their interactions.
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 the skills helps 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 a 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 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.
The more the team can provide each other feedback and coaching, and manage their membership, the freer the team will be to collaborate and build a safe environment for itself.
Recognize Interpersonal-Skills Traps
As people develop these skills, you might see some traps:
The team members don’t provide enough feedback to each other.
Team members inflict help when they see a solution.
Team members “sandwich” their feedback.
You can work to overcome these traps. Here are ways that might work for you.
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.
If you want to provide feedback to someone, and some are change-focused and some is reinforcing, consider these options:
Ask yourself if the person really needs all this feedback. Maybe the feedback is about you, not the other person.
Ask the person which feedback he or she would like to hear first:
change-focused or reinforcing? Then, organize the feedback.
Conduct separate meetings where you provide one kind of feedback. At a later date, provide the other feedback.
The best thing you and everyone else can do is to practice feedback. As with many agile ideas, the smaller the feedback, the easier it is for the other person to hear it and act on it.
Agile Requires Different Project Leadership
Every project needs some sort of project management. Not every project, especially agile projects, needs a project manager. In fact, if you have a cross-functional feature team and everyone in the organization has an agile mindset, you might not need any project leadership. However, I have yet to see this circumstance in organizations that are new to agile approaches.
When you first start using an agile approach, you may need a servant leader in the form of an agile project manager or a coach to help the team understand the process it needs. That servant leader might need to help the team recognize what to change about the team’s process and how the team could change.
You might need that person to protect the team from what I call “management mayhem” in Avoid Management Mayhem. Agile project managers facilitate the team’s process and remove impediments that prevent the team from delivering finished value.
You might be accustomed to more of a hierarchy in your project: the project manager took responsibility for the team’s work and the team’s process. Everyone reported to the project manager. Conversely, in agile approaches, team members report to each other. The team commits to and takes responsibility for its work and its process. That changes the kind of leadership a team needs.
Agile teams do not require anyone to control them. Agile teams don’t need any hierarchy to work or to solve problems. In fact, hierarchy and control often prevent team members from feeling safe and collaborating, which many teams depend on for learning and experimenting. Agile teams require servant leadership—a different kind of project management.
Agile project-management activities facilitate the team’s ability to work and to deliver value. In this blog, I’ll discuss what servant leaders are, the servant leaders you need, and the servant leaders you might consider for your team.
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
An agile project manager facilitates and serves the entire team. Agile project managers identify and manage risks that the team needs someone to manage.
Here is a list of what an agile project manager might do at the team level:
Facilitate the team’s process. New-to-agile teams don’t have the agile mindset and culture baked into their DNA. Who will learn more about how they can make agile work for them? Who will schedule the demo and the retrospective and make sure the two meetings occur?
Remove or enable removal of impediments the team members can’t remove. Many impediments are at the organization level. The team isn’t going to tackle them. The team “delegates” the impediment to the project manager.
Assist the team in measuring the team’s velocity, cycle time, and any other measurements. This might be as simple as creating the space for the team to measure as they walk the board.
Assist the product owner in writing stories for the next iteration. New product owners may not understand how to write small-enough stories for iterations.
Facilitate the team’s workshopping of the project vision.
Facilitate the team’s workshopping of the release criteria.
Facilitate the team’s working agreements, including the team’s definition of “done.”
In addition, the team may need help in identifying and managing the team’s risks. This can be many different things:
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.
Project managers who act as servant leaders fulfill useful functions. Project managers can be especially helpful if managers don’t understand the difference between resource efficiency and flow efficiency.
Controlling project managers? Not so helpful.
Here’s what agile project managers do not do:
The agile project manager does not assign work.
The agile project manager does not estimate work on behalf of the team.
The agile project manager does not commit to features, stories, or tasks on behalf of the team.
The agile project manager does not agree to dates.
The agile project manager does not agree to constraints on the project.
For many new-to-agile teams, this is a huge change. In serial life cycles, such as a waterfall or phase-gate, there is no such role as the product owner. (In serial life cycles, the team works on all the requirements, then all the analysis, then all the design, and so on. Phase-gate life cycles have gates—checkpoints —after each phase before a team can proceed to the next phase.)
In the serial lifecycle, the project manager assesses the requirements and decides what features/requirements/whatever the team should work on first, second, third, and so on. The project manager decides on the deliverables.
In agile approaches, the product owner decides the rank order of what the team will do, often using rolling-wave deliverable-based planning. Rolling-wave planning says to plan a little now—say up to four weeks of work—and as the team completes one week, add a week to the end. The team always has a four-week plan, a rolling wave. See Manage It! for a larger explanation and see Create Rolling-Wave Roadmaps, for more details as to how to apply rolling-wave planning to agile projects.
The product owner decides which features (deliverables) the team needs to implement now, and what rank they are. The product owner decides when to replan. The agile project manager might assist/suggest/facilitate, but the deliverable-based planning is the product owner’s job.
The product owner now performs some of the work a project manager might have done:
The product owner (or the product manager) manages the “commitments” to external requests.
The product owner defines deliverables for the team to focus on and deliver.
The product owner defines the rolling-wave planning so the team can look ahead a bit.
This can be a large change for traditional project managers, who were accustomed to making their deliverable-based rolling-wave plan work. (Yes, you could make a waterfall project work with deliverable-based rolling-wave planning. It was difficult but possible.) Some project managers have a difficult time reconciling their role to be one of a servant leader, facilitating the team’s work rather than directing it.
This also means every team needs a product owner. If two teams work off the same backlog, it’s possible those two teams can share a product owner. A product owner has the ability to decide about features in the moment, to define acceptance criteria, and to explain a story for the team at any time.
Beware of the Trap: Your Team Has a Business Analyst Masquerading as a Product Owner. Every team needs a product owner.
What Product Owners Do
Product owners represent the customer to the team. The product owner creates and ranks the product backlog for a team. Often, the product owner works with a product manager to create a coherent picture of the product (the roadmap) and this time period (the backlog).
The product owner takes input from the rest of the organization and creates and ranks the stories in the backlog. See blog 6, Teams Deliver Features, for the details of how the product owner does that.
The product owner shepherds the business value of the roadmap and the team’s backlog so the team always delivers the most valuable work.
How Roles Change in Agile Projects
Agile approaches demand changes in the project manager’s role and the product owner’s role. The team decides how to do its work. The agile project manager facilitates the team and its process. The product owner (a new role in agile) decides what to do and when the team should deliver that work.
These changes can lead to problems in expectations and in how the team works. I’ve seen expectation problems such as these:
The product owner thinks the team doesn’t need the stories broken down into something the team can complete each day (or more often).
The product owner thinks the team cannot help write stories.
The product owner thinks the team doesn’t need to address the legacy problems it may have.
When the product owners don’t understand their roles, the agile project manager can help the product owner understand what to do and how to treat the team. The project manager can see if the team is struggling with too-large stories, and can facilitate the product owner creating smaller stories.
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 got 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.
Recognize Leadership Traps
As a leader, you might not want to think about leadership traps. Aside from the obvious—acting in a controlling manner as opposed to a serving manner —many of the traps I’ve seen have been about product ownership. Here are the traps I’ll highlight:
When the team has several people who act as the product owner.
When the team has no product owner.
When the team has a business analyst who masquerades as a product owner.
These traps prevent team members from knowing what they need to do when.
Trap: One Team Has Several People Acting as Product Owner
I’ve encountered several organizations where the product manager “owns” a product, and negotiates for people to work on that product. Of course, that means begging, borrowing, stealing people from other projects, and lots of multitasking. It also means that specific people have very specific knowledge of products or pieces of products, and it’s way scary for these product managers to consider allowing other people to work on their products.
This situation can devolve into several product managers working as product owners for one team. The team is supposed to work on Product Manager 1’s project and Product Manager 2’s project.
Sometimes the team splits into the different projects. That means the team needs to be large enough to split.
Sometimes the product managers collaborate on one joint backlog for the team and rank all the stories.
Sometimes they ignore the other product managers and assume the team works on just “their” stories.
It’s a mess.
Instead of having multiple product managers talk to a team, ask one product owner to represent the rest of the organization. That product owner can make the stories small enough that the team can finish stories often. Even better, have the managers manage the project portfolio so that the product managers are not at odds with each other, competing for the same teams.
Trap: Your Team Has No Product Owner
What happens when you have no product owner at all? How does a team know what features to develop and in what order?
I’ve seen several patterns of “no” product owner:
The team has a product manager who can work with the team up to a few hours every couple of weeks. That product manager assumes a full-time business analyst can fill in for the product manager. However, the product manager is the one person who can accept stories, and that person is not available on a regular basis. Too often, the business analyst does not have enough domain expertise or customer experience to decide for the product manager.
The team’s manager or a different manager in the organization acts as the product owner. That might work, but eventually, the management work overwhelms the manager.
The team no longer has a product owner. I’ve seen these other problems also: managers do not understand the real acceptance criteria; managers do not know the correct ranking of the stories; and, if the manager is a technical manager, the manager is too interested and involved in the how of the story instead of defining the what and when for the story. When managers work that closely with the team, they may well inhibit team safety by deciding for the team instead of with the team.
The team shares a product owner with another team and that product owner doesn’t quite understand what this team’s feature set is.
Every team needs a full-time product owner. That product owner is a responsible person who can create and rank the backlog so the team knows the order of the work. Without that person, the team does not know what to do and when to deliver that value.
Without a product owner, the team loses something precious to agility: the customer collaboration as part of working with the customer or customer surrogate. The team loses the back-and-forth about the product that the customer or product owner helps the team understand. And there’s no one who can rank the work the way a customer would.
Even when teams use managers instead of product owners, the manager is not the customer. The manager is not the person who can set the real acceptance criteria. The manager can see the demo, but the manager cannot say for sure that the team is developing the correct requirements in the correct order.
A team without a customer or product owner is not agile. The team might use iterative and incremental approaches, but it doesn’t have an agile culture. Agile approaches separate who “owns” what. The customer or product owner owns the decisions about what problems the team should solve and when by creating roadmaps and ranked backlogs. The team owns the architecture and design decisions about how to solve these problems. A team without a customer or customer surrogate does not maintain that separation.
When the team manager gets involved, that allows the “business” to be unaccountable for developing the system. How do you know what is a shippable product without the responsible person?
The problem is this: product development is a joint venture between the business people and the technical people. We need legal, marketing, sales, and anyone else on the “business” side of the house to help us with the what-and-when-to-build decisions. That’s why we need a responsible person. In Scrum, that person is called a product owner. And we need a technical project team to deliver the value. We use agile as an approach and use the demo because it shows business value every iteration.
When the business is unaccountable, the agile ecosystem breaks down. We no longer have ideas coming into that funnel, as illustrated in the “general agile picture” here, being evaluated by that responsible person. Sure, that responsible person has a lot to do. And that responsible person should develop product roadmaps and make the potential product direction transparent to the rest of the organization. That way, the next iteration or two is clear for the team, and everyone can discuss the product direction.
Feature teams cannot know the strategic intent for a given product. Feature teams tend not to discuss product strategy. Or the discussions go off in a different direction than the product needs to go. And that’s a very bad thing.
Because when the discussions about product strategy don’t occur, the technical group takes all the responsibility for the product: for what to build, when to build it, and how to build it. And that means we have let the rest of the business abdicate all of its responsibility for their part of the product. That’s not the partnership or the transparency agile promises us.
You might be on the road to agile approaches if you have no product owner. If your team is better off, terrific. But don’t fool yourself. If you want to become even better at delivering, you need a product owner who can represent what the organization needs now and later to define and rank the features. That person cannot also perform technical work for the project. Without a product owner, your team is missing a key cultural transformation that allows agile to succeed.
What if this is the best you can do?
Trap: Your Team Has a Business Analyst Masquerading as a Product Owner
Many organizations have the problem of not enough product owners. The organization’s managers think the business analysts can act as product owners, especially if the business analyst has the backup of a product owner.
I have yet to see this work. Inevitably, the product owner is not available— often because the product owner is the product manager, not the product owner. (The product manager is an external-facing position. The product manager visits with customers, gathering data about what should be in the product as a whole or in the next generation of the product. In contrast, the product owner is an internal position, a person who works with the team, providing details about the next stories and insight into the future.) Unfortunately, the team suffers the lack of a product owner.
Business analysts have a place, and that place is often with the product manager, understanding what the customers want and turning those desires into roadmap features. It’s possible your business analyst can work with the product owner and create small stories. One of my clients defines a bazillion business rules for a given release. That client finds the business analyst can define the business rules and acceptance criteria to go along with the rules.
The worst part of this trap is when your management thinks the business analyst is sufficient for your team’s needs. If you think you have a business analyst masquerading as a product owner, try these options:
Count the number of times a story goes into a clarification wait state, such as “waiting for an explanation,” or “waiting for acceptance criteria.” Your product owner is not clarifying the story.
Look for causes of a relatively high number of fixes that don’t stay fixed, as discussed in Measure the Fault Feedback Ratio. One cause might be an insufficient clarification of the feature.
The product owner cannot lead the story-definition work. The product owner does not have the authority to define stories in any meeting, whether that meeting is a requirements workshop, the backlog refinement meeting, or the planning meeting.
Every agile team deserves one responsible person (and no more than one) to decide what to do and when.