CMSI 543 / SYEG 557: Welcome to Week 06

This Week's Class Agenda

• SCRUM Roles
• That's all
• …but that's enough…

Introduction to Roles

Since most of your text book focuses on Scrum, and since Scrum seems to be the currently dominating Agile methodology in use, we start the discussion of Agile mechanics by discribing and discussing the roles that are involved in a project that follows Scrum.

QUICK QUIZ: Why is it important to understand the Agile roles? It is important to know and understand the different roles of Agile projects, because they are the underpinnings for how Agile projects deliver their work products. Each role has specific and detailed responsibilities and accountabilities without which an Agile project CANNOT BE SUCCESSFUL. Indeed, the definititions and requirements of each role show how the principles of the Agile methodology are done in organizations of all shapes and sizes. For Scrum, there are three main roles for any Agile project: Product Owner, Scrum Master, and Team Member. Let's look at each one in turn, in full detail.

Product Owner

The product owner is directly in charge of two of the twelve Agile Principles. First, the product owner has the responsibility for principle #1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Secondly, the product owner is responsible for principle #4: Business people and developers must work together daily throughout the project. You can think of product owners as sort of glorified cheerleaders in some respects. They are the ones who are the champions of the product and who must facilitate product decisions. They are also the ones who have the final say about the product. A couple of things to note here, though. Product owners don't actually own the product, they are merely the responsible party for the product. In that sense, they own the responsibility for the product, with respect to the two principles given above. Secondly, they facilitate product decisions, but they don't actually make them.

Making a viable project out of an abstract product vision is done by creating and maintaining the product backlog, which is one of the core duties of the product owner. [From here on this will be abbreviated PO.] The product backlog is a listing of all the user stories that are part of the project. We'll talk about the details of user stories in a minute; for now, just know that these are the way the project is divided up into parts of manageable size and that they are prioritized so the team always knows what they are working on. These user stories are the Agile equivalent of the software requirements that are used by other methdologies like Waterfall. It is the job of the PO to maintain the backlog. Further, it is the job of the PO to be the one to write the user stories to begin with, and to work with the customer to prioritize them.

The next few sections provide details of the PO's tasks.

Setting the Priorities

What this means is that the PO has the very important job of setting the priorities for each part of the project, no matter what it might be. This job can ONLY belong to one person; if it were split up between two or more, there would be conflicts that could lead to delays and/or uncertainty within the team about what the priorities are and what they should be working on. THAT situation could cause delays in the development and could throw the entire project off track.

It is important to note, also, that there may be multiple top priorities that must be handled. Although it sounds a bit silly, there are often situations that arise in business which create multiple priorities which all have essentially the same urgency. This is what is meant by the phrase multiple top priorities. It is never an easy task to juggle these conflicts, and it is important, whenever possible, to have a single person performing this activity. With respect to Agile, this factor was noted by Ken Schwaber and Mike Beedle in 2002:

The practice Scrum adds is that only one person is responsible for maintaining and sustaining the content and purity 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, in Ashmore, p 75]

Prioritization by Business Value

Looking at the case for Cayman Design on page 75 of your textbook as an example, there are a number of issues which are listed that must be prioritized. Some of these priorities conflict with each other, so it is useful to look at the entire list for discussion:

• 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.

Note that all three of these improvements are important to adding business value to the application, and they are all valid additions that will require proper planning and implementation. But how should we go about prioritizing them? Given that the main impetus of Agile is providing business value, what are some of the forms that might take? [Ashmore p 76]

• Increasing the revenue
• Expanding the market to reach more people
• Lowering the cost
• Improved customer satisfaction
• Better processing speed
• Better application stability [robustness]
• Increasing the usability of the application

It is important to understand, define, communicate, disambiguate, and measure [when possible] business value provided by an application. It is also critical, then, to make sure that when you are prioritizing activities, the business value of each item is discussed and decided upon. The product owner must be the one to balance all these inputs to properly prioritize what the team will work on next.

DISCUSS: Which of the three items above seems to be the hightest priority for the Cayman Design application, in terms of the business values forms listed?

Sprint Results

Another thing that the PO must be accountable for is the acceptance or rejection of the work at the end of a sprint. It is NOT in the spirit of Agile to simply reject work; that is not a collaborative attitude to take. Instead, if the results of a sprint don't meet the requirements, or don't meet the business objectives [kind of the same thing] or don't meet the PO's expectations, it is inherent on the PO to tell the team why, give a rationale for the rejection, and then add new user stories to the product backlog so that future sprints will be able to correct the deficiencies. It is also the PO's job to make sure that ALL WORK FOR THAT SPRINT is completed. That means the PO may need to go through each of the completed user stories for a sprint, one-by-one, to make sure that they are all done, and if there are any that are not 100% complete, the PO must hold the team accountable for the quality of their work. Note that this DOES NOT MEAN the PO takes an individual team member to task; the team succeeds or fails as a TEAM. This job of the PO also raises another issue, namely, what is the definition of done? This must be decided by the team as part of the initial work. We'll see more on this in a future week.

Release Management

A topic that is related to setting priorities is the process of release management. Activities for this function include deciding how many features should be included in a product before it can be released. This also includes defining the difference between a release, a build, and the results of a sprint. These issues are critical to decide with new products which need to be marketable and must grab the attention of new as well as target customers.

For example, given the scenarios above with Cayman, we might want to add new cities to increase the number of potential markets, and hence the number of new customers we can attract [your text book calls this increasing the addressable market. [Ashmore p 77]] This might be a simple operation, if the code is set up correctly, so that the team only needs to add some standard information to existing data files as part of the next sprint.

However, there may be other features that are desired, which are more complex and which might even need several sprints to complete. These features would need to be carefully planned as part of those sprints and would need to wait until a full formal release instead of just being pushed out with updates from a completed sprint.

In any case, it is the job of the PO to determine what makes a release, and then manage the feature set for every release.

Who IS the Product Owner?

So, given that the PO is such a critical role, who is the best person to fill that position on the team? It is most important to make sure that person knows the martkeplace as well as the needs of customers and other potential prospects of the business. It is also vital that the PO knows EXACTLY WHAT the team needs to build. To do that, the PO needs easy access to market information as well as feedback from the stakeholders on the project.

There are several people who can then serve as the PO. It might be a Product Manager who has experience with product development from past projects, Agile or not. It might also be a Business Analyst [BA] who has the requisite knowledge; this BA might be from the IT department, or perhaps from somewhere else in the organization. It might also be an account manager who is responsible for engaging with the current customers of the organization. It may even be someone from a more operations-focused department who has knowledge of the company's operations. As long as it is someone who will perform due diligence on the duties of a PO with the required knowledge, who will create a good feedback loop with the rest of the team, organization, and stakeholders, the PO can come from any area.

Product Ownership — Breadth

Another facet of the PO's role is breadth of ownership. This term has to do with the number of projects the PO is managing, as well as the number of PO's on a project. For example, does the project only require a single PO? Or perhaps it is large enough that it needs two or more PO's to manage several small parts of the large project? In the first case, the PO is in pretty good shape, since the only coordination needed is with the situations we have already seen above.

However, if the PO is managing two or more projects, the biggest risk is time. The PO needs to carefully balance the time required for each project being managed so that neither one gets short shrift. This can be tricky, given that the PO needs to not only have the time to give proper attention to all of the projects, but also needs to have the depth of knowledge required to manage them well, and to effectively collaborate with the teams for all projects.

In the case of multiple PO's on a single project, there are a couple of potential risk factors. First, there is the chance that the PO's may have a conflict in their prioritization of tasks, such that one PO thinks something should have top priority when another one disagrees with that assessment. Another situation that may arise is the possibility of system interactions and dependencies that the PO's need to take into consideration. It is obvious that in keeping with the Agile tenet of collaboration it is critical in these cases for the PO's to collaborate effectively with each other as well as with their individual teams.

