Scrum (Agile Software Development)
Scrum was intended to be
for management of software development projects. It is a holistic
approach which increases speed and flexibility in commercial new product development. The whole process is
performed by one cross-functional team across the different phases (the rugby
method).
Depending on the situation
scrum can be adapted or changed to fit specific needs.
Roles
ScrumMaster maintains the processes and works similar to a
project manager. His primary job is to remove impediments to the ability of the
team to deliver the sprint goal. The ScrumMaster is not the leader of
the team (as they are self-organizing) but acts
as a buffer between the team and any distracting influences. The ScrumMaster
ensures that the Scrum process is used as intended. The ScrumMaster is the
enforcer of rules and sprints of practice.
Product Owners represent the stakeholders and the Team which includes the developers (In
my experience they are the producer and the design director). It is imperative
that the Product Owners work closely with the publisher or investors. Most game
developers work for hire and they need to make sure that the client gets
exactly what he expected. The expectations and needs must be explained to the
scrum teams.
The Team
has the responsibility to deliver the product. A small team of 5-9 people with
cross-functional skills to do the actual work (designer, developer etc.).
Pigs are the ones committed to the project and the Scrum
process; they are the ones with "their bacon on the line".
Chicken
roles are not part of the actual Scrum process, but must be taken into account.
An important aspect of Agile approach is the practice of
involving users, business and stakeholders into part of the process. It is
important for these people to be engaged and provide
feedback into the outputs for review and planning of each sprint.
Users
The software is being
built for someone!
Managers
People that will set up
the environment for the product development organization.
Sprint
During each sprint,
a 15-30 day period (length decided by the team), the team creates an increment
of potential shippable (usable) software. The set of features that go
into each sprint come from the product backlog, which is a prioritized
set of high level requirements of work to be done. What backlog items go into
the sprint is determined during the sprint planning meeting. During this
meeting the Product Owner informs the team of the items in the product backlog
that he wants completed. The team then determines how much of this they can
commit to complete during the next sprint.
During the sprint, no one is able to change
the sprint backlog, which means that the requirements
are frozen for sprint. One of Scrum's biggest advantage is that it is very easy
to learn and requires little effort in general terms to start using.
The Scrum Meeting
Each day during the sprint, a project
status meeting is arranged. This is called a scrum. The scrum has
specific guidelines:
- The meeting starts precisely on time with team-decided
punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken
around your neck)All are welcome, but only "pigs" may speak
- The meeting is time-boxed at 15 minutes regardless of the team's
size
- All attendees should stand
- The meeting should happen at the same location and same time
every day
During the meeting, each team member
answers three questions: - What have you done since yesterday?
- What are you planning to do by tomorrow?
- Do you have any problems preventing you from accomplishing your
goal? (It is the role of the ScrumMaster to remember these impediments.)
After each sprint a sprint retrospective is held, at which all team members
reflect about the past sprint. The purpose of the retrospective is to make
continuous process improvement. This meeting is time-boxed at four hours.
Scrum enables the creation of
self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and
disciplines that are involved in the project.
A key principle of Scrum is its
recognition that during a project the customers can change their minds about
what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a
traditional predictive or planned manner. As such, Scrum adopts an empirical
approach � accepting that the problem cannot be fully understood or defined,
focusing instead on maximizing the team's ability to deliver quickly and
respond to emerging requirements.
The Scrum Meeting
The product backlog is a high-level
document for the entire project. It contains broad descriptions of all required
features, wish-list items, etc. It is the "What" that will be built.
It is open and editable by anyone. It contains rough estimates, usually in
days. This estimate helps the Product Owner to measure the time line and, to a
limited extent, priority (e.g. if "add spell-check" feature is
estimated at 3 days vs 3 months, that may affect the Product Owner's desire).
Sprint Backlog
The sprint backlog is a greatly
detailed document containing information about how the team is going to
implement the requirements for the upcoming sprint. Tasks
are broken down into hours with no task being more than 16 hours.
If a task is greater than 16 hours, it should be broken down further. Tasks on the sprint backlog are never assigned; rather tasks
are signed-up for by the team members as they like.
Burn Down Chart
The
Burn down
chart is a publicly
displayed chart showing the number of tasks remaining for the current sprint.
It should not be confused with an earned value chart. A burn down chart could
be flat for most of the period covered by a sprint and yet the project could
still be on schedule. The chart is maintained by the Scrum Master.