| 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 the final one in a series of
newsletters that discusses the Agile Scrum
process and ends with tailoring Scrum in a way that
improves your individual software releases.
Here are the prior newsletters in this series:
Overview
As you
have read in our prior newsletters, Scum offers a
very efficient way of delivering software releases.
However, Scrum in it's purest version, may not meet
your needs exactly. Never feel afraid to take
the Scrum methodology and make it your own by
customizing it or tweaking it to meet the needs of
your team.
6 Ways we have Tailored Scrum to our Needs
Below are
ways we have tailored it to meet our needs, this may
trigger ideas for your team to use when tweaking
Scrum for your team:
-
30 Day Sprints - In the purest
of Scrum, the 30 day sprints are 30 calendar
days. We found because of holidays and
workload, 30 calendar days did not work well for
us. So we changed this to be 30 working
days, then we added 10 more working days to the
sprint for final quality assurance (bug fixes,
final design/rework changes, etc.) before moving
to beta or production, so our entire sprint
becomes 40 working days.
-
Software Quality Engineer -
In the purest of Scrum, a team is made up of the
Product Owner, Scrum Master, and the Team.
The team is comprised of programmers that
perform coding, testing, and documentation.
In our experience, programmers do not make the
best testers, so we have included another team
role called the Software Quality
Engineer, and this engineer is
responsible for creating test cases, reviewing
them with the team, and performing regression
testing (automated if possible).
-
Documentation Specialist
- As mentioned earlier, programmers are not the
best documentation specialists, so we also
included another team role called the
Documentation Specialist. This
person is responsible for updating user guides,
marketing materials, training guides, help
guides and movies.
-
User Stories
- In Scrum, User Stories are the requirements.
User Stories are written on 3x5 index cards and
provide minimal information about the
requirement and are awarded story points. Story
points are just a way of estimating the user
story as to its difficulty. We found that
User Stories just did not provide enough
information to provide a good test plan.
Therefore, we create a requirements document
(called a Work Order) that explains the feature
in detail, contains a prototype of the feature
(if applicable), and provides estimated hours to
complete the work order. This allows our
software testing engineer to create a better set
of test cases (with great traceability) and
allows our developers to code the requirement to
specification. For an example of a
Work Order document, see this:
http://www.pragmaticsw.com/Template_WorkOrder.doc.
-
Publishing Test Cases Prior to Coding -
In a traditional Waterfall environment, the test
engineers develop test cases as coding is
progressing and then they run the test cases
once all functionality is coded and is ready for
testing. In this scenario, the programmer
does not have visibility to what test cases are
going to be run until all coding is complete.
In our experience, this approach causes a 30%
longer quality assurance cycle because many of
the test cases fail due to the programmer not
being aware of the scope of testing. When
test cases fail, it takes iterations of re-work
to get them fixed. Our approach is to have
the test engineer publish all test cases BEFORE
coding begins and we REQUIRE the programmer to
fully read and understand the test set before
they begin coding. This fuels them to code
the logic in way that will ensure the test cases
pass. Once the coding is done, we also
REQUIRE the programmer to run each test case and
ensure all pass before moving marking them ready
for quality assurance testing. The
software test engineer will also run the test
cases again to ensure they pass, but can spend a
lot more time doing exploratory testing and
ensuring a higher quality product. Many
people think this will add time to the
programmer's tasks because they have to run and
fix tests during coding. This is true, but
from our experience, it only adds about 10% more
to their timeline, saving a overall quality
assurance timeline of 20%.
-
Automated Testing -
Although Scrum does encourage automated testing,
we believe if you have not started any automated
testing, it is best to start your automation on
your regression test cases, as those will need
to be run daily to ensure you are not breaking
existing features. We still find
creating and running manual test cases for new
functionality is critical, as a human can have a
deeper test and can physically review the
results in detail. For more information on
test automation, see this document:
http://www.pragmaticsw.com/WhitePaper_TestCase_Automation.pdf.
Summary
Never feel afraid to take the Scrum
methodology and make it your own by customizing it
or tweaking it to meet the needs of your team and
always continue to make it better via input received
during your retrospectives.
|
|
Helpful Templates
Below are some helpful
templates to aid you in developing software
solutions on-time and on-budget:
|
About the Author
Steve Miller is the President of Pragmatic Software
(http://www.PragmaticSW.com).
With over 23 years of experience, Steve has
extensive knowledge in project management, software
architecture and test design. Steve publishes a
monthly newsletter for companies that design and
develop software. You can read other newsletters at
http://www.PragmaticSW.com/Newsletters.asp.
|
|
Note:
This newsletter is never sent unsolicited, it was
opted into from our website. If you wish to
unsubscribe,
click here. |
|
|
