CMSI 543 / SYEG 557: Welcome to Week 03
SPECIAL EDITION

This Week's Class Agenda

• SCRUM Roles Overview – to help with your group organizing
• Agile Requirements – to help with your project start-up and your design document
• Then Back to the REALweek03

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.

It is helpful, when learning about the Scrum roles, to keep in mind the twelve Agile Principles, as they are given at the Agile Alliance website.

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 following list provides an overview of the PO's tasks. For complete details on each of these items, refer to the week05 web page.

• Setting the Priorities — The PO has the very important job of setting the priorities for each part of the project; this job can ONLY belong to one person.
• 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.
• 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 ~if the results of a sprint don't meet the requirements, 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
• 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.

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.

Scrum Master

The next key role we will address is the Scrum Master role. For many organizations, this role is VERY new and different from 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.

The following list provides an overview of the SM's tasks. For complete details on each of these items, refer to the week05 web page.

• Removing Impediments — 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. Your book has several examples of interruptions.
• Communicator and Liaison — With any project, there are questions which will need answering. In fact, early on in the project, the team not only doesn't know the 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.
• 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 activity:
  
  • 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.
  • 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.
  • 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, 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.
• 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. However, there may be cases for which the SM role might NEED to be rotated among the team members.

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. The person's 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.
• Project Manager: 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. An Agile SM 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: 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.

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 been in situations in which the original dissenters have actually been able to show why their side makes more sense, and have brought the team around!]

Another thing to note is that the Fist of Five is really more aptly named the Fingers of Five since the 'vote' is actually done by holding up a number of fingers — the 'fist' actually means that person *DOES NOT* agree.

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, if at all.

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

These will be covered in a later class. Check out the week05 page for details.

Agile Requirements in Scrum

Agile works in a completely different way than Waterfall. Instead of trying to document all of the parts of a complex system up front, meaning at the very beginning of the project, Agile simply gets the team to figure out what the main parts of the system are, then pick a few of them that are key to providing value to the customer. The team then designs and builds that one key part or feature, then adds more parts and details to it as time goes on. Further, the requirements are focused on meeting the needs of the user or customer, on delivering immediate business value, and on inviting collaboration.

How Agile Does It

In software engineering, as in many other disciplines, gathering requirements is called requirements elicitation. This process collects the requirements and combines them into a document of some form. As we've seen in Waterfall, this is a Software Requirements Specification or SRS. However, in Agile/Scrum, the requirements take the form of things called user stories. This name is not chosen by accident. The idea is to have the customer walk the team through a typical use scenario, with each of the steps being written down so that at the end, the team [and the customer/user] will have a complete story of what that portion of the software must do. This helps the team to know:

• What: what is being requested for this feature or part of a feature that is short and simple
• Who: describes the functionality from the standpoint of the person who will actually be using the software or feature
• Why: encapsulates the value of the software or feature so that the team can thoroughly understand what the request is being driven by
• When: prioritization allows the team to associate an element of time to what the user story should accomplish; those that have greater business value or more time sensitivity

User Story Format

With Agile, as with Waterfall and requirements statements, there is a very specific format for the user stories. However, the format is much more user-friendly:

   As a <type of user>, I want <some goal>, so that <some reason>.
            

Here's how the parts in angle brackets are described:

• As a <type of user>: it is important for the developers to know the viewpoint of the user who will be using the application. It will make a significant difference if you develop code from the perspective of an end user who is proficient with computers as contrasted with a user who is not technical at all.
• I want <some goal>: developers need to know what the user story is trying to accomplish; this is similar to the what focus of requirements in Waterfall. The developers must fully understand the feature request in order to build the right thing.
• So that <some reason>: this is perhaps the most critical part of the entire statement, since it pokes directly at the idea of providing business value; if there is no value in the purpose of the user story, it will likely be eliminated.

Here is an example from your text book on page 116 which shows how this would look for the case of our weather application:

   As a concerned and retired grandmother, I want to receive alerts for areas where my children and
   grandchildren live so I know when I need to worry and call them to make sure they are safe.
            

This user story clearly defines all three of the items in the list: type of user [grandmother], what is wanted [alerts], and the reason it is wanted/needed [so I know to call them]. The who, what, and why make a very specific combination so that the developers have much more to work with than the traditional way of Waterfall requirements — they have context for this part of the software. This helps to insure that the team will build the right thing.

A user story is not a specification, but a communication and collaboration tool. User stories should not be handed off to the development team but be complemented by a conversation. [Pichler 2010, in Ashmore, p 117]

In class exercise

1. 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.
2. 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.
3. Every week or two, check to see how things are going. Is everyone honoring the agreement? If not, why not?
4. 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?
5. Next, try writing some user stories for your project. Fit the user stories into the model that is on the page above. Think about the user stories *COMPLETELY* from the user's viewpoint — in other words, what would the user see on the application screen? What would the user do to make it perform some operation?
6. Try to come up with at least three good user stories. Don't worry if they are too large or too small.

Coming up…

• Agile 'Flavors'
• Scrum
• Extreme Programming
• Kanban
• Crystal
• Lean
• Dynamic Systems Development
• Feature-driven Development