Chapter 4. Describing the Different Roles

It is important to understand the different roles that are used in Agile because they lay the foundation for how the work is delivered; detailing the responsibilities of each role shows how the Agile principles are brought to life in organizations of various sizes and complexities. In this chapter, we first explore the roles within Scrum, the most widely used Agile methodology (VersionOne 2013) and deep dive into the descriptions of the product owner, the Scrum master, and the Scrum team. With that foundation, we can then discover other roles and methodologies and how they approach the delivery of working software to key stakeholders and customers.

Roman Pichler, who has published many articles and books on the topic of the product owner, and who is also one of the interviewed guests for this chapter, describes the role as follows: “As the name suggests, a product owner should own the product on behalf of the company. You can think of the product owner as the individual who champions the product, who facilitates the product decisions, and who has the final say about the product, for instance, if and how feedback is actioned, or when which features are released” (Pichler 2010a).

Turning the product vision into an actionable project is accomplished by creating and maintaining the product backlog, which is the core responsibility of the product owner. The product backlog contains all of the requirements for the project in priority order to ensure that the team is always working on the most important things. The product backlog is described in detail in Chapter 5, “The New Way to Collect and Document Requirements.” One of the key differences with Agile, and specifically Scrum, is that the requirements are broken down into small units of work called “user stories”; the product owner writes these user stories to capture the most urgent needs of the desired customer. As the marketplace, competition, and customer expectations change and evolve, the product owner can easily react by changing the priority of the work units in the backlog. The ability to seamlessly respond to change without disrupting the development process is one of the things that make Agile so enduring.

The practice Scrum adds is that only one person is responsible for maintaining and sustaining the content and priority of a single Product Backlog. Otherwise, multiple conflicting lists flourish and the Scrum teams don’t know which list to listen to. Without a single Product Owner, foundering, spin, contention and frustration result. (Schwaber and Beedle 2002, p. 34)

• Built a landing page for site visitors to come to

• Added a way to pull in or import the latest weather information

• Created a page to display that information

It may seem a bit simplistic, but we wanted to start with the basics and get our product to market quickly, knowing that we can add features in future sprints.

The product owner knew that, for the initial launch, the target market was largest in New York City, and Cayman Design needed to provide only weather for New York City to satisfy the most urgent business need. Then following the initial launch, the product owner will prioritize other features that can be released in a more iterative manner. The concept of being able to iterate, continuously grow, and improve an application is central to the benefits of Agile.

• We want to add more cities so our application will appeal to a broader audience.

• We want to add features that will drive revenue and help monetize the site, such as selling weather-related calendars.

• Our IT teams have found that the code they have written to import the weather data is too slow, and they need to “refactor” the code to increase the processing speed.

Each one of these three efforts is important and valid, so how do you know which one to work on first? Within Agile, the main driver of priorities should be business value. Business value can take a number of forms, such as the following:

• Increased revenue

• Expansion of addressable market (i.e., with this new feature, more people will be interested in buying it)

• Decreased cost

• Increased customer satisfaction

• Increased processing speed

• Increased stability of the application

• Improved usability

The important thing about business value is that it is understood, articulated, and measured (when possible.) The reality of the workplace is that subjective measures may come into play, such as political pressure, executive opinions, or power within the organization. Although these types of things certainly happen, the goal of Agile is to be as objective as possible, always striving to increase business value.

The product owner must balance all of these inputs to determine the next effort that the Scrum team will work on, thereby setting the priorities. It is important that the product owner be precise in the prioritization setting as well, truly defining the number 1 and number 2 priorities, and so on; simply bucketing work into high, medium, and low categories is not detailed enough (Cohn 2004, loc. 2102).

In our example of Cayman Design, the product owner determined that a web site displaying data for New York City was sufficient for an initial release. Once the product is in production, new features can be released as soon as they are available. For example, we could add cities to increase the number of customers that we can attract; this is referred to as “increasing the addressable market.” As soon as the data for Boston is imported and tested, then Boston can be released into production.

However, other features might be more complex, requiring several sprints to complete. These features would need to wait for a formal release, as opposed to being pushed to production after each sprint or iteration. If we look at the weather calendars that Cayman Design wants to offer, there are a number of component pieces that must all be delivered in a single release for the feature to work correctly. For example, one sprint may be dedicated to inventory management—making sure that the calendars are available and can be shipped in a timely fashion when an order is received. A second sprint may be dedicated to payment processing—ensuring that credit card authorizations are handled appropriately and that a process is in place for credit card declines. Yet a third sprint could be dedicated to e-mail confirmations of orders received and order shipment information. The work done in these three sprints could be held in a testing environment until all are available, and they would be pushed to production together—as part of a single release.

It is the responsibility of the product owner to determine what constitutes a release and then manage the feature set within that release.

The person who plays the role of product owner can vary depending on the organization. For example, the product owner may be a product manager, if the company has a formal product management organization. Otherwise, there are several other ways to fill this role. First, you can have business analysts (BAs) serve as product owner, and these BAs can be in either IT or other organizations. People in account management who are responsible for engaging with current customers can be a fit too. If the development work being undertaken is more operational in nature, then someone with operational expertise can fulfill this function. As long as care is taken to create a solid feedback loop, then the product owner can come from many areas of the company.

To examine the first instance, what are the advantages and disadvantages of having one product owner responsible for multiple products? The biggest risk factor is time and attention. Can the product owner devote adequate time to every product that he or she is responsible for? Does this person have the necessary depth of understanding to truly collaborate with IT on the best solutions? It is a risk, but certainly one that can be overcome.

In the instance where the product is large enough to have multiple product owners, there is a chance that the priorities will not align. Related to the previous reference of business value, if one product owner wants to expand to new cities to attract new users but another product owner places top priority on improving the processing speed, then you can run into conflicts. However, one of the core tenets of Agile is collaboration, which includes collaboration between product owners. Product owners need to be in communication with each other to clearly articulate the best plan for all groups—knowing that at any given time, one group’s needs will take precedence over another’s.

