| Many of us have
experienced projects that drag on much longer than
expected and cost more than planned. Companies
looking to improve their software development
processes are now exploring how Agile can help their
Enterprise more reliably deliver software quickly,
iteratively and with a feature set that hits that
mark. While Agile has different "flavors",
Scrum is one process for implementing Agile.
This newsletter is one in a series of
newsletters that will discuss the Agile Scrum
process and will end with variants of Scrum that can
be used to aid in improving your software releases.
Here are the prior newsletters in this series:
Team Composition
Managing Scrum development requires a major change
in how teams work together. In traditional
Waterfall development, teams normally have a project
sponsor, a project manager, analysts, designers,
programmers, testers, and documentation specialists.
Each team member has specific duties which normally
do not normally overlap and they have a specific
reporting structure (most team members report to the
project manager).
With Scrum, you have just 3 team roles and is
normally limited to 7 or less individuals (however,
you can have multiple Scrum teams in sets of 7 or
less):
-
Product Owner - This is the
person that identifies and prioritizes the
features that will appear in a 30 day sprint.
This is normally the Product Manager, CTO, in
some cases the CEO, or some other
high level stakeholder that ultimately is
responsible for shaping the roadmap of their
product. Before a sprint begins, the
Product Owner communicates the goal of the
sprint to the team and what features should be
analyzed for the release. This does not
mean that all the desired features will make it
into the sprint, the team estimates and
prioritizes items for the sprint (during the
Sprint Planning sessions), and only the items
that can fit in the sprint are done.
-
ScrumMaster - The ScrumMaster
is akin to the Project Manager in Waterfall
environments, but does not manage the team
deliverables at a micro level. Instead,
this person is responsible for ensuring that the
30 day sprint stays on course, no new features
are added to the sprint, code inspections happen, and
ensuring everyone plays by the rules. The
ScrumMaster coordinates and runs the daily
sprint meetings. The ScrumMaster is not a
task master, they are a leader that empowers the
team members to deliver the assigned tasks and
to help eliminate roadblocks that slow them
down.
-
The Team - With Waterfall, a
team consists of analysts, designers, testers
and documentation specialists. With Scrum,
each team member is empowered and expected to
self-manage themselves and to participate in all
duties needed to deliver a feature. This
includes analysis, design, coding, testing and
documentation. The Team is responsible for
staying focused on assigned tasks, soliciting
help as they encounter road blocks, fully
testing their code, refactoring code, logging
their time daily (including estimated time
remaining on each task), and for checking their
code daily or more often if possible.
Our Experiences with
Team Composition
In our experience, it is unrealistic to assume that
The Team can handle quality
assurance and documentation well. We have
improved the team composition to include 2
additional roles:
-
Software Quality Engineer - This
individual is responsible for the quality of the
sprint. In our experience, programmers do
not test code with the same mentality as a
Software Quality Engineer (SQE). Once
specific requirements are defined, the SQE
develops a set of test cases (manual or
automated) to test each requirement fully.
Before coding begins, the test cases are made
available to the programmers on the team. The
programmers are expected to run each test case
before marking coding as being complete.
Once a requirement is marked as being complete,
the SQE is responsible for running the test
cases again to ensure they all pass. The
SQE also runs a weekly regression to ensure that
legacy features are not compromised by the
release. If the SQE has developed
automated test cases for regression, those are
run daily or more frequently, if needed.
The SQE does not wait until the end of the
sprint to begin testing, they test once a
requirement is completed. By the end of
the sprint, all testing has been done and
regression has been run frequently.
-
Documentation Specialist - The
Documentation Specialist (DS) is responsible for
creating User Guides, Administrator Guides and
other training materials. In our
experience, programmers do not always have the
written communication skills to write
documentation in a way that a laymen can
interpret it, that is why it is important to
have a separate resource for this function.
Once a requirement has been fully tested by the
SQE, the DS begins the documentation of that
requirement. The DS does not wait
until the end of the sprint to begin this, the
end of the sprint includes all completed
documentation.
What's Next?
Upcoming newsletters will discuss the following
topics:
-
Agile Scrum - Understanding Scrum
Rules
-
Agile Scrum - Scrum Kickoff and
Product Backlog
-
Agile Scrum - The Daily Scrum
Meeting
-
Agile Scrum - Reporting and
Metrics
-
Agile Scrum - Retrospectives
-
Agile Scrum - Site specific
variants of Scrum
|