To return to the Cayman example, if the product is large enough to have a PO for the front end and a different PO for the backend order management system, there may be a conflict if one PO prioritizes adding cities [front end] over processing speed [back end], while the other PO prioritizes just the reverse. The two PO's will need to collaborate to ensure that the release timing is properly aligned so that both priorities are properly handled.

This situation also brings up another sticky point, namely, what work products go into a release, as contrasted with simply a sprint result being pushed? Here again, the two PO's will need to coordinate effectively to make that definition clear to BOTH of the development teams, and they will also need to plan carefully when deciding what to include in the sprints for the two teams so they are properly coordinated.

Scrum Master

Removing Impediments

The next key role we will address is the Scrum Master role. For many organizations, this role is VERY new and different to the normal state of affairs, and in many cases does not really have a comparable role in Waterfall methods. The Scrum Master [SM] is responsible for actually being the development team leader, and must work through any issues that arise within the team during the sprint. The specific details of what the SM must do depends heavily on a set of factors, including the size of the team and the experience level of its members. The SM must be the kind of person who is willing to make decisions and take responsibility for them, and must be the key player throughtout the organization who can remove roadblocks that are keeping the team from making forward progress. Being the project SM is definitely not a job for everyone – some people are uncomfortable with the visibility of this role in the organization, or may not be able to take the initiative needed to ensure the project's success.

One of the main things the SM must be able to do is to work at removing impediments. This is the term applied to anything that is in the way of the developers getting their work done. One big part of this is preventing the team from being interrupted. When the team is working well, they will be focused on their activities; if they are interupted, there is more lost than just the time spent on the interruption. It can be quite difficult to pick up where they left off when the interruption is dealt with. This is a situation known as restart cost. Your book has several examples that can be used to illustrate:

• One member of the team is playing music so loudly that it is distracting other team members. The SM should be the one to work with both team members to find a solution that is satisfactory to both of them.
• One team member has questions for the PM, who is rarely around, always in meetings, or is not accessible to get questions answered. The SM should be the one to work with the PM to alleviate the situation so that the developer gets the proper information to continue progress.
• One member of the development team is a Subject Matter Expert [SME] for the organization; as such, many people cause frequent interruptions to that team member's work because they must ask legitimate questions. The job of the SM in this case would be to be a buffer between the team member and those asking questions, possibly even scheduling specific times when questions are allowed.

It is a good and useful thing to have a person on the team who can fulfill these duties; so that the team can stay on track and be productive. However, it does sometimes require determination and some assertiveness to serve this role. Not everyone is comfortable with the potential for confrontation which may arise, and even if someone is comfortable with that they may not have the diplomacy needed to work out differences with tact.

Communicator and Liaison

With any project, there are many questions which will need answering. In fact, early on in the project, the team not only doesn't know that answers to the questions, but in fact may not even know the questions! The SM should be the link to coordinate with the other stakeholsers to obtain the answers the team needs to keep moving. This may take several paths: the SM may attend some meetings; the SM may seek out SME's or specific people to facilitate the information transfer; the SM might even need to find the answer independently. The SM can also keep the team in the loop about all information to support the Agile philosophy of no surprises.

Adherence to Scrum Best Practices

The SM must also insure that the team adheres to the principles of Scrum. There are several things involved with this: Make sure all voices are heard: if someone is fairly dominant in meetings and someone else is more quiet, it is the SM's job to make sure that the dominant one leaves room for the quiet one to talk so that everyone's voice is heard. here are several ways to do this diplomatically, including asking questions directly of the quiet person or even taking the dominator aside later and gently reminding that person. Stick to the meeting schedules: this topic includes both scheduling and just showing up as well. The SM needs to make sure that the required meetings are scheduled, that everyone knows about them, that all required people have been invited with appropriate messages of date/time/location, and to make sure that all those required people show up. In addition, meetings should have a start time and a specific agenda so that the meeting runs smoothly. Daily Scrums should be scheduled for a standard time and place. The SM should run the daily Scrum to make sure that everyone has their turn to contribute, and to cut short any extended discussions of have you tried… to keep the meeting on track. [Such discussions can be taken off line, meaning they can be handled with a separate meeting.] One of the most important meetings is the Sprint Retrospective, which occurs at the end of each sprint; this confab gives the team a time and a forum to reflect on what went well in the last sprint and what needs to be improved in the next one. Finally, hold the team accountable: the team needs to meet its commitments, which includes all of the activities for which it has signed up, as well as commitments to attend meetings, produce all work products on time and properly functioning, and collaborate with the other team members to communicate effectively.