Even if you have a single product owner for every product, that does not mean that things are easy. Between systems there are interactions, and to create a new feature or make a modification, the product owner may need to consider dependencies.

Using our Cayman Design example, the product owner has decided to place the highest business value on driving incremental revenue. Thus, the weather application that Cayman Design has offered will have an additional feature allowing their end users to purchase weather calendars that provide statistical information for the next 12 months based on historical data and trends. To sell these calendars, the front-end web interface needs to be designed to take order information from a consumer; the order is then sent to a back-end order management application where the data is stored and the product purchase is fulfilled.

From an Agile perspective, there may be one product owner for the front-end web application and another for the back-end order management system. To be able to sell these calendars, enhancements will need to be made in both systems. The two product owners will have to collaborate to make sure that the timing of the enhancements is aligned. It does not necessarily mean that the changes to the two systems have to happen at the exact same time, but it does mean that they need to be coordinated, tested, and launched in concert.

Here are a few other examples:

1. The team in the next aisle plays music while they are working, and they play it so loud that it causes you to lose your concentration. Rather than try to work through it or create a scene by shouting that they need to knock it off, the developer can let the Scrum master know of this impediment, and the Scrum master can coordinate with the other team to find a workable solution; it might be the investment of headphones, or setting a specific time when playing loud music is acceptable.

2. The product owner that you work with does not always provide complete information, and you have questions. But he or she is in meetings all the time, so you spend hours trying to find the person to get your questions answered. This is another perfect item to give to the Scrum master as an impediment: The Scrum master can find a solution that might involve daily meetings with the product owner, setting specific times when the product owner is available, or working out a system via instant message or text message for quick direction. Whatever the appropriate solution, the Scrum master is responsible for clearing the impediment so the developer can write code.

3. Members of the organization stop by your desk to ask questions because you are the subject matter expert (SME) on a particular item; this happens frequently in the workplace and can be a true productivity killer. The people doing the interrupting have valid reasons for doing so—there is a customer waiting on an answer, another team cannot proceed because they need additional information, an executive needs input for something he or she is working on—but the act of stopping what you are doing and shifting to the topic of the question makes it challenging to reengage once the question is answered. The Scrum master can serve as a blocker for this type of activity, by either answering the majority of the questions or creating a predefined timeframe when answering questions will not be disruptive.

There is significant value in having a team member who can remove these types of roadblocks so that developers can spend the majority of their time writing code. The ability to tackle these issues requires determination and stubbornness (Schwaber and Beedle 2002, p. 32), so selecting the right person for the role is important.

Another example is adherence to the meeting schedule, which is explained in detail in Chapter 8, “Tracking and Reporting.” One of the meetings that is part of the Scrum process is the Sprint retrospective. This meeting takes place at the end of each sprint, and it is a time for the team to reflect on what went well in the last sprint and what needs improving in the next sprint. This is a meeting that can be dismissed as unnecessary, but it is actually vitally important to the Agile process. It is the Scrum master’s job to make sure that the team does not cut corners that diminish the effectiveness of Agile.

The Scrum master also needs to hold the team accountable for honoring their commitments. If the team is not completing testing or documentation, the Scrum master needs to work with the team to improve their performance and address any root causes that might have led to the lapse.

Jeff Sutherland (2010), a signer of the Manifesto, recommends full-time assignments, but sees opportunities for flexibility for smaller teams, where the Scrum master is also a working member of the team. Mike Cohn, a well-known author and expert on Scrum, would prefer that a Scrum master serve in only that role, but if there is bandwidth for additional responsibilities, the Scrum master should lead more than one team (Cohn 2010, p. 124).

If you have a natural leader who enjoys playing the role of Scrum master, then the continuity and consistency of that assignment can be quite beneficial. However, if you have an experienced team who are disciplined about their adherence to Agile practices, then rotating the Scrum master duties might provide a nice variety for the team.

In most instances, though, the Scrum master is a challenging and significant role that deserves respect (Cohn 2010, p. 122). Therefore, organizations in the early stages of adopting Agile should not explore part-time or rotating Scrum masters until they have matured their Agile practices sufficiently.

• Technical Lead or Lead Developer

A common choice for a Scrum master is the person on the team who has demonstrated a capacity for decision making by being the lead developer or the technical lead. These people are usually very proficient at the application and are adept at solving complex problems, so they naturally rise as potential leaders. Whether they are a good fit for the Scrum master role depends on their personality and preferences. First, they must be willing to coach and collaborate with team members versus making decisions and dictating to the team. Also, they must be comfortable with the visibility of the role, because it often requires more interactions with management and other departments.

• Project Manager

Some project managers are a natural fit to morph into Scrum masters, but that is certainly not always the case. The project manager’s role in a Waterfall environment is typically that of accountability and enforcement. The project manager would likely have a detailed project plan clearly outlining due dates and task owners. That person’s job is to make sure that everyone completes their tasks on time and as expected; this is very different from the role of Scrum master, who needs to serve as a coach and a collaborator (Hunton, 2012). When an unexpected problem arises, some project managers approach it by completing risk matrixes and reassigning tasks and establishing a new timeline, while escalating the occurrence to upper management. The Scrum master would take an entirely different approach: collaborating with both the team and the product owner on what they learned and how it could affect the product. By working collaboratively, the Scrum master would seek a new solution and would actively participate in brainstorming and creative problem solving.

Some project managers can easily make the shift from the command and control practices often associated with Waterfall projects to being collaborative in an Agile environment, but it certainly is not always possible.

• IT/Functional Manager

