Monday, December 21, 2009

Agile Scrum - Tailoring Scrum to Your Needs

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:

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. 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%.
  6. 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:

Posted by at
Labels: , , , , , , , , , , , ,

1 comment:

  1. alineJuly 18, 2010 at 8:33 PM

    I actually enjoyed reading through this posting.Many thanks.

    Scrum Process

    ReplyDelete

Subscribe to: Post Comments (Atom)