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? 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.
The product owner is directly in charge of two of the twelve Agile Principles.
First, the product owner has the responsibility for principle #1: 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 |
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.
refactorthe code to increase the processing speed.
spiritof 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.
release, a
build, and the results of a sprint.
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.
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 |
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.
There are a couple of variations on the SM role, which can change from organization to organization:
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:
lead developerand
technical lead, but there are other potential leaders as well. The person's
fitfor 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.
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].
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]:
|
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:
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.
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:
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.
The first one is simple: the Agile best practice is for a team that has from five to nine people.
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.
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.
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:
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.].
turning onthe new customers
These will be covered in a later class. Check out the week05 page for details.
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.
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:
valueof the software or feature so that the team can thoroughly understand what the request is being driven by
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:
whatfocus of requirements in Waterfall. The developers must fully understand the feature request in order to build the right thing.
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]
trueteam environment? What has been positive about the experience? What has been negative about it?