Tuesday, December 22, 2009

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:

Basics of Test Driven Development (TDD)

If you've heard of Test Driven Development (TDD) before but was not sure what it was or how it works, this newsletter provides a summary of the approach.

What is Test Driven Development?
Test Driven Development is a unique way to develop software by starting the process by collecting a requirement, developing test cases for the requirement, followed by the coding process. For traditional development and testing shops, this process "feels backwards" because traditional approaches perform the coding before beginning testing. However, this approach has been used for years by Agile Development teams.

So how does it Work?
For TDD to work, create your test cases using an automated testing tool and then write the code that causes the automated test(s) to pass. So here are the steps:
  1. First fully understand the requirement
  2. Create automated test(s) that test the requirement
  3. Create the coding logic -- test it by running the automated test(s)
  4. Once the automated test(s) pass, the coding then fulfills the requirement
  5. Re-factor the code for better maintainability, run the automated test(s) again to ensure it still works
What are the Advantages of TDD?
Studies have shown that Test Driven Development reduces defect density, improves software quality, and in some cases make team productivity higher. Empirical Software Engineering Journal published a paper that summarized 4 cases studies (1 at IBM, 3 at Microsoft), where they followed the TDD practice and evaluated the effectiveness of it. For more information on this study, visit
http://www.infoq.com/news/2009/03/TDD-Improves-Quality.

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
  • Software 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
  • 15 Useful Test Cases for ensuring Consistent User Interfaces

    When testing user interfaces, it is easy to overlook test cases that ensure that your user interface is user-friendly and consistent. This newsletter identifies 20 test cases that might be considered when testing user interfaces for consistency.

    15 Useful Test Cases for ensuring Consistent User Interfaces
    1. Screen Font Type - Ensure that the screen font family matches from screen to screen. Mismatching fonts within the same sentence and overuse of different fonts can detract from the professionalism of your software user interface.
    2. Screen Font Sizes - Ensure that the screen font sizes match from screen to screen. A good user interface will have an accompanying style guide that explicitly defines the font type and size for headers, body text, footers, etc.
    3. Colors - Ensure that screens do not use different color sets as to cause an inconsistent and poorly thought-out user interface design. Your style guide should define header colors, body background colors, footer colors, etc.
    4. Icons - Ensure that icons are consistent throughout your application by using a common icon set. For example, a BACK link that contains an icon next to it should not have a different icon on one screen versus another. Avoid free clip-art icons, opt for professionally designed icons that complement the overall look and feel of your screen design.
    5. Narrative Text - Having narrative text (screen instructions) is a great way to communicate how to use a specific screen. Ensure that narrative text appears at the same location on the screen on all screens.
    6. Brevity - Ensure that narrative text, error messages and other instructions are presented in laymen's terms but are brief and to-the-point.
    7. Dialog Box Consistency - Use a style guide to document what choices are available for dialog boxes. You should have not have Save/Cancel dialog on one screen and an OK/Cancel on another, this is inconsistent.
    8. Links - If your application has links on the screen (e.g. Save as Spreadsheet, Export, Print, Email, etc.), ensure that the links have consistent spacing between them and other links, that the links appear in the same order from screen to screen, and that the color of the links are consistent.
    9. Menus - If your application has menu items, ensure that menu items that are not applicable for the specific screen are disabled and the order in which each menu item appears is consistent from screen to screen.
    10. Buttons - If your application has buttons (e.g. Submit, OK, Cancel, etc), ensure that the buttons appear in a consistent order from screen to screen (e.g. Submit then Cancel).
    11. Abbreviation Inconsistencies - If your screens contain abbreviations (e.g. Nbr for number, Amt for amount, etc), the abbreviations should be consistent for all screens in your application. Again, the style guide is key for ensuring this.
    12. Delete Confirmations - It is a good practice to ask the user to confirm before deleting an item. Create test cases to ensure that all delete operations require the confirmation. Taking this a step further, it would also be great to allow clients to turn off specific confirmations if they decide to do this.
    13. Save Confirmations - It is good practice to ask the user to confirm an update if updates are made and they navigate to another item before explicitly saving. Create test cases to ensure that all record movement operations require the confirmation when updates are made. Taking this a step further, it would also be great to allow clients to turn off specific confirmations if they decide to do this.
    14. Grammar and Spelling - Ensure that you have test cases that look for grammar or spelling errors.
    15. Shortcuts - If your application allows short cut keys (like CTRL+S to save), ensure that all screens allow using of the consistent shortcuts.

    By the way, did you notice any inconsistency above? We intentionally showed 15 useful test cases above but the narrative before the listing shows 20 test cases. Inconsistencies are easy to spot, right?

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

    20 Useful Test Cases for testing User Interfaces

    When testing user interfaces, it is easy to overlook test cases that would be helpful for a more thoroughly tested solution. This newsletter identifies 20 test cases that might be considered when testing user interfaces.

    20 Useful Test Cases for testing User Interfaces
    1. Required Fields - If the screen requires data entry on a specific field, it is good practice to identify the required fields with a red asterisk and to give a friendly warning if the data is left blank.
    2. Data Type Errors - If the screen contains dates, numeric, currency or other specific data types, ensure that only valid data can be entered.
    3. Field Widths - If the screen contains text boxes that allow data entry, ensure that the width of data entered does not exceed the width of the table field (e.g. a title that allows 100 characters in the database should not allow more than 100 characters to be entered from the user interface).
    4. Onscreen Instructions - Any screen that is not self-explanatory to the casual user should contain onscreen instructions that aid the user.
    5. Keep Onscreen Instructions Brief - While onscreen instructions are great, keep the wording informative, in layman's terms, but concise.
    6. Progress Bars - If the screen takes more than 5 seconds to render results, it should contain a progress bar so that the user understands the processing is continuing.
    7. Same Document Opened Multiple Times - If your application opens the same document multiple times, it should append a unique number to the open document to keep one document from overwriting another. For example, if your application opens a document named Minutes.txt, if it opens the same document for the same user again, consider having it append the time to the document or sequentially number it (Minutes2.txt or Minutes_032321.txt).
    8. Cosmetic Inconsistencies - The screen look, feel and design should match the other screens in your application. Creating and using a style guide is a great way to ensure consistency throughout your application.
    9. Abbreviation Inconsistencies - If your screens contain abbreviations (e.g. Nbr for number, Amt for amount, etc), the abbreviations should be consistent for all screens in your application. Again, the style guide is key for ensuring this.
    10. Save Confirmations - If your screen allows changing of data without saving, it should prompt you to save if you move to another record or screen.
    11. Delete Confirmations - If a person deletes an item, it is a good idea to confirm the delete. However, if your user interface allows deleting several records in a row, in some cases you might consider allowing them to ignore the confirmation as it might get frustrating to click the confirmation over and over again.
    12. Type ahead - If your user interface uses combo boxes (drop down lists), be sure to include type ahead (if you have hundreds of items in a list, if you type in the first letter it will skip to the first item that begins with that letter).
    13. Grammar and Spelling - Ensure that you have test cases that look for grammar or spelling errors.
    14. Table Scrolling - If your application lists information in table format, if the data in the table extends past one page, the scrolling should scroll the data but leave the table headers in tact.
    15. Error Logging - If fatal errors occur as users use your application, ensure that your applications writes those errors to a log file, event viewer or a database table for later review. Log the routine the error was in, the person logged on, and the date/time of the error.
    16. Error Messages - Ensure that error messages are informative, grammatically correct, and not condescending.
    17. Shortcuts - If your application allows short cut keys (like CTRL+S to save), test each shortcut to ensure it works in all different browsers (if the application is web based).
    18. Invalid Choices - Do not include instructions for choices not available at the time. For example, if a screen cannot be printed due to the state of the data, the screen should not have a Print button.
    19. Invalid Menu Items - Do not show menu items that are not available for the context you are currently in.
    20. Dialog Box Consistency - Use a style guide to document what choices are available for dialog boxes. You should have not have Save/Cancel dialog on one screen and an OK/Cancel on another, this is inconsistent.
    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.comSoftware Development /QA Templates -http://www.pragmaticsw.com/Templates.asp
  • Test Case Training - http://www.PragmaticSW.com/Services.asp
  • Pragmatic Agile Development - http://www.pragmaticsw.com/PADOverview.pdf
  • Benefits of Keyword Driven Testing for Test Automation

    Most software companies have considered automated testing and many have fully automated their regression test cases in an effort to reduce manual effort needed to test new builds of their software. Many companies that have been successful with automation attribute it to keyword driven testing techniques that reduce the time spent creating test cases.

    This newsletter addresses why companies consider automation and best practices for ensuring that time spent automating test cases provide a return on investment.

    Why Automate Your Test Cases?
    Many companies run their regression test cases manually, so when does it make sense to begin automating your regression test cases? It makes sense to automate your test cases when you can no longer run the regression test cases on each build created. For example, if you are doing daily or weekly builds of your code to quality assurance and you cannot quickly run your regression test cases with each build, it is time to consider automating them. Automating your test cases provide these benefits:

    • Quicker Releases – By having your regression test cases run automatically, your software quality team can concentrate on testing new features of your software and less time regressing existing features.
    • Higher quality releases – Your software releases will have fewer bugs and require less customer support because they will be of higher quality.
    • Happier Customers – Your customers will be happier and more willing to serve as testimonials for future prospects.

    Why Does Automation Fail?
    Many companies are thinking about test case automation or have experimented with it in the past. Some companies that experimented with it eventually abandoned it because of these reasons:

    • Poor Understanding of Test Automation – Many companies see automation as a silver bullet that will allow them to quickly automate every test scenario quickly and allow them to abandon manual testing and reduce staff. In reality, automated testing is designed to quicken the running of regression test cases but it is not a substitute for manual testing. A quality-oriented software team will see the value of utilizing both automated and manual test cases to ensure great test coverage and higher quality releases.
    • Improper Tester Education – Automation requires a tester to learn the testing tool. Companies that purchase the tool but not any training will eventually abandon the tool because the testers are not equipped to use the tool.
    • Lure of Record / Playback – Many companies think that they can quickly get up and running with automation by simply recording their screen actions and playing them back. While record and playback will create scripts that they can use as a starting point for your automation, it does take time to update the scripts to be more re-usable and it takes scripting language knowledge to do this.

    What is Keyword Driven Testing?
    Most automated tools require the test engineer to understand a scripting language (VB Script, Java Script, etc.) to write their automated test cases. Most tools have the ability to create the scripts using record and playback, but this does not always write the most efficient scripting code and is not as re-usable and maintainable.

    Since many testers do not have deep scripting skills, it is imperative that your automated testing tool has a way to create Keyword Driven Tests. Keyword Driven Testing is a way to define automated test cases without the need for scripting skills. It allows a tester (or even a subject matter expert) to create automated tests by describing each step of the automation.

    For example, if you are automating the login process of your application, your user will access your application, type in their user-id and password and press a button to login. Traditionally, testers would do this by writing VB Script that will navigate to your application, identify each object on the screen (user-id, password and login button), then write script to enter in the user-id, password and to press the login button.

    With keyword driven testing, the tester does not need to understand the scripting language to make this happen, they can simply describe the event (navigate to your application, enter in "abc" for the user-id, enter in "xxx" for the password, press the Login button when done). As you can imagine, this is a much simpler approach to automated testing than scripting.

    How have Successful Companies Implemented Automation?
    Successful companies understand the enormous benefits of automated testing and have implemented strategies to ensure that they receive the maximum return on investment with their test efforts. Below are the secrets to becoming successful with test automation:

    • Start Smart – Automation efforts are similar to software development efforts -- it takes upfront thought and a good test design architecture to ensure that your automated test cases will be re-usable and easy to maintain. Before jumping into automation, ensure that your automated tool has the ability to maximize your efforts with keyword driven testing -- as this will ensure that you can easily re-use your automated test cases.
    • Start Small – Start your automation efforts on an established project that already has a good set of manual regression test cases written. Take those manual regression test cases and develop your automated test cases that will replace them. Once this is done, you will find that you can automatically run those automated test cases each day of builds and with minimal efforts, freeing your team up to do more manual exploratory test cases. Once you have this established for a single project, move on to other projects and expand your effort.
    • Blend Automated and Manual Tests – Not all test cases should be automated. Some test cases require a human eye to ensure that screen cosmetics are appropriate, that data is reasonable, etc. Spend time automating test cases that do not require this type of human contact and continue to use manual test cases when appropriate. A good application lifecycle tool should allow you to track both automated and manual test cases.
    • Keep track of Metrics – Keep track of how many automated and manual test cases are run for each build, how many pass, how many fail, etc. Track how many additional automated test cases your team can write with each release so that you can determine average time needed to develop automated test cases in the future. Track how many defects are found post-production to determine if your automation efforts are paying dividends. A good application lifecycle tool should allow you to track metrics for both automated and manual test cases.
    • Build on your Successes – Once you have successfully implemented automated testing on a single project, roll it out to more projects. Help other teams in your organization learn the benefits of automation and help them do it right.
    • Schedule Your Automation Efforts - A good application lifecycle tool will allow you to organize your automated test cases into "test sets" that allow you to run test cases in a specific order. It should also allow you to schedule those test sets to run at specific intervals (nightly, weekly, monthly, etc.).

    How can I learn more about Test Automation?
    There are a number of automated and manual test management solutions on the market, as long as your selected solution allows you to follow the best practices of this newsletter, you can easily begin making the transition to automation and begin receiving a return on investment from your efforts.

    If you don't have a solution for both automated and manual testing, Software Planner (http://www.SoftwarePlanner.com) and TestComplete (http://www.testcomplete.com) offer an integrated solution that offers both automated and manual test cases and has a keyword driven testing engine that ensures re-usability and maintainability.

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

    The Seven Habits of Highly Effective Scrum Masters

    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 scrum masters. 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
    Habit 1 - Be Proactive
    A Scrum Master's goal in any software project is to empower team members to get things done and to remove impediments. Below are some ideas for being proactive on software projects:

    Run Daily Scrum Meetings
    Each day, your team should hold a Daily Scrum Meeting. Normally, this daily meeting is set for 15 minutes and each team member is asked 3 questions:
    1. “What did you do yesterday?”
    2. “What will you do today?”
    3. “Are there any roadblocks or anything impeding your progress?”
    15 minutes is not always enough time to have a good dialog and a meaningful meeting, some days may take 30 to 45 minutes. To speed this up, consider having each team member post a summary of what they did yesterday and a summary of what they plan to do tomorrow in a daily discussion forum that is automatically distributed to all team members. This allows you to spend the Daily Scrum meeting talking about roadblocks, design decisions, and impediments to progress.

    References:
    Discussion Forums -
    http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=DiscussionBoard

    Best Foot Forward
    A key way to reduce cost and time overruns is to prevent them during design. Some Agile evangelists might argue that doing user stories (which normally do not contain detailed requirements, prototypes or designs) is the best approach. Although our team has been using Agile for years, we found that user stories are not detailed enough, as they tend to cause too much rework and have a tendency to reduce the accuracy of estimates. Agile is designed to be flexible and tweaked for your specific needs so by deploying a more structured requirements gathering, we enjoy the flexibility of Agile and the reduction of rework, providing us with the best of both worlds.

    References:
    Requirements -
    http://www.pragmaticsw.com/GuidedTours/Default.asp?FileName=FunctionalSpecifications
    Detailed Design -
    http://www.pragmaticsw.com/Templates.asp

    Review Metrics Daily
    It is important to ensure that the Agile sprint will complete on time. You can ensure this by having team members enter their time daily and reviewing burndown and velocity charts.

    References:
    Burn Down Chart - http://www.pragmaticsw.com/WhitePaper_SP_Metrics.pdf

    Habit 2 - Begin with the End in Mind
    Your end goal for the sprint should be to deliver high quality software that meets the goals of the sprint. Before coding begins, you should make a list of success criteria that you judge the project on. For example, your success criteria may be that the software produces specific results, 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. Solicit help from all team members (product owner, scrum master, developer, tester, etc.) when defining the success criteria. By getting a team perspective of the success criteria, you will have better and more measurable criteria and you will get much better buy-in from the team. 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 team 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 project continues.
    • Retrospective - Once your project is complete, do a "post mortem" or "
    retrospective
    • " to determine if you met your success criteria.
    References:
    Retrospectives -
    http://www.softwareplanner.com/Newsletters/newsletter_2008_08_SP.htm

    Habit 3 - Put First Things First
    Prioritizing work effort is critical. You must apply effort to the most important things first, followed by less important things. Work the higher priority items first, then the lower priority items if time allows.


    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, developer, tester, etc.) 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
    Team collaboration 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.

    References:
    • 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 scrum masters see the need to continue honing their skills and love learning new techniques, best practices and approaches. Below are some links that might be of interest to you:
    • 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
  • 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
  • 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:

    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:

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

    Monday, December 21, 2009

    The Seven Habits of Highly Effective Project Managers

    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 project managers. 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

    Habit 1 - Be Proactive
    A project manager's goal in any software project is to ensure that the software is shipped on time, within budget, with high quality while satisfying the software requirements. Below are some ideas for being proactive on software projects:

    • Understand Your History - When planning projects, you should know what your variances have been on past projects (how many hours were estimated vs. how many hours were actually spent).
    • Best Foot Forward - A key way to reduce cost and time overruns is to prevent them during design. When collecting requirements, have your team review them for completeness and testability. Back the requirements with a detailed design and prototypes, as this allows you to better understand (and agree on) the solution and provides more detail for better estimates. Some Agile evangelists might argue that doing user stories (which normally do not contain detailed requirements, prototypes or designs) is the best approach. Although our team has been using Agile for years, we found that user stories are not detailed enough, as they tend to cause too much rework and have a tendency to reduce the accuracy of estimates. Agile is designed to be flexible and tweaked for your specific needs so by deploying a more structured requirements gathering, we enjoy the flexibility of Agile and the reduction of rework, providing us with the best of both worlds.
    • Communicate Effectively - During development, it is imperative that everyone knows the status of the development effort and to allow people to ask questions and get answers regarding specific requirements. To do this, communicate daily status and requirement questions via email or a discussion forum. Have developers discuss (briefly) what code modules they worked on for the day -- this allows others to know what areas they are working in and can proactively alert them if they are also working in an area that might causes issues based on the work they are doing. Have developers and testers ask questions about requirements and have subject matter experts respond to those questions with answers. This can dramatically reduce QA time.
    • Meet Daily - No matter if you are using Waterfall or Agile development, it is important to meet daily with your development and testing team to know the status of where things stand. 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.

    Habit 2 - Begin with the End in Mind
    Your end goal for a software project should be to deliver high quality software that meets the needs of the client using reusable and maintainable code. Before coding begins, you should make a list of success criteria that you judge the project on.

    For example, your success criteria may be that the software produces specific results, 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.

    Solicit help from all team members (project managers, product managers, testers, automation engineers, other developers, documentation specialists, etc.) when defining the success criteria. By getting a team perspective of the success criteria, you will have better and more measurable criteria and you will get much better buy-in from the team. Below are some tips for ensuring your meet your success criteria at the end:

    1. Identify success criteria - Make sure your success criteria is published and agreed upon by the team members.
    2. Review success criteria - At least weekly (in one of your daily team 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 project continues.
    3. Retrospective - Once your project is complete, do a "post mortem" or "retrospective" to determine if you met your success criteria.

    Habit 3 - Put First Things First
    Prioritizing work effort is critical. You must apply effort to the most important things first, followed by less important things. Many times a project can introduce cost and time overruns by small decisions that are made each day. The project manager must keep a close eye on these things to ensure that the project has the best chance of completing on time and on budget. Here are some examples of innocent "small" changes that could impact your project deliverables:

    • Feature Changes - Many times the team is tempted to make "small changes" to a requirement during the coding or testing phase under the guise of making the feature more attractive or usable. If the proper thought is put into the requirements, use cases, prototyping and design, the probability of this happening during coding or testing is less. A "small change" can impact many things. For example, imagine that a developer presents the case for enhancing a particular screen to have a bit different design than was originally set. Although making the coding changes might be minimal (a few hours), it is important to see that it might also trigger a change to the requirements document, the test cases, automated test cases, the help system and other documentation. So this "small" 4 hour coding change could turn into a 3 day impact on the overall project plan.
    • Enhancements Disguised as Defects - Sometimes testers will disguise an enhancement as a defect. If the developer is not familiar with how it was originally implemented (or why it was implemented this way), they may assume it is a defect and make a change that impacts existing clients. Although the tester saw this as a great change for their clients, it may impact clients that do not see it as a good change. To mitigate this, the project management and/or product owner should triage defects to ensure that they are true defects, not enhancement requests.

    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 (project manager, developer, tester, etc.) 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
    Team collaboration 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.

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

    Learning Agile - These newsletters explain the basics of Agile Scrum:

    1. Agile Overview - http://www.pragmaticsw.com/Newsletters/newsletter_2008_02_SP.htm
    2. Team Composition - http://www.pragmaticsw.com/Newsletters/newsletter_2008_03_SP.htm
    3. Understanding Scrum Rules - http://www.pragmaticsw.com/Newsletters/newsletter_2008_04_SP.htm
    4. Scrum Kickoff and Product Backlog - http://www.pragmaticsw.com/Newsletters/newsletter_2008_05_SP.htm
    5. The 30 Day Sprint and Daily Scrum Meeting - http://www.pragmaticsw.com/Newsletters/newsletter_2008_06_SP.htm
    6. Agile Reporting and Metrics - http://www.pragmaticsw.com/Newsletters/newsletter_2008_07_SP.htm
    7. Retrospectives - http://www.pragmaticsw.com/Newsletters/newsletter_2008_08_SP.htm
    8. 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: