Using Retrospectives to Improve Future Testing Efforts

This month's newsletter is delivered as an On-Demand webinar. It is the last in the 5 part series entitled "Uniting your Automated and Manual Test Efforts" and focuses on using retrospectives to improve future testing efforts.

Click here: http://www.softwareplanner.com/guidedtours/edgeui/Camtasia.asp?Filename=UnitingPart05) to begin the presentation. You will learn:

1. What a retrospective is and how it can help your team improve
2. How to conduct a retrospective
3. How to improve future releases by applying what you learn in retrospectives

5 Benefits of Daily Builds

This month's newsletter describes the major benefits of doing daily builds and how it can improve your software quality. A daily build is the process of compiling your software daily so that tests can be run against it to identify any major coding issues introduced since the last build. Daily builds have become common place with Agile development, but it is not limited to just Agile teams. Teams practicing Waterfall development can also get enormous benefit from this approach.

To see the full article, click here: http://www.softwareplanner.com/newsletters/Newsletter_2010_05_SP.htm

Peer Code Review: An Agile Process

This month's newsletter discusses how peer code review can be used by Agile teams to drive better software quality. The article was written by Gregg Sporar of Smart Bear Software and published in the proceedings of the Agile Development Practices conference in November 2009, Gregg has kindly given us permission to share it with you. We hope you have a great holiday and enjoy Gregg's article.

Is Peer Code Review Agile?
Peer code review is one of the most effective ways to improve software quality – but is it agile? Done correctly, it absolutely is. The Agile Manifesto[1] states:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Research has consistently shown that code review produces software with fewer defects, which aligns with the emphasis on working software. And what could be more interactive than two or more software developers talking (or instant messaging or emailing) about the code and making real-time improvements?

Yet many agile practitioners consider peer code review to be part of the “bad old world” of waterfall development and reject its inclusion in agile projects. This newsletter shows how code reviews can be conducted using methods that align perfectly with the fundamental principles of agile development.

Moving Beyond the “Code Review Stigma”
Historically, the process for conducting code review was pretty “anti-agile.” As originally conceived by Michael Fagan in 1976, code inspections[4] were a heavyweight code review process that led to an entire generation of software developers who believed meetings were necessary in order to review code.

Heavyweight processes and meetings are not regarded favorably on agile projects, and that stigma has tainted the concept of code review. This “guilt by association” has worn away over time, but misconceptions still linger.

The biggest misconception is that meetings are required to do code review. Fagan stated that meetings are required, as have other researchers. But Lawrence Votta of AT&T Bell Labs was not convinced. His study[6] showed that if developers read the code before the meeting in order to find defects, actually having a meeting will only increase the total defects found by 4% (while often tying up several hours of valuable time per participant).

Recent studies have confirmed that code review can be effective without meetings. Jason Cohen, founder of Smart Bear Software®, conducted a study[3] at Cisco Systems® that showed that a lightweight peer code review approach was as effective as a heavyweight code inspection process, but more time-efficient by a factor of 7x.

Yet even agile devotees who recognize that meetings are not required have misconceptions about code review: “We only use the latest techniques here – code review is from the past and provides no value,” or “All the unit tests pass, so why do we need to do code reviews?” If you take away the meetings and the heavyweight process, but leave the interaction, responsiveness, and dedication to continuous improvement, then code review is very much an agile practice.

How Does Code Review Align With Agile?
Delving into the underlying principles[2] of the Agile Manifesto provides specific evidence that code review is agile:

Working software is the primary measure of progress. Software developers are fallible, just like all other humans. We make mistakes. Some of those mistakes can be detected automatically (unit tests, static analysis tools, etc.) but just as professional writers have human editors in addition to spell-check software, software developers benefit from having one or more other developers examine their source code. It is interesting how much time we spend during an iteration discussing the requirements with our stakeholder(s) and the emerging design and architecture with other software developers, but when it comes time to actually write the code the tendency is for each developer to work in isolation. The interaction during discussions of requirements, architecture, and design uncovers flaws. The same principle applies to the writing of the code. Code reviews uncover flaws and have another key benefit that is prized by agilists – the feedback is kept close to the point of creation and happens sooner – before the code gets to QA or customers.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. That’s a tall order. To help meet it, agile teams frequently practice collective code ownership. The goal is that each portion of the source code is understood by more than one member of the team. To reach that goal, it is important to pay attention to the bus number for each part of the code – how many team members would have to get struck by a bus before no one was left that understood the code? If the bus number for a section of the code is less than two, then that’s a problem. By encouraging the reading and discussing of the source, code review helps maintain collective code ownership, increasing the bus number for the reviewed code. That way, if a team member is on vacation, or leaves the team, progress can continue at the same pace.