Scrum Master Role

There are a couple of variations on the SM role, which can change from organization to organization:

• Full Time or Part Time: If the team is large, if the team has many new members, if the team is building a complex project, or other such factors, it might be a good idea to have the SM be a full-time position. In such a situation, the SM would NOT be a part of the development team proper, doing no coding or building or testing work. On the other hand, if the team is small, or if there are several smaller teams, the SM might be a part-time position, with the rest of the person's time being taken up by being SM for another group or even taking part in the more hands-on development activities.
• Permanent or Rotating: In some cases, it might be a good idea to have the role of SM be a rotating position, meaning it is shifted around among the various team members. Deciding may be based on several factors, such as if there is someone on the team who is a natural leader, or someone who especially WANTS to be SM, or even someone who has more experience as a SM than the other team members. There is something to be said, as well, for the consistency which comes from having a single person be permanently assigned to the position. However, there may be cases for which the SM role might NEED to be rotated among the team members; it may be the case, for example, that there are potential SM's in training and the experience can be helpful to them, especially if there is another person on the team who can mentor them in the SM role.

Who Should Be Scrum Master?

This is a very important decision to make early on in the project. Because a good choice is so critical to the success of the project, there are several things to consider in terms of who to pick:

• Technical Lead or Lead Developer: One obvious choice for the SM role is someone who has previously demonstrated the ability to make decisions in a leadership position. There are several such positions on the team; your book names >lead developer and technical lead, but there are other potential leaders as well. Anyone who is good at solving complex or technical problems might be a candidate. Someone who seems to have a natural leadership ability might also be a good choice, even if they are not quite as strong technically. The persons fit for the role is also a consideration. By fit is meant that the person must be able to coach other team members and collaborate with them rather than making dictator-style decisions without properly consulting the team. The person who is selected must also be comfortable with the added visibility that the SM role involves. Someone who is shy about talking with management or who cannot be assertive without being antagonistic towards other is not a good fit for the role.
• Project Manager: Here again there are decisions to be made based on the type of organization and the fit of the potential SM's. If the project managers are already accustomed to a waterfall method, they may not be a good fit for Agile. This is because they are already trained to look at project management in terms of accountability and enforcement. a Project Manager's job is to make sure that everyone completes their tasks on time; if any problems arise, the Project Manager usually make risk matrices and reassign tasks or [the worst thing to do] may add additional people, then make up a new time line for the project. An Agile SM, in contrast, will strive to collaborate with the team and the PO to see how the product is affected and to brainstorm a new solution using creative problem solving methods.
• IT or Functioal Manager: Another subject is whether the SM can be the IT manager. One more time, this depends upon the make up of the organization. If the IT managers are all used to Waterfall, they are most likely accustomed to making all the decisions, and hence will be more comfortable assigning tasks and managing the Scrum Team as individuals rather than as a team. If such is the case, the IT Manager most definitely should NOT be the SM for the project. In fact, the SM may not even be an IT person at all; there have been instances in which the SM is from accounting! The important thing is, the person must be able to remove impediments, minimize interruptions, lead the team, and enforce the principles of Agile!

Team

the last role we'll look at is the role of the Scrum team. These are the people who will perform all the development tasks necessary to ultimately deliver on the project. There is a great deal of variability about the team makeup. The following paragraphs provide some key things to take into account when forming an effective Scrum Team [ST].

Working Agreement

First, there needs to be an agreement of some kind that the team can all sign up to. The agreement Should help the team establish trust with each other and enable enforcement to the goals and principles of Agile. This agreement is what is known in Agile terms as the working agreement. There are several items which should be considered as part of this document [and it should be a document]:

Specification of the time and location of the daily Scrum meeting The plan for one or more testing strategies, including unit level, functional level, integration level, performance level, stress testing, acceptance testing, first article testing, etc. Plans for building and infrastructure and who will be responsible for each of the parts of each of those items Normative behaviors for the team and its members, such as being on time, help when needed, respect for other team members, etc. Process for addressing bug fixes and putting out fires when they occur Documented availability of the PO, including office hours, phones, Scrum meeting attendance Sprint capacity in story points which is estimated for the first sprint and calculated therafter

Fist of Five

The fist of five is a method of making a decision when there are several options to solve a problem and no ideal solution. It is a way of voting on a one to five scale, similar to a Likert scale that is used in survey research. The vote goes from one [lowest] to five [highest] and corresponds to the following selections:

Five fingers: I'm all in, I completely agree 100% Four fingers: I buy into it, and support it Three fingers: I have some reservations, but I can support the decision and move forward Two fingers: I have reservations about this topic and I cannot support this decision without further discussion and clarification One finger: I do not support this decision and I completely DISAGREE 100% The fist of five system allows all team members to show their level of support, or lack thereof, so that there will be no team members who may not agree but choose to keep that opinion silent. In this sort of team environment, there cannot be such dissent, since it can possibly sabotage the team later on. As long as everyone shows three, four, or five fingers, the team can move on. If anyone shows one or two fingers, there needs to be further discussion before moving forward. Note that it is possible, in some cases, for the dissenters to be right about their dissenting opinions. [I have seen cases in which the original dissenters have actually been able to show why their side makes more sense, and have brought the team around.]

Another situation the fist of five can help to resolve is the social situation of introverted people in a setting with extroverted people. Sometimes people feel inhibited in speaking out or speaking up; the fist of five requires the participation of ALL team members. Further, the introverts may be able to overcome those feelings, at least in part, by realizing that simply by holding up two fingers they have the power to get the entire team to wait and listen to their concerns.

Self-Organizing & Team Size

There are some further points to be expressed about the climate of a team which is encouraged to self-organize. Such teams have a tendency to adopt the following states:

• Members commit to clear, short-term goals
• Members can estimate the progress of the group
• Members can see the contributions of other team members
• Member can feel safe to be 100% honest with opinions, ideas, and feedback

Self-organizing teams are allowed to handle their own individual job assignments. Once the sprint has been set up, planned, and groomed, the team members can pick what they want to be their assigned tasks to work on. The ownership of their own tasks is a significant difference between Agile and Waterfall; in the latter, team members are given job assignments by the manager. In that case if the manager picks well and the job assignment matches the person's skill set well, it is likely that the project will be fine. However, this doesn't necessarily allow for the individual to grow and learn anything new. If the team is self-organizing, the team members can achieve a significant increase in job satisfaction and a greater sense of ownership in the overall product as well as their part of it.

Membership

The first one is simple: the Agile best practice is for a team that has from five to nine people.

Cross Functional

Second, teams need to be cross-functional so that everyone on the team can participate in the design, coding, debugging, and testing within a single sprint. The focus is to get the team to have a complete set of the skills required so that working software can come out of EVERY SPRINT, without the need for any outside resources.

Further, the team should be as static as possible, so that there is as little upheaval or personnel changing as possible. Team personnel should NEVER change during a sprint. The time for such changes is between sprints.

Lastly, the team members should be assigned as FULL TIME, and should only work on a SINGLE TEAM. There may be situations in which this is not entirely possible, but the best practices is full-time membership. There may be times when a full-time person may not have enough to do, such as a DBA or UI designer. Such situations may require sharing those resources.

Scenarios and Examples

Take a look at your text book on pages 90 – 93 for some good [and compete!] examples of the roles that have been discussed above.

Extended Team Members

There are several other people who may be needed as part of the team, beyond the three major roles that we've met so far:

• Project Sponsor: this is a person who can advocate for the project, with the authority to allocate funding and other resources to the project. The are true decision makers in the organization and can back up their commitments.
• Stakeholders: these are people who are either directly or indirectly affected by the project and its successful development and completion. There are internal stakeholders [those who are inside the company, from users to the CEO], and external stakeholders [those who are outside the organization, again including users, but also shareholders, etc.].
• Operations team: responsible for turning on the new customers
• Customer Service Reps: support the end users when there are questions/problems
• Technical Help Desk: support the end users with technical assistance
• Finance and Billing: booking the revenue for the product when it is deployed
• There may be many others as well. Can you suggest some?

Roles In Other Agile Methods

Project Sponsor

In Crystal, FDD, Lean, and Scrum, this person is called the sponsor, or sometimes is called the executive sponsor. In DSDM, the term project champion may be used.

Requirements Gatherer

This is the person who gathers the requirements, understands the needs of the customer and/or the end user, tells the team about the business value being developed, and sets the details vision of what the product will be. The Scrum PO fills this role. In XP, this is the customer. In FDD, it is split between the chief programmer who prioritizes the work, and the domain expert who understand the details of the application as it relates to the business or operations to which it will be applied.

In DSDM, this is also divided among the visionary who understands the long-term use of the software, the ambassador user who makes sure that the end users' needs are carefully considered, and the advisory user who will be more focused on the usability of the software and the resulting workflow details.

Project Manager

With Crystal and DSDM, the role is still called Project Manager. With XP the role has the same responsibilities, but is called the tracker. In FDD and Lean, it is still known as Project Manager but is expanded to include team environment optimization.

Team Coach

FDD, Lean, and Scrum all assign the responsibilities for this rol to the Project Manager and the SM, but in XP this function is split between the coach and the big boss. The former is a mentor to the team, leading by example and helping others; the latter is responsible for holding the team accountable for meeting their commitments.

With DSDM, the role is similarly split between team leader and coach.

Crystal does not define such a role.

Large organizations with several Agile teams may want to use an Agile Coach, either as a full-time employee or as a consultant, to oversee the Agile implementations and make sure that each team is operating at its full potention and optimization.

Architect/Tech Lead

FDD calls this role the chief architect, who is responsible for the overall architecture of the application. They must insure that no individual feature of the application will compromise the integrity of the system as a whole.

In DSDM, this is called the technical coordinator. In Crystal, it is the architect. In Lean, it is called the technical owner. Scrum doesn't specifically name this role.

Development Team

XP, Scrum, and Lean view the development team as a single entity. However, in Crystal there is a role of user experience designer, sometimes referred to as UI designers or usability professionals. This is also defined in Crystal as the UX designer. Crystal also specifies a programmer and a tester. In DSDM, there are named roles for solution developer and solution tester.

Since FDD has the idea of classes, there are class owners within the development team.

Documentation and Training

Some teams need to include one or more people responsible for documentation and for training users. In DSDM, there is a role called a scribe who documents the application. Additionally, the team may have need of a trainer or training facilitator to help the end users with training and understanding the application and its documentation.

Kanban Roles

Hey, guess what?! Kanban doesn't define specific roles! The Kanban philosophy tries to NOT assign specific roles and responsibilities in this way, and cautions against defining roles just for the sake of having them. Kanban considers such activities form over function.

Some Examples

We will look through the examples on pages 99 – 103 of your text book to see some examples of how roles are defined and used in several different types of organizations.

In class exercise

Create a working agreement within your project group. Discuss what matters to you as a team, what is most important to you as individuals making up that team, and how you can increase your effectiveness using teamwork. Write your agreement down and post it to your repo; you can incorporate it into your README.md file if you like, or put it someplace else as a separate document.

Then every week or two, check to see how things are going. Is everyone honoring the agreement? If not, why not?

At the due date for your Detailed design, re-evaluate the agreement again. Has it brought the team closer together? Has it been effective in creating a true team environment? What has been positive about the experience? What has been negative about it?

Coming up…

MIDTERM EXAMINATION IS NEXT WEEK!!