Another often debated subject is whether the Scrum master can or should be the IT manager. Again, this depends entirely on the makeup of the organization. As we demonstrated in Chapter 2, “Organizational Culture Considerations with Agile,” moving from a Waterfall environment to Agile can have serious implications to the organization and culture. If your organization has been in Waterfall for quite some time, then you might have IT managers who are accustomed to making all of the decisions. They might be more comfortable assigning tasks and managing the Scrum team as individual employees, rather than a team; if this is the case, then the IT manager should absolutely not be the Scrum master. The team will never find its own rhythm if they are being managed in a Waterfall manner. In fact, on many Scrum teams, the managers are not allowed to attend the Scrum meetings, or if they do, they are not allowed to speak.

Conversely, if your team is new or you are working in more of a start-up environment, then it is perfectly acceptable to have the IT manager double as the Scrum master. This makes particular sense if you are constrained in your resources.

Who makes the best Scrum master? As with most things in Agile, the answer is—it depends. Good Scrum masters can be developers, quality assurance (QA) folks, or BAs. In fact, the Scrum master does not even need to be in the IT organization. There have been successful models where the Scrum master is an analyst from account management or a customer service organization. The important thing when choosing your Scrum master is that the person should be able to remove impediments, minimize interruptions, lead the team, and enforce the principles of Agile.

• 5 fingers = I am all in. I completely agree.

• 4 fingers = I buy into the option and I will support it.

• 3 fingers = I have some reservations, but I can support the decision and move forward.

• 2 fingers = I have reservations, and I cannot support this decision without further discussion and clarification.

• 1 finger = I cannot support this decision. I completely disagree.

The fist of five allows all team members to show their level of support so there can be no “quiet dissenters” or people who say nothing in the meeting and then sabotage the decision afterward. To use a classroom example, if you work on a group project, you may need to decide which language you are going to write an assignment in for a software development class. Your team decides to use Java, and as you are coding, you run into some troubles. The team member who acts as the dissenter might say “I always thought we should have used .NET, but nobody listens to me.” Fist of five deals with this type of situation at the time the decision is made. The team will decide on Java and everyone on the team will vote. As long as everyone shows 3, 4, or 5 fingers, the team is free to proceed. If anyone shows a 1 or a 2, the team needs to stop and discuss the issue further. The team should not move forward until every team member is at a 3 or higher. Another common problem that fist of five solves is the team dynamic with introverts and extroverts. There are people who are naturally quieter in their demeanor and do not want to interrupt others or jump into a heated debate; fist of five allows those people to have their voice heard in a very nonconfrontational manner. By simply holding up a “2,” that person now has the opportunity to express concerns or ask critical questions.

Michael James (2010) describes the value of self-organizing teams quite well in the Scrum Reference Card:

Self-organizing teams can radically outperform larger, traditionally managed teams. Family-sized groups naturally self-organize when the right conditions are met:

• Members are committed to clear, short-term goals

• Members can gauge the group’s progress

• Members can observe each other’s contribution

• Members feel safe to give each other unvarnished feedback

Another critical difference between Waterfall and Agile is the handling of task assignments on self-organizing teams. Once the sprint has been groomed (described in detail in Chapter 6), the team members can select the tasks that they want to work on. This ownership of task assignment is a huge departure from Waterfall, where the manager often told each developer what he or she was expected to accomplish. The ability for each team member to pick assignments leads to significant lifts in job satisfaction. It also invites the opportunity for cross-training, because less experienced people could request tasks that they would like to learn, and they can be mentored by the more experienced members of the team. This is all positive, but it is worth pointing out that all of the work still needs to get done, so although the team is self-organizing, they cannot neglect certain less desirable tasks, such as documentation. How the team chooses to assign documentation, though, is within their control.

However, there are some resources that would not have enough work if they were assigned to a single Scrum team full-time; examples are the database administrator (DBA) and the user interface (UI) designer. Often, a DBA resource may be required for only a few hours during a sprint, and as long as the team has access to a resource when needed, there is no need for the DBA to join the team full-time.

The point of this cartoon is that some people in the Scrum process have a higher level of commitment (pigs) than others (chickens) based on the nature of their work. For example, developers are pigs: “Team members commit to a goal and do the work that is required to meet it. They are called pigs, because they, like the pigs in the joke, are committed to the project” (Beedle and Schwaber 2002, p. 42). This commitment cannot be taken lightly. It is a promise, and the developers know that if something goes wrong, they might have to work long hours in order to deliver on that commitment. They are, in effect, putting their reputations on the line every time they make a commitment. The more promises that are kept, the more the team’s reputation in the organization goes up; but if several promises are missed, then the team is held in lower regard. Hence, the developers are pigs because their level of commitment is absolute. Chickens, on the other hand, are definitely interested in the project and want to see it succeed, but their reputations or careers (or proverbial “necks”) are not on the line. The best way to describe these terms is through an example.

Product owners are great to look at because sometimes they are chickens and sometimes they are pigs. First, the team gets together with the product owner to determine the priorities for the next features that will be worked on. The product owner has to be knowledgeable about the feature request and the business value that it will bring to the company. He or she must be able to articulate exactly the reasons for advocating for one feature over another with information (not opinions) and must be ready to answer clarifying questions for the team. In this discussion, the product owner is clearly a pig: He or she is heavily invested in and committed to the outcome.

The next step is for the Scrum team to discuss coding options and different ways they can design the solution that the product owner is advocating. They could get into a heated debate, for example, over the technology design. When the Scrum team is getting into the details of the coding options, the product owner turns into a chicken: Although this person’s input may be interesting, it is not the product owner’s decision on the technology. That belongs to the team writing the code, and they are the pigs.

As is discussed in Chapter 8, there are even meetings where chickens are not allowed to speak. Although the naming convention is a bit silly, it works well in practice because you could literally stop a meeting and ask, “Are you a chicken or a pig?” and everyone will know the distinction you are making. It can move the conversation along with greater productivity than if every person in the room carried the same amount of influence.

Let’s look at Keith, who was assigned as the product owner to an application that had several high-profile and demanding clients. Keith researched all of the necessary competitive and market information so he could ascertain the best prioritization for the development work that needed to be done. An account manager who handles one of the high-profile clients did not like Keith’s prioritization because something the client wanted was not at the top of the list. Keith was very deliberate in his analysis, and he believed that the requested feature would not be adopted by others in the marketplace—it would really apply just to this one client, almost as if it was custom code; therefore, he put other features that he believed would drive more business value ahead of the requested client feature. But that did not satisfy the account manager, because she thought her client’s request was vitally important. So she pleaded with Keith again and again: She called him and sent him e-mails and held meetings and pestered Keith relentlessly to try to get him to change the prioritization. Finally, in a moment of frustration, Keith said, “Fine. You go talk to the IT manager of the development team. If she thinks they can get it done, then so be it.”

Keith was having a bad day, and in that moment was a very bad product owner. The product owner sets the priority for the work of the IT team based on knowledge and research of the marketplace and what will drive the highest business value. Further, the product owner must collaborate with all of the constituents to “sell” the prioritization. He or she must gather input from a number of sources, including account management. It was Keith’s decision—and his alone—as to whether the client request would be prioritized high on the list; by deferring to the IT manager, he was shirking his responsibilities. He should have either convinced the account manager that his backlog was prioritized correctly by articulating the business value of the high-priority items, or, if he could not do that, then he should have reprioritized the backlog to move up the client’s task, based on the information learned from the account manager. Being a product owner is a difficult balancing act, but the role is critical and must be performed well for Scrum to be effective.

By contrast, Kelly is a great product owner. She actually moved her desk to sit with the Scrum team so she could be immediately available to answer questions. Kelly spent a portion of her time with the account managers, salespeople, and actual customers so she could stay on top of how customers were using the product and what problems they were having. She also learned from the salespeople what objections they were hearing from prospective clients. She was able to distill all of that feedback into the user stories that she created. She understood which features would drive the most business value so she could effectively prioritize. Kelly also listened to her Scrum team and understood enough about the technology to contribute to the discussion around various choices that could solve a particular problem. The best product owners have enough technical expertise to be able to follow a technical conversation and contribute salient points to the discussion. They do not have to be developers by any means, but they should demonstrate a technical aptitude.

Consider Steve. He was brought in from another team to be the Scrum master of a team that was really struggling. Steve started by getting to know all of the developers on his team. He met with each person individually to learn his or her impressions of the problems. Then Steve began actively advocating for the team. When decisions were not being made in a timely fashion, Steve escalated the issue so his team could get the answers they needed to write the best code. When the team had a disagreement, Steve jumped right in and facilitated a healthy but heated discussion about how to solve the problem. When required to make decisions, Steve gathered the best information available at the time, consulted with people internal and external to the team to check his facts, and then chose a path, informed all parties, and stood behind his decision when it was questioned. His leadership allowed the team to focus on the code they were designing, writing, and testing so that they could meet their commitments and feel a real sense of accomplishment. Steve is a great Scrum master.

Steve’s team sits very near Ray’s team, who is not sharing in their success. Ray is the Scrum master, and he has a rather timid personality. When conflicts on Ray’s team arise, he watches nervously and encourages everyone to be nice but he does not help them resolve the problems. He acts more like a disengaged referee. Ray’s team has two very strong, dominant personalities and two very introverted and quiet people. Ray does not like confrontation, so when the two strong personalities dominate the conversation, he allows it to happen. Therefore, the more timid people do not say anything and just go along because they do not want to rock the boat. This is very unfortunate, because the two quiet developers are quite knowledgeable about the system, and they have noticed flaws in the design of the code. The strong personalities do not seem to understand or care about the risks, which jeopardizes the entire effort. Because Ray allows this dominance on the team, he is part of the problem instead of being part of the solution. For a Scrum master, avoiding confrontation is not healthy or helpful. Confrontation does not have to be negative; it can be respectful and lead to the best deliverable. Ray is not an effective Scrum master, and he is jeopardizing the success of his team.

The green team has a team member, Joe, who is very smart, so much so that the rest of the team has trouble keeping up with him when he gets going on an idea. Joe is almost always right in his direction but he processes information in his brain so quickly that when he talks, it is a bit like gibberish to the rest of the team because he does not clearly state how he got from problem to solution. On some teams, this type of savant could be extremely frustrating because when Joe talks, the team rarely understands what he is saying. But the green team is highly effective, and they recognize and value the intelligence and ideas of their super-smart colleague. They brainstormed the right way to allow Joe to communicate his ideas and thought patterns. They painted all of the walls in the area with white board paint, which allows you to write on the walls and then erase when you are done. They encouraged Joe to write down his train of thought in solving a particular problem. This allows the rest of the team to slowly digest what he is conveying, and they have a written record to access when they are trying to recall a specific detail. The green team rallied together and found a solution that would allow everyone to actively contribute and drive toward the best possible solution.

The blue team, on the other hand, is not optimized. They have a member, John, who is equally talented but far more disruptive. John is negative and not a team player. He is dismissive of every idea that is not his own. John is very intelligent and knows the system very well, so his behavior is tolerated even though he is so negative. The sense is that the team could not do without him because of his expertise, but his presence has created a tense and unproductive work environment. His team members are reluctant to confront him because he is so aggressive in his negative demeanor. The issue of John’s attitude has been raised with both the Scrum master and the IT manager, but neither are willing to address the problem because they fear losing his expertise on the system. As a result, this team operates in a constant state of fear. They do not know how John will react in any situation, so they all retreat and wait for his reaction before they express their own opinions. The team is failing to meet any of its deliverables because no one can commit to certain tasks when John is behaving like a bully and driving all of the discussions. This is an ineffective team who would be far better off if John was removed. They might suffer a bit from the lost expertise, but they would gain far more by being allowed to brainstorm and work together.

What is interesting is that all of these examples come from a single company. Within any Agile implementation, there are both things that go well and areas for improvement. Every team, every Scrum master, and every product owner should always be aware of opportunities to learn, improve, and be more effective.

For example, one obvious stakeholder is the leader of the sales organization. How the product is developed, the features that are included, the timing of the release, and the scalability of the application are important data points for sales to know and potentially influence. It is the product owner’s responsibility to gather input from sales to consider in the prioritization of features and release management.

Other examples of stakeholders could include the leaders of the following types of organizations:

• The operations team, who will be responsible for on-boarding (or turning on) new customers

• The customer service representatives (CSRs), who must support end users who call in with questions

• The technical help desk, because they will take technical questions from internal and possibly external users

• The finance or billing organization, which is tasked with billing customers and thus booking the revenue

There can be many others, and virtually every organization within a company may have some stake in an upcoming project, depending on the size and scope of the effort. Stakeholders are critical because their impressions, whether they are correct or incorrect, of how a project is proceeding can influence funding, timelines, team resources, etc. It is essential to recognize and appreciate the role of the stakeholders.

• The project manager must plan for and track all aspects of the product release. Within a highly evolved Scrum team, the Scrum master would own all of these activities.

• Project managers are responsible for securing the approval and the funding for the project and providing all of the necessary paperwork and tracking mechanisms against that approval. In an Agile organization, the product owner would ensure that all funding was in place to accomplish their vision for the product.

• The project manager also manages project risks and issues. Within any given project, there will always be unforeseen items that come up, and it is the project manager’s role to document issues as they arise. Risk planning is important and can make a big difference to a project. If the Scrum team is high functioning, they will anticipate and mitigate risks.

• The project manager is tasked with communicating status. This is a large and important role, because transparency is critical within Agile practices. Communication regarding the team and the sprint progress would belong to the Scrum master; communication with stakeholders on product features and release management would be the responsibility of the product owner.

Although it is true that all of these functions could (and perhaps should) be managed within the existing Scrum roles, most organizations have not yet reached this level of maturity with their Agile practices, so there is still a place for the project manager role.

As already described in detail, the product owner fills this role in Scrum. The name encompasses the essence of this particular function—this person “owns” the product. Lean software development also defines this as the product owner.

Within XP, this role is referred to as the customer because he or she represents the needs and priorities of the ultimate end user (Chromatic 2003, p. 59). Those in this role are responsible for understanding what end users really need, how much they value it, and what they will pay.

In feature-driven development (FDD), the role of requirements gatherer is split between two titles: the chief programmer, who is responsible for prioritizing the work to be done, and the domain experts, who know the application in great detail and can articulate the business needs to the developers (Palmer 2013).

In DSDM, this responsibility is also divided between several roles. The visionary understands the long-term direction and the ultimate goal for the product. The ambassador user acts as an ambassador for the end users and makes sure their needs and priorities are considered. The advisory user will be more focused on the usability and workflow details for the product (Wikipedia 2013).

In other methodologies, the requirements gatherer is not a specifically defined role but rather is included in the collaborative discussions regarding the project. For example, within Crystal, the end users (customers) interface with both the user interface (UI) designers and the business analysts, so both would be responsible for collecting, documenting, and prioritizing the project goals and requirements.

Within XP, this type of function is split between two roles, the coach and the big boss, but one person may cover both. The coach is viewed as the mentor to the team; he or she has earned the team’s respect and leads by example (Chromatic 2003, p. 64). The big boss is responsible for holding the team accountable and ensuring that they do what they say they are going to do (Beck 2000, p. 84).

Within DSDM, the role is split between the team leader and the coach. The specific responsibilities of the team leader include working with the team on the immediate deliverables—the day-to-day activities, timeliness of deliverables, and full team participation (Caine 2013); the coach is focused on ensuring that the team understands and embraces the principles of Agile.

Crystal does not specifically define this type of role.

What makes this team coach role unique within Agile is that it does not correlate to any management responsibilities. The coach, or Scrum master, does not make decisions about hiring and firing and does not own the preparation of annual reviews or appraisals of the team members’ performance. Instead, the coach’s role is to make sure that everyone on the team is actively participating, has what they need to do the job (information, tools, support, knowledge, etc.), and is fully engaged in the end deliverable. The inclusion of this type of role has proven quite impactful because it encourages the people doing the work, in this case the developers and testers, to have a voice in their work environment and the product deliverable. This type of active engagement is a big departure from the Waterfall world, where managers simply told developers what to work on.

Large organizations may need several roles, as required by the technical complexity of the environment, such as an enterprise architect or an application owner.

Enterprise architect is a role in IT with the task of making sure that all of the projects will stitch together in an architecture that can be maintained. The person in this role worries about integration, scalability, response times, enterprise hardware strategies, and enterprise-wide disaster recovery.

An application owner may be required if multiple development teams are working on a single application. They have the same responsibilities as the enterprise architect but for a specific application. This role has to make sure that application testing and the code integration are tightly monitored.

However, other roles may or may not be included. An example is the user experience designers [UX designers, sometimes referred to as user interface (UI) designers or usability professionals]. This role will be essential on teams where mapping the end user experience is central to the success of the product or feature. These people may be assigned to a team full-time, but more often they float between several development teams because their expertise is somewhat rare and must be shared across the organization. In the Crystal methodology, the UX designer is a specifically defined role that is always part of the team. Crystal also specifically recognizes a programmer and a tester. Within DSDM, there are named functions for a solution developer and a solution tester.

Feature-driven development has perhaps the most interesting split of the development team by introducing the concept of “classes.” This is best described in contrast to XP and Scrum.

XP, like Scrum, includes a practice called collective ownership—the idea that any developer can update any artifact, including source code, as required. FDD takes a different approach, in that it assigns classes to individual developers, so if a feature requires changes to several classes, then the owners of those classes must work together as a feature team to implement it (Ambler 2013). Therefore, within FDD, there are class owners in the development teams.

• A start-up company with limited resources and one Scrum team

• A mid-sized company with multiple teams but who are working mostly on stand-alone applications

• A large multinational company with multiple Scrum teams working on a single application

• sales leader = project sponsor/key stakeholder

• business analyst = product owner

• IT manager = Scrum master, enterprise architect, application owner

• four developers and one tester = Scrum team

The project sponsor sets the overall objective, scope, and budget for the effort. The product owner gathers the requirements, interviews prospects, goes on sales calls to learn more, and prioritizes the items that will add the most business value to the top of the backlog. The product owner also works with the Scrum master (who in this case is also the IT manager) to manage the timelines and risks and reports status to the key stakeholder. The Scrum master organizes the team, removes impediments, reduces interferences, and clarifies issues with the product owner. The enterprise architect (who in this case is the same person with the Scrum master responsibilities) ensures that this development effort will fit in with the larger ecosystem and ensures that all of the necessary hardware and environments (development, QA, and production, as examples) are all in place. The team consists of the developers and the QA tester. The team’s membership is fixed (there are no other people), and the tester is responsible for testing both this code release and the integration to existing code.

This is an example where a few people are playing multiple roles, but it can and does work for a number of smaller organizations. As the company grows, additional head count can be added to augment the team and spread the roles to more people.

• sales leader = project sponsor/key stakeholder

• account management leader = stakeholder with an emphasis on existing customers and feature enhancements that they desire

• product manager = product owner

• IT manager = IT manager

• Scrum master = Scrum master

• Agile coach = Agile coach

• enterprise architect = enterprise architect

• six developers and two QA = Scrum team

In this example, the product owner meets with the sales leader and the account management leader to determine the size, scope, timing, and funding for this development effort. The product owner begins to write requirements/user stories with input from many across the organization.

The IT manager assigns members to the Scrum team and ensures that the team is fully staffed. The IT manager will handle all personnel issues, such as performance management (appraisals/reviews) and any hiring decisions.

The Scrum master assembles the team, and he or she works closely with the product owner to make sure that all requirements/user stories are understood and prioritized. The Scrum master and product owner also coordinate to track the project progress and any identified risks and report back to the stakeholders on a regular basis.

The Agile coach meets with the Scrum master and the team both to ensure that members have what they need and are adequately trained and to answer any questions. The Agile coach may also share best practices or lessons learned from other Scrum teams within the company, since he or she has a broader view of the activities.

The Scrum team designs and develops code to meet the business requirements identified by the product owner.

The QA testers test the code as it is developed and ensure that each sprint culminates with code that is ready to be deployed, according the release plan as defined by the product owner.

The release date is met, error-free code is deployed, sales has what is needed to drive revenue, and everyone is happy.

• VP of customer support = project sponsor/key stakeholder

• chief information officer (CIO), chief financial officer (CFO), head of sales = stakeholders

• director of product management, sometimes called the chief product owner (Cohn 2010, p. 328) = lead product owner overseeing efforts of all six teams

• product manager = product owner per team

• IT manager = IT manager, possibly over more than one team

• Scrum master = Scrum master per team

• Agile coach = Agile coach

• enterprise architect = enterprise architect

• application owner = application owner

• various subject matter experts (SMEs) to assist with workflow decisions

• six Scrum teams

In this example, the VP of customer support, working closely with the application owner, defines the work streams and the high-level milestones and assigns work streams to teams. The stakeholders all review and agree on the work stream breakdown and the milestones.

The enterprise architect crafts a plan for how all of the component pieces will fit together from an infrastructure perspective before any major code is written. The resulting architecture will influence all of the teams and their direction. The application owner will ensure that the milestones and activities of the individual teams work in concert toward a united goal of a single CRM system.

Each of the six teams will have a product owner who will be responsible for writing user stories/requirements for their respective team. The director of product management/chief product owner oversees the activities of all six product owners, making sure each understands the priorities of the product backlog and how the components will fit together for a cohesive end user experience. Each team will have a Scrum master who will ensure that their team is working effectively and will remove any impediments that come up along the way.

Because of the size of this project and the complexity of multiple teams, it is a good idea to have an Agile coach onboard who can float from team to team and optimize their effectiveness as well as work with the product owners, Scrum masters, and the stakeholders to confirm that everyone continues to work toward a common goal. The coach would also ensure that risks, delays, and business problems are all addressed in a timely manner using the collaborative framework of Agile. As workflows for the CRM system are defined, coded, and tested, it is likely that a number of SMEs will play a role, because they are best suited to identify issues and considerations.

The biggest challenge in a project like this is the communication and the integration of the multiple teams. Many such projects fail because one or more teams hit significant hurdles that they are unable to overcome and they cannot deliver their code; this then affects the successful teams because they cannot integrate their complete pieces into the overall system, so the whole project falls into a state of disarray. The oversight by the chief product owner, application owner, enterprise architect, and the Agile coach is one of the best practices to ensure that all six teams complete their work so that the whole can be created by the sum of its parts.

• The product owner is responsible for setting the product vision, defining release management, setting priorities based on business value, accepting the sprint results as complete, incorporating stakeholder feedback, and supporting the team. In short, the product owner defines the “what.”

• The Scrum master is responsible for making sure that the team has the best environment possible to complete their work. This includes removing impediments, minimizing interruptions, ensuring team cohesiveness, and enforcing the principles of Agile.

• The Scrum team is a self-managing group of cross-functional resources who commit to delivering working software in every sprint. The team makes the technical and design decisions to execute on the user stories presented by the product owner. The team determines “how” the work will get done.

• Working agreements are the set of rules and/or values that govern the team’s interactions. Each Scrum team establishes their own working agreement and uses it to reinforce team norms and relationships.

• “Fist of five” is a voting mechanism with Agile that facilitates discussion and decision making. As long as each participant is a 3 or higher, the decision is made and the team can move forward.

• “Chickens” and “pigs” are terms that come from a famous Agile cartoon: Pigs are deeply committed to the work (i.e., developers), and chickens are interested and supportive (i.e., stakeholders.)

• The project sponsor or champion is a critical role because it possesses both the budget and the authority to approve a project and make it happen.

• Scrum does not have a specific role for a project manager but does value the skills and deliverables by managing them within the team. Other methodologies, such as Crystal, FDD, and Lean software development, continue to utilize this role; XP does as well, though it is called a tracker.

• Stakeholders can be both internal (executives, users of the system) and external (customers or company shareholders), and they must be kept informed of project progress and deliverables. Their impressions, whether correct or not, can influence a project’s funding and potential success.

• The role of product owner in Scrum and Lean software development includes gathering and prioritizing requirements. In XP, this is called the customer, and FDD and DSDM have multiple roles that fulfill the function: In FDD, it is the chief programmer and the domain experts, and in DSDM, it is the visionary, ambassador user, and advisory user. Crystal advocates for collaboration between the customer and the designer with no specific role.

• Team coach is a role that is handled several ways. Lean and FDD put the responsibility of team effectiveness on the project manager, and Scrum advocates for a Scrum master. DSDM has two roles that share this task—the team lead and the coach. XP has both a coach and a big boss, though one person can play both roles.

• An architect or tech lead is not a specific role in Scrum because the responsibilities belong to the team. FDD has a chief architect, Crystal has an architect, DSDM has a technical coordinator, and Lean software development has a technical owner.

• Documentation is still required in Agile, and the depth of documentation should be dictated by the value it delivers. Only one methodology, DSDM, specifically gives the documentation author a title: “scribe.”

• Many companies will utilize an Agile coach to ensure a cohesive implementation of the Agile principles across multiple self-organizing teams.

• Kanban does not name specific roles because it is focused primarily on process improvements and removing bottlenecks.

Roman’s involvement with Agile started in 1999. He coached his first Agile project in 2001 and began working with Scrum in 2004. Roman has more than ten years’ experience in helping companies transition to Agile. This includes rolling out Scrum in several companies, and teaching and coaching executives, product managers, product owners, development managers, project managers, and teams. He is the founder of the London Scrum User Group, an active contributor to the Scrum Alliance and the London product management community, and a regular speaker at international conferences. Roman was named one of the 20 most influential Agile people in April 2012. To learn more about Roman, you can visit www.romanpichler.com.

Kristin and Sondra: What is your definition of the product owner role?

Roman: The product owner is the person who owns the product on behalf of the company. The individual is responsible for the success of the product and has to be empowered to make the necessary decisions.

In practice, the application of the role varies. It is influenced by several factors including the market, the product life-cycle stage, and the organization. For instance, working as a product owner of a brand-new mobile app developed by a small team in a small to mid-size company will differ from looking after an existing healthcare product, which is developed by several teams in a large enterprise.

I find that the product owner role is particularly valuable in the early life-cycle stages when the product is developed and introduced to the market. In these stages, the product owner resembles an “intrapreneur,” an entrepreneur within the enterprise.

Kristin and Sondra: How do you define the success of the product?

Roman: Broadly speaking, a successful product does a great job for its users and customers, and it benefits the organization developing it. Examples of the latter include entering a new market or market segment, meeting a revenue target, and strengthening the brand.

A great way to determine the product success is to carry out some customer discovery or problem validation work, including business modeling. Tools like the Business Model Canvas and Lean Canvas help determine what success means for a specific product.

Kristin and Sondra: What are the core responsibilities of the product owner?

Roman: The simple answer is: Whatever it takes to achieve product success in a healthy, sustainable manner! Here are some duties that I regard as important:

• Have a vision of where to take your product.

• Understand the product’s business model, including its value proposition and the desired business benefits.

• Carry out product roadmap planning—particularly when you work with an existing product.

• Collaborate closely with the development team and the Scrum master.

• Describe the desired user experience and the product features, and capture them in the product backlog.

• Determine what needs to be done next, and select the right sprint goal.

• Select the appropriate research/validation technique to expose the product increment to the right people, including customers, users, and internal stakeholders.

• Analyze the feedback/data gathered, derive the right insights, and action them. This often results in updating the product backlog.

• Look after the budget, understand the progress made, and manage the delivery/launch date.

• Coordinate the product launch activities.

Techniques such as user observations, problem interviews, competitor analysis, business modeling, product roadmapping, personas, user stories, scenarios, design sketches, product presentations, user tests, metrics and analytics, and release planning help the product owner carry out the duties well.

Kristin and Sondra: Any closing thoughts?

Roman: Working as a product owner is a multifaceted job that requires different skills. But it provides the opportunity to create something new, to develop new products and features that hopefully benefit the users and the organization. It’s a great job, in my mind!

She believes that Agile is more than an alternative project management methodology, and she is passionate about deepening the roles in Agile—specifically Agile coach and Agile manager—to help Agile move into its fullest expression.

She holds numerous certifications, including: Certified Scrum Coach (CSC), Certified Scrum Trainer (CST), Project Management Professional (PMP), Six Sigma Green Belt (SSGB), and Organization and Relationship Systems Certified Coach (ORSCC). She is also a trained Co-Active Coach and Leader. For more on Lyssa, please visit http://www.agilecoachinginstitute.com.

Kristin and Sondra: What are the most important skills for a Scrum master?

Lyssa: Above all, the Scrum master’s primary purpose is to help the team move toward high performance, producing products they are proud of and that fulfill the intended purpose in the world.

Perhaps surprisingly, then, technical or industry knowledge is not a key characteristic for success as a Scrum master. In fact, too much familiarity with the subject matter can actually be a detriment because it can keep the Scrum master “in the weeds.” With Agile methods, team members are the ones “in the weeds,” and rightly so. They are the knowledgeable insiders about the subject matter, the product, and the best ways to build things. This liberates the Scrum master to focus at the process level, considering questions such as: How is the team doing with the Agile process? What is the level of quality of their conversations? What is their ability to work with conflict as a positive force? Are they producing innovative and purposeful products? This is a completely different role, and one that requires a toolbox of skills more than any specific knowledge.

Working at this level, key skills for the Scrum master are facilitation, teaching, mentoring, and professional coaching. These skills allow them to work with team dynamics at the whole-team level as well as with individuals who often experience change and the resistance that comes along for the ride. Of course, deep knowledge of Agile practices and Agile values is key, as well. Ah! Finally! Here is the Scrum master’s knowledge area and the subject matter expertise they bring to the team. Notice, though, that it is only one area of many.

Kristin and Sondra: How does a Scrum master develop over time?

Lyssa: Although Scrum often comes into an organization through its software development function, it doesn’t stay there. It moves out into the organization, first requiring businesspeople to take up their role as the drivers of the product, then moves even further to challenge the organization’s processes, structures, and leadership culture. That can become quite a tall order for a Scrum master!

To meet the ever-increasing challenges in an organization, Scrum masters develop from working with one team to working with an entire enterprise. Along the way, they acquire more skills and models for working with people at all levels. They also undertake a significant amount of self-development to increase their personal “leaderfulness,” a key attribute for working with executives.

At the entry level, a Scrum master works with one team, being their on-the-ground Scrum guide and team development coach. They focus on helping the team use Scrum well. They also work to help the team remove the impediments directly blocking in the team’s path. As the Scrum master gains experience with Scrum and working with team dynamics, they can grow into an Agile coach.

Kristin and Sondra: If you are just starting to adopt Agile, who are the best internal employees to tap for the Scrum master role?

Lyssa: The best people to tap for the Scrum master role are ones who find other people interesting and who find team dynamics absolutely fascinating. A person’s previous role or domain knowledge is not a strong indicator of how they will flourish, or merely survive, in the Scrum master role. It’s easy to learn Scrum and hard to help people use it well. To do so requires a love for helping people develop themselves while they are developing great products.

Ambler, Scott. (2013). Feature driven development (FDD) and Agile modeling. http://www.agilemodeling.com/essays/fdd.htm.

Beck, Kent. (2000). Extreme Programming explained. Boston: Addison-Wesley.

Caine, Matthew. (2011). DSDM Atern roles and responsibilities—overview. http://www.mcpa.biz/2011/10/dsdm-atern-roles-and-responsibilities-an-overview.

Chedalawada, Alan. (2010). Standard work and the Lean enterprise. http://www.leanssc.org/files/201004/powerpoint/4.21%205pm%20Chedalawada%20StandardWorkAndTheLeanEnterprise.pdf.

Chromatic. (2003). Extreme Programming pocket guide. Newton, MA: O’Reilly Media.

Cohn, Mike. (2004). User stories applied: For Agile software development. Boston: Addison-Wesley. Kindle edition.

Cohn, Mike. (2010). Succeeding with Agile: Software development using Scrum. Boston: Addison-Wesley.

Cohn, Mike. (2013). Product owner. http://www.mountaingoatsoftware.com/scrum/product-owner.

Derby, Esther. (2011). Working agreements. http://www.estherderby.com/2011/04/norms-values-working-agreements-simple-rules.html.

Derby, Esther, and Larsen, Diana. (2006). Agile retrospectives: Making good teams great. Raleigh, NC: Pragmatic Bookshelf.

Dreher, J. C., and Berman, K. F. (2002). Fractionating the neural substrate of cognitive control processes. Proceedings of the National Academy of Sciences, 99(22), 14595–14600.

Hunton, Steve. (2012). A ScrumMaster is not a project manager by another name. Blog entry, August. http://www.scrumalliance.org/articles/436-a-scrum-master-is-not-a-project-manager-by-another-name.

James, Michael. (2010). The Scrum reference card. http://www.scrumreferencecard.com.

Kniberg, Henrik, and Skarin, Mattias. (2010). Kanban and Scrum—Making the most of both. Raleigh, NC: lulu.com.

Palmer, Stephen R. (2013). FDD: People. http://www.step-10.com/SoftwareProcess/FeatureDrivenDevelopment/FDDPeople.html.

Pichler, Roman. (2010a). Agile product management with Scrum: Creating products that customers love. Boston: Addison-Wesley.

Pichler, Roman. (2010b). The product owner role: Product owner on one page. http://www.romanpichler.com/blog/roles/one-page-product-owner.

Poppendieck, Mary, and Poppendieck, Tom. (2003). Lean software development: An Agile toolkit. Boston: Addison-Wesley.

Richards, Keith. (2007). Agile project management: Running PRINCE2 projects with DSDM Atern. London: TSO (The Stationary Office).

Schwaber, Ken, and Beedle, Mike. (2002). Agile software development with Scrum. Upper Saddle River, NJ: Prentice Hall.

Sterling, Chris. (2008). Creating a team working agreement. Blog entry, May 2. http://www.gettingagile.com/2008/05/02/creating-a-team-working-agreement.

Sutherland, Jeff. (2010). Scrum handbook. http://jeffsutherland.com/scrumhandbook.pdf.

VersionOne. (2013) “8th annual state of Agile survey.” http://www.versionone.com/pdf/2013-state-of-agile-survey.pdf.

Wikipedia (2013). Dynamic System Development Method. http://en.wikipedia.org/wiki/DSDM.

2. What are the considerations when one product has multiple product owners?

3. What is the product owner’s responsibility in reviewing the sprint results?

4. Who are the likely candidates to serve as Scrum master?

5. In what circumstances is it a bad idea to have the IT manager be the Scrum master?

7. How can “fist of five” help in the decision-making process?

8. How large should a Scrum team be? Why does it matter?

9. What are some of the benefits of self-organizing teams?

10. Who is a “pig,” and what is meant by this distinction?

12. What is a project manager called in Extreme Programming (XP)?

13. Which methodology has more roles, Kanban or DSDM?

14. What would be the role of an Agile coach?

15. Provide several examples of stakeholders.

17. What should be the driving factor in prioritization?

18. What is the most widely used methodology?

19. What are examples of impediments?

20. Within Scrum, who is responsible for testing?