Continuous attention to technical excellence and good design enhances agility. All software developers have egos and most of them are naturally curious people who enjoy learning new things. Developers who know that their code will be reviewed tend to write better code because they know that their reputation is on the line. No one wants to be thought of as the weak link in the chain. A corollary is that developers who review other’s code get an opportunity to learn new tricks and techniques. A key step in mastering any craft is to benefit from the experience of others.

Types of Lightweight Code Review
Lightweight code review provides the right mix of code review process with agile practice, allowing effective and efficient code reviews without overwhelming burden. There are four different approaches to doing lightweight code review in an agile environment. Each has its strengths and weaknesses and they are not mutually exclusive, so there is no single right or wrong approach. As with so much in the agile world, each team needs to decide for itself which approach is correct.

1. Over the shoulder. This is the easiest technique of all: when it is time for a code review, find a developer and sit down with him or her in front of the code. Face to face communication is an easy, high-bandwidth medium for the author’s explanation of the code. An obvious drawback is that not all teams have all members in one location. An additional issue is that the reviewer is being interrupted – after the review it will take time for that developer to get back to the same level of productivity. The biggest risk with this sort of approach, though, is that it can end up being a walk through instead of a review. If the reviewer has no prior access to the materials then typically the author does most of the talking, which can result in a passive reviewer who spends more time nodding than asking questions about the code.
2. Email pass-around. When the code is ready, send it out over email. One of the advantages of this approach is that reviewers and authors can be in different locations. Another advantage is that the reviewers can do the review at their convenience. One obvious downside is that as the review proceeds and the emails get nested in multiple replies, it becomes more difficult to follow the conversation. And if files are reworked and line numbers change, it can be challenging to determine which version of a file – or even which line – is being referenced by a particular comment. But perhaps the biggest drawback is that it can be difficult to answer a simple question: When is the review finished?
3. Pair programming. One of the Extreme Programming world’s key contributions has been pair programming, which in some ways is a continuous code review. The advantages are that no workflow or tools or interruptions get in the way. Further, the review is at a deep level since the developer who is reviewing has the same level of experience with the code. One obvious downside is that the time commitment is non-trivial. A less obvious downside is that the reviewer is “too close” to the code to give it a good review. After all, a key benefit of code review is to get outside opinions. If two developers are pairing to the extent that they have the exact same view of the code then the code review will likely not be as effective.
4. Tool-assisted review. Code review tools exist to help overcome the shortcomings of the approaches listed above. They can package up source files, send notifications to reviewers, facilitate communication, ensure defects are fixed, and more. The obvious downside is that they require at the very least time for installation and configuration, and in the case of commercial products, money for license purchases. A popular tool for peer code review is Code Collaborator (http://www.codecollaborator.com).

Techniques for Optimal Code Reviews
Regardless of which type of lightweight code review your team chooses, there are tips and techniques[5] for preventing wasted time and improving the results:

• Limit the amount of time – a developer should spend no more than sixty to ninety minutes at a time doing code review.
• Go slowly – typically 200 to 500 lines of code per hour is the maximum rate for an effective review.
• Limit the amount of code – as a product of the time and rate recommendations, the total amount of code for a review should be no more than 200 to 400 lines.
• Have the author annotate the materials before the review starts. Just looking at the code using a different tool than their standard editor can lead developers to spot problems in their own code before the review begins.
• Review checklists (if used) should be short, contain no items that are obvious or can be detected via automation, and should focus on things that are easy to forget (e.g. “Are all errors handled correctly everywhere?”).

Overcoming Resistance
A key Agile Principle[2] is: “The best architectures, requirements, and design emerge from self-organizing teams.” If peer code review is mandated by someone outside the team, its chance of success decreases. If team members do not want code review to succeed, it will fail.

Even when suggested by a team member, code review can still face resistance. A key to success is to start slowly. Do not attempt something like: “Starting today 100% of all code written must be peer reviewed.”

The key is to instead get the best return on time invested by initially doing code reviews only on a limited part of the source code. For example, one approach is to have the developers agree on the “top ten scariest source files” and then only review changes to those files. Or only review changes made to the stable branch of the source code. A slightly more extreme approach would be to just review unit tests – if the unit tests are complete and are passing, then those results indicate the underlying implementation is correct without investing additional review time.
The amount of code that gets reviewed can be expanded after a team has experience with code review and sees its value over time.

Summary
Peer code review is agile, when done correctly. The legacy of heavyweight code inspection processes has biased many agile developers away from code review, but there are multiple types of lightweight code review that work well in an agile environment. With the right approach and techniques, and by phasing in the use of code review over time, agile teams can more easily deliver working – and high quality – software.

Learning More
Read about the results and other insights in the book, Best Kept Secrets of Peer Code Review, written by the founders and associates of Smart Bear Software. Request a free copy of this book at http://www.CodeReviewBook.com.

References

1. The Agile Manifesto, http://agilemanifesto.org/, 2001.
2. The Agile Manifesto Principles, http://agilemanifesto.org/principles.html, 2001.
3. Jason Cohen, Best Kept Secrets of Peer Code Review, http://codereviewbook.com, 2006.
4. M. E. Fagan. “Design and code inspections to reduce errors in program development.” IBM Systems Journal, 15(3):216-245, 1976.
5. Smart Bear Software, 11 Best Practices of Peer Code Review, http://smartbear.com/docs/BestPracticesForPeerCodeReview.pdf, 2007.
6. Lawrence G. Votta, Jr., “Does every inspection need a meeting?” Proceedings of the 1st ACM SIGSOFT symposium on Foundations of software engineering, p.107-114, December 8-10, 1993, Los Angeles, California, United States.

Sound Off!
We value your input regarding this newsletter. Please take 2 minutes to fill out a survey (5 quick questions) that asks your opinion about this newsletter: Click here to take survey:

http://www.surveymonkey.com/s/7KKWHC9

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

1. Software Planner - http://www.SoftwarePlanner.com
2. TestComplete (Automated Testing Tool) - http://www.TestComplete.com
3. Code Collaborator (Peer Code Review Tool) - http://www.SmartBear.com
4. Software Development /QA Templates -http://www.softwareplanner.com/Templates.asp
5. Test Case Training - http://www.SoftwarePlanner.com/Services.asp
6. Pragmatic Agile Development - http://www.softwareplanner.com/PADOverview.pdf

Reducing Costs with Good Requirements and Code Reviews

Teams constrained by resources are always looking for a competitive advantage in reducing costs and improving software quality. This advantage can be achieved by implementing two best practices:

1. Writing good requirements
2. Providing peer code reviews

Studies have proven that the later a defect is discovered, the more it costs a team to fix. A study conducted by Dunn - "Software Defect Removal" - found that a defect that costs $1000 to fix when discovered during requirements analysis costs $25,000 to fix when left undiscovered until the quality assurance testing phase. Another study conducted by Jason Cohen, highlighted in his book - "Best Kept Secrets of Peer Code Review" showed that defects cost half as much to fix when found during code review vs. when discovered during quality assurance testing.

Defining Good Requirements
A good requirement contains these elements:

• A narrative that explains what the requirement is going to accomplish
• A prototype that depicts exactly what is expected (screen shots, report layouts, etc.)
• A list of validation rules (e.g. allowable field sizes, allowed values, data validation, etc.)
• A list of security rules (e.g. only administrators can access specific features)
• A list of performance criteria (e.g. must be able to add a record in 3 seconds or less)
• A list of audit rules (e.g. when adding or changing a record, store the history of the change)
• Success criteria (e.g. objective criteria that can be evaluated to ensure this requirement meets the need)

Let's explore how taking this approach saves costs. Imagine we needed to develop a new screen to track our customer contacts and the screen entry needed to collect company name, contact name, email address and phone number. A poor requirement would simply describe the process (e.g. "create a data entry screen for collecting contacts") but would not include any of the other descriptive elements.

Without a prototype to guide him, the programmer might take liberties and design a screen that had a lot of ancillary fields (like birth date and marriage status) that may not be needed and may not include important fields (like email address and phone number). If no validation rules are specified, the programmers may not test a scenario where a new contact is added whose email address is the same as an existing contact -- causing a duplicate contact record.

If no security rules are identified, the screen may allow anyone to delete a contact and this may cause your team to lose an important contact record. If no performance criteria are set, the team may not test a scenario where you have 100,000 contacts in your contact list and your new software may slow to a crawl. If no audit rules are in place and a person deletes a contact, you may never know who deleted an important contact and why.

With a good QA team, many of the issues above would shake out during the quality assurance phase. However, the cost of discovering these issues and re-working the code is dramatically higher when discovered at this time. If the requirements had been written using the detailed elements above, the programmer would not have taken liberties to add additional fields and leave out important ones, they would have stress-tested the solution with large number of contacts, they would have implemented validation logic to ensure all fields were validated, they would have added logic to prevent duplicate records and would have audited records when deleted.

Defining good requirements is equally crucial for Waterfall and Agile projects -- the difference is that Agile projects will break the requirements into smaller units of work that are described by User Stories (what a user wants to do in each case). In our example above, a Waterfall approach would define all of the elements of each requirement at the outset of the project. An Agile approach would break each of those elements into separate User Stories (a User Story for the prototype, a User Story for the Validation Rules, etc.) and would incrementally implement each item in an iterative fashion.

It's also imperative to review requirements as a team (internal teams and client) once they are developed but before they are signed off. The review process lets extra eyes ensure that the elements above are addressed and that the requirement will meet the actual need.

Reducing Defects with Peer Code Reviews
As code is developed, it is important to review the code with your team. Below are a few items to look for in code reviews:

• Ensure the code functionality meets the specifications in the requirement
• Ensure each subroutine contains proper error trapping and handling
• Inspect logic errors that can cause looping, memory leaks and performance issues
• Inspect variable declarations to ensure that variables are cast properly to reduce boundary issues and invalid type casting
• Review coding standards to ensure the code meets your internal standards, is well documented, and easy to maintain

The most efficient way to perform code reviews is to have team members inspect the code (called Peer Code Reviews) on a regular basis and openly discuss possible issues discovered during the code review. This activity can be done before checking the code in (called "pre commit") or after checking the code in (called "post commit"). The decision for pre or post commit is entirely up to your team and the way your team works best together.

By inspecting the code regularly, you can discover defects earlier in the development cycle which, like writing clear and detailed requirements, will reduce costs. Imagine a scenario where you reviewed the code and noticed that no logic had been added for preventing duplicate records from being added.

By discovering the issue prior to testing, you eliminate costly QA time to discover and report the issue. And if QA doesn't find the issue, you will spend exponentially more fixing it once the software has shipped to customers.

From a technical perspective, imagine a scenario where you had some logic that reads data from a database using a record set, then executes a loop over and over again until all the data is processed. A common programming mistake is not checking for a "no data found" or "end of file" condition.

A peer code review could quickly discover that the loop may be entered even if no data was loaded into the record set, which will only cause a failure under that condition. If this defect is not found until QA testing, your QA testers may see erratic behavior where it works sometimes (when data is found) but not other times (when no data is found). It may take your QA testers 2 to 3 days to discover the actual issue, so you have just added several days of effort to a problem that could easily have been discovered during a peer code review.

Reduce Project Costs with These Best Practices
Obviously, the sooner in your development cycle that you identify discrepancies in requirements and find defects, the less expensive the corrective measures will be. By writing good, detailed, and clear requirements at the outset of a project, and by having both team members and customers review them, you ensure that developers spend their time building the right thing the first time. By doing peer code reviews on your code before it goes to QA, you ensure that bugs are found immediately, while they are still easiest – and cheapest – to fix.

Can Tools Help?
Tools can help you with both of these issues.

Software Planner (http://www.SoftwarePlanner.com) allows you to keep all your requirements in a single place and allows your team to setup workflow to ensure that requirements are reviewed for best practices. Software Planner works equally well for Waterfall and Agile environments and allows teams to spot issues with requirements before it is too late and more costly to fix.

Code Collaborator (http://www.CodeCollaborator.com) allows your team to conduct peer code reviews online, a task that is painfully tedious and error prone without a tool.

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

• Software Planner - http://www.SoftwarePlanner.com
• TestComplete (Automated Testing Tool) - http://www.TestComplete.com
• Code Collaborator (Peer Code Review Tool) - http://www.SmartBear.comSoftware Development /QA Templates -http://www.softwareplanner.com/Templates.asp
• Test Case Training - http://www.SoftwarePlanner.com/Services.asp
• Pragmatic Agile Development - http://www.softwareplanner.com/PADOverview.pdf

The Seven Habits of Highly Effective Agile Scrum Product Owners

Published in 1989, The Seven Habits of Highly Effective People, written by Stephen R. Covey has helped millions establish great habits for achieving true interdependent effectiveness in their life and their jobs. This article discusses the 7 habits, framing the habits for highly effective Agile Scrum Product Owners. Below are the 7 habits:

1. Be Proactive
2. Begin with the End in Mind
3. Put First Things First
4. Think Win/Win
5. Seek First to Understand, Then to be Understood
6. Synergize
7. Sharpen the Saw

Pre-Requisite Information
This newsletter discusses habits for highly effective Agile Scrum Product Owners. If you are not familiar with Agile or Scrum, please see our newsletters at http://www.PragmaticSW.com/Newsletters.asp, specifically those posted February 2008 - September 2008, those newsletters explain Agile Scrum in detail.

Habit 1 - Be Proactive
A Product Owner's goal in any software project is to ensure that the project produces the highest return on investment (ROI) in the shortest amount of time. Below are some ideas for being proactive on Agile software projects:

Communicate Sprint Rules to Management
Since the product owner is responsible for prioritizing the product backlog and is responsible for ROI, the product owner must communicate to his/her upper management that once the sprint begins, they can not push for new features in the sprint unless they are willing to abandon the sprint. Upper management sometimes tries to interfere with the sprint by introducing features not currently in the backlog and derailing team members with busy work that can cause the sprint to fall behind schedule. The product owner must communicate the rules to management and remind them if this behavior happens, the sprint must be aborted and a new sprint must be planned.

Meet Daily
It is important to participate in the Daily Scrum Meeting. This provide full transparency - if you review progress, status and impediments daily, you should never be surprised if tasks begin to slip and you can proactively resolve those to reduce slippage. When meeting daily, hold the meeting first thing in the morning and try to keep the meeting to 30 minutes or less. Here would be a typical agenda for the meeting:

• Review progress - Do this by analyzing a project burn down chart. This shows how well you are progressing towards completion of the project.
• Identify slippage - After reviewing progress, identify if anyone is slipping in their tasks and brain storm on helping them catch up.
• Remove Roadblocks - Ask if anyone is experiencing impediments and roadblocks. Help clear those roadblocks.

Learn More: http://www.pragmaticsw.com/WhitePaper_SP_Metrics.pdf

Habit 2 - Begin with the End in Mind
Your end goal for a sprint should be to deliver software that could be released to production if needed (high quality is important). Before the sprint begins, you should make a list of success criteria that you judge the sprint on. For example, your success criteria may be that the certain backlog items are complete, has no known defects (or a small number of low severity defects), is reusable, is maintainable, is well documented, is easy to use, etc. By defining the success criteria up front, you can objectively evaluate whether the project met the criteria or not. Below are some tips for ensuring your meet your success criteria at the end:

• Identify success criteria - Make sure your success criteria is published and agreed upon by the team members.
• Review success criteria - At least weekly (in one of your Daily Scrum Meetings), review the success criteria. This can include reviewing your defect statistics, test case run history, etc. to allow you to determine if you are progressing towards the success criteria as the sprint continues.
• Retrospective - Once your project is complete, do a "retrospective" to determine if you met your success criteria.

Learn More: http://www.softwareplanner.com/Newsletters/newsletter_2008_08_SP.htm

Habit 3 - Put First Things First
Prioritizing the product backlog is critical. You must apply effort to the most important things first, followed by less important things because this directly affects ROI.

• Prioritize the Product Backlog - When planning a sprint, it is important to ensure that the most important features are being worked on during the sprint. To do this, prioritize the product backlog as high, medium and low (in terms of how it will impact ROI). Within the high priority items, prioritize the relative importance of those items (1 to 10, with 1 being the most important to ROI).
• Best Foot Forward - Review the product backlog priorities often. It is OK to change the priorities during the sprint for the items that have not yet begun to ensure that the items being worked on will benefit ROI in the best way.

Habit 4 - Think Win/Win
When dealing with projects, you want to foster a win/win relationship between your team and the client. The alternative to that is:

• Win/Loss - In this scenario, your team wins but the client loses. This can cause loss of future business with the client.
• Lost/Win - In this scenario, your team loses but the client wins. This can cause team burnout, financial distress and other issues.
• Win/Win - This is the scenario you want to foster. In this scenario, both your team and the client wins. How is it done? Normally this centers around the project management pyramid (Features, Time, Cost). To foster a win/win relationship, one of those variables must be flexible. Once your team and client agree to that, it is much easier to make objective decisions about how to plan the project. Here are examples:
  
  1. More Features / Less Time - The flexible variable is cost, so your client agrees to absorb more costs (you can hire more people).
  
  2. Cost Savings / Less Time - The flexible variable is features, so less features will be delivered but costs and time will be less.
  
  3. More Features / More Costs - The flexible variable is time, allowing you to extend the timeline.

Habit 5 - Seek First to Understand, Then to be Understood
Many of us have a bad habit of blocking out a conversation and not listening because we so desperately want our opinion to be heard. Every team member (Product Owner, Scrum Master, Team Members) has different experiences, different perspectives and motivations.

Before you can solve any problem, it is important to first listen intently and diligently to fully understand the problem. Once you feel you have all the facts, solicit ideas for multiple solutions. Having several options can provide better discussions and allows team members to tweak initial solutions into solutions that are more far reaching and solve the problem in a more direct way. If you disagree with an approach, don't attack the person that offered the approach. Instead, explain based on your past experiences why you think there might be a better approach.

Habit 6 - Synergize
For Agile teams, team collaboration and empowerment is the key to a synergized team. A synergized team is made up of divergent team members that have different strengths, different backgrounds and different perspectives. Encourage these differences but provide your team with tools that allow you maximize their effectiveness. Highly collaborative teams communicate with each other by sharing their calendars, posting their statuses into discussion forums so that everyone is aware of what the other is doing and accomplishing. These teams keep track of all tasks they work on each day, the number of hours worked, the number of hours remaining and variances to plan. They also share documents that illustrate best practices and produce white papers that teach others what they have learned.

Learn More:

• Tools - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=OverviewSoftwarePlanner
• Calendar Sharing - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=Calendar
• Discussion Forums - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=DiscussionBoard
• Task Tracking - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=ProjectPlans
• Document Sharing - http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=SharedDocuments

Habit 7 - Sharpen the Saw
Productive product owners see the need to continue honing their skills and love learning new techniques, best practices and approaches. They proactively learn about different ways to improve Agile projects. Below are some links that might be of interest to you:

• Agile Alliance - http://www.agilealliance.com/show/1641
• Yahoo Scrum Development Group - http://groups.yahoo.com/group/scrumdevelopment/
• Agile Project Management - http://finance.groups.yahoo.com/group/agileprojectmanagement/
• Agile Overview - http://www.pragmaticsw.com/Newsletters/newsletter_2008_02_SP.htm
• Team Composition - http://www.pragmaticsw.com/Newsletters/newsletter_2008_03_SP.htm
• Understanding Scrum Rules - http://www.pragmaticsw.com/Newsletters/newsletter_2008_04_SP.htm
• Scrum Kickoff and Product Backlog - http://www.pragmaticsw.com/Newsletters/newsletter_2008_05_SP.htm
• The 30 Day Sprint and Daily Scrum Meeting - http://www.pragmaticsw.com/Newsletters/newsletter_2008_06_SP.htm
• Agile Reporting and Metrics - http://www.pragmaticsw.com/Newsletters/newsletter_2008_07_SP.htm
• Retrospectives - http://www.pragmaticsw.com/Newsletters/newsletter_2008_08_SP.htm
• Tailoring Scrum to your Needs - http://www.pragmaticsw.com/Newsletters/newsletter_2008_09_SP.htm

Helpful Resources
Below are some helpful resources and templates to aid you in developing software solutions:

• Software Planner - http://www.SoftwarePlanner.com
• Automated Testing Resources - http://www.Star-QA.com
• Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
• Agile Training - http://www.PragmaticSW.com/Services.asp
• Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp

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:

• Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
• Mar 2008: Agile Scrum - Team Composition http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm
• Apr 2008: Agile Scrum - Understanding Scrum Rules http://www.pragmaticsw.com/newsletters/Newsletter_2008_04_SP.htm
• May 2008: Agile Scrum - Scrum Kickoff and Product Backlog http://www.pragmaticsw.com/newsletters/Newsletter_2008_05_SP.htm
• Jun 2008: Agile Scrum - The 30 day Sprint and the Daily Scrum Meeting http://www.pragmaticsw.com/newsletters/Newsletter_2008_06_SP.htm
• Jul 2008: Agile Scrum - Reporting and Metrics http://www.pragmaticsw.com/newsletters/Newsletter_2008_07_SP.htm
• Jul 2008: Agile Scrum - Retrospectives http://www.pragmaticsw.com/newsletters/Newsletter_2008_08_SP.htm

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:

• Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
• Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
• Software Planner - http://www.SoftwarePlanner.com
• Agile Training - http://www.PragmaticSW.com/Services.asp

Agile Scrum - Understanding Scrum Rules

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:

• Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm
• Mar 2008: Agile Scrum - Team Composition http://www.pragmaticsw.com/newsletters/Newsletter_2008_03_SP.htm

Understanding Scrum Rules
For Agile Scrum to be successful, you must have buy-in from the highest stake holders to the individuals doing the work and every individual must follow the rules. Below are the rules for Scrum:

• Obtain Number of Hours Commitment up Front - Before beginning an Agile 30-day sprint, each team member must commit to a certain number of hours for the 30 day sprint.
• Gather Requirements / Estimates up Front - The Product Manager will specify the sprint goal and the team will gather the requirements and provide an estimate up front. Once the estimates are done, the requirements are prioritized and only the ones that will fit into the sprint are worked on (based on estimated hours of all tasks vs. hours committed to by team members).
• Enter Time Daily - Each person on the team agrees to enter their actual hours and estimated hours remaining EVERY DAY.
• Daily Builds - Each programmer will check code in daily or more frequently if possible. The checked in code must be compilable. An automated process will create daily builds to prevent manual merging of code and allowing the Quality Assurance Engineer to test features of the sprint.
• No new Requirements for a Sprint - No new requirements can enter into the sprint unless all features of the sprint are completed. Management and other parties that are not directly involved in completing the features for the sprint are not allowed to direct actions of team members on items not included in the sprint. If an emergency feature is required by management, the sprint must be aborted and a new sprint must begin with the new feature set.
• Keep the Daily Scrum Meetings Short - Daily Scrum meetings are held to determine what things were done since the last Scrum meeting, what things will be done in the next Scrum meeting and what impediments stand in the way of any person on the team. The Daily Scrum meeting is designed to be completed in 15 minutes. If it takes 30 minutes, this is OK, but it should not extend longer than that without a solid business reason for it. Team members that show up to Daily Scrum meetings late are required to pay the Scrum Master a $1 fine.
• Code Inspections are Paramount - Upon completing a particular feature, the programmer should illustrate the feature to the team and show the code that drives the feature. The team should inspect the code for re-usability, cleanness, and adherence to established coding standards.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

• Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
• Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
• Software Planner - http://www.SoftwarePlanner.com
• Agile Training - http://www.PragmaticSW.com/Services.asp

Agile Scrum - Team Composition

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:
Feb 2008: Agile Scrum - An Overview http://www.pragmaticsw.com/newsletters/Newsletter_2008_02_SP.htm

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.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

• Pragmatic Agile Development -http://www.pragmaticsw.com/PADOverview.pdf
• Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
• Software Planner - http://www.SoftwarePlanner.com

Agile Scrum - An Overview

Agile Scrum - An Overview
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 blog is the first 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.

So what is Agile?
According to Wikipedia, Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. Simply put, Agile allows your team to identify the most critical features of the software that can be completed within a short time frame (normally 1 to 2 months), and it delivers a complete build with this set of limited features as the first iteration. Once that is done, you can move those features to production or continue on to the next iteration.

By breaking the releases into shorter stints, it allows you to gain quicker releases and to capture return on investment more quickly by putting the working (but limited) features into production sooner. This is in stark contrast to the more traditional "Waterfall" approach, where you design all features upfront, code each one, test each one, then move into production. Agile projects are iteratively released to production months where Waterfall projects normally span a year or more before they are released to production.

So what is Scrum?
Scrum is process of implementing Agile, where features are delivered in 30 day sprints. Scrum borrows its name from Rugby, where a sprint is the process of stopping play, then vigorously playing until the sprint ends and a new one begins. The same idea applies here, where you define the requirements for a 30 day sprint and work on them with vigor for 30 days without being sidetracked by other things or having things re-prioritized. A specific feature is not recognized as being completed until it is analyzed, designed, coded, tested, re-factored and documented. At the end of the 30 day sprint, most features defined in the 30-day sprint should be completed. If some did not get finished (because of being underestimated), the uncompleted features can be moved to a later sprint. A sprint is considered successful if all the completed features have high quality and can be put into production (or beta) upon ending the sprint.

Do Team Member Responsibilities Change?
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 CEO, CTO, or some other high level stakeholder that ultimately is responsible for shaping the roadmap of their product.
• 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 inspection, and ensuring everyone plays by the rules.
• 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.

So how does Scrum Work on a Day-by-Day Basis?
Scrum begins with an 8 hour Scrum Kickoff Meeting. The Scrum Kickoff meeting is divided into (2) 4 hour segments, where you first determine what features are desired for the 30 day sprint. The last 4 hours are used to provide rough estimates for the items identified for the sprint. If the estimates exceed the available resources, the features are prioritized and less important features are dropped from the sprint. An important component of Scrum is using a time-box approach, where meetings and events have a definite time period (e.g. no more than 8 hours for the kickoff meeting) and this time-box is strictly enforced. Once the features are locked in for the 30-day sprint, no changes are allowed (new features can not be introduced until the next sprint). When estimating features for a sprint, the estimates must include time for analysis, design, coding, testing, re-factoring, and documentation. A feature is not considered complete until all those things are done.

Each day, a Daily Scrum Meeting is held to determine how the features are progressing. The meeting is no longer than 15 minutes, and each team member is asked 3 questions:

1. What have you accomplished since the last Daily Scrum Meeting?
2. What will you do before the next Daily Scrum Meeting?
3. Is there anything that is impeding your progress (and remedies are discussed)?

From a programmer's perspective, Scrum development is a new paradigm which is very empowering but does require them to follow specific rules:

• Code is only checked out for the duration needed to complete a feature. No exceptions. Most code will be checked in daily, as most features are broken down into small feature sets.
• Time must be entered daily. For each feature, you will have estimated hours, actual hours and hours remaining to complete the feature. This information must be updated at the end of every day so that the ScrumMaster can determine if the release progress is trending as required.
• Programmers are not allowed to be pulled off on tangent projects, they must stick to the features they have been assigned for the sprint.
• All team members must attend the Daily Scrum Meeting and must be on time.

Code is compiled and deployed to a test server daily. Teams can use automated build tools to speed this process. Automated tests should be run against the daily releases to discover any issues introduced by the release.
Once a Scrum 30 day sprint is completed, all features that were completed can then been moved to a beta or production environment. Following the sprint is a Retrospective (post mortem), where team members discuss and document things that went well and things that can be improved upon in the next sprint.

Helpful Templates
Below are some helpful templates to aid you in developing software solutions on-time and on-budget:

• Software Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
• Software Planner - http://www.SoftwarePlanner.com