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 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:

• Project Management Institute (PMI) - http://www.pmi.org
• Information Technology Lab (ITL) - http://www.itl.nist.gov/
• Capability Maturity Model Integration (CMMI) - http://www.sei.cmu.edu/cmmi/

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:

• 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 Developers

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 developers. 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 developer's goal in any software project is to ensure that the software is developed to a requirement that meets the customer need and one that produces software that is reusable and maintainable. Below are some ideas for being proactive on software projects:

• Be Responsible for Great Requirements - Don't blame others for poor

requirements

. Instead, work with the team to fully analyze the requirements to ensure they are complete, accurate and meet the needs of the customer.

Analyze Reusability during Design - When creating a design, many developers look no further than the current requirement for their design. When creating a detailed design for the requirement, the developer should approach it to be used in other ways than fill the existing design need. For example, if you are designing a new system and it has 20 listing screens and 20 edit screens, it would be better to design a single listing and a single edit screen that can accommodate all 20 needs. The screens can look and feel different if needed, but you can still use the same code base by deploying "behaviors" that dictate how the screen operates. By making the screen reusable, you can then build additional listing and edit screens quickly because you are not re-writing code from scratch. It also helps in maintainability because if a major screen flaw is found, you are only fixing a single screen rather than 20 distinct screens.

Communicate Effectively - During development, it is imperative that everyone knows the status of the development effort. Communicate daily status via email or a discussion forum. Discuss any impediments that are keeping you from making progress. Discuss (briefly) what code modules you worked on for the day -- this allows others to know what areas you are working in and can proactively alert them if they are also working in an area that might causes issues based on the work you are doing.

Review Test Plans before Coding Begins - A great way to be proactive in decreasing QA time is to have your QA team publish test cases before coding begins. You should require that your developers review the test cases before beginning coding and that they run the test cases prior to shipping the code to QA for testing. This reduces QA time by validating that the test cases have good coverage for the requirement and by bringing to light things that the testers are expecting you to code for (validation issues, bounds, etc.). For this to be effective, you must build time into the project plan for the developers to do this. A good rule of thumb is to build 10% extra time into the project plan for this activity (if the coding is estimated at 200 hours, build 20 hours in for this activity). By doing this, you can expect a 30% decrease in QA time because you will minimize re-work, so the effort is worth the investment.

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.

Habit 3 - Put First Things First
Prioritizing your work effort is critical. You must apply effort to the most important things first, followed by less important things. For example, everyone will generally agree that creating reusable and easily maintainable code is important. However, in an effort to do this, developers have a tendency to "gold plate". "Gold plating" is when a developer adds bells and whistles to the feature that were not asked for and can easily increase the complexity and estimated hours needed to deliver the work. Be very careful with this.

It is great to create reusable code, but it does not have to handle every future scenario that you can dream up. Instead, stick with the stated features needed but organize the code in a way that makes it easy to extend and improve in future releases. As you develop the code, do team code reviews to identify how to better reuse code, to spot troubled code and to reorganize for maximum maintainability.

Habit 4 - Think Win/Win
In many organizations, development and testing teams play a blame game and create tension between the teams. This can be very disruptive and can greatly affect the quality of the software project and the user experience. The development and testing teams should have a common goal -- to ensure that the client receives the software with the highest of quality. If this is a unilateral goal of the team, it makes sense for all team members to provide help and encouragement to each other so that when the software is shipped with high quality and the client is happy, everyone on the team basks in the joy of a happy client. If you want to encourage an environment of trust, respect and foster an win/win team, here are a few tips:

• Share Knowledge - Don't hold your knowledge to yourself, share it with others.
  Socialize - Eat lunch with members in different roles in your company. Learn more about them, take a general interest in their hobbies and personal goals.
• Encourage Others - Offer congratulations and compliments to team members that you see are doing a great job. Tell your (and their) manager how well you think they are doing. Tell them how much you appreciate their efforts.
• Help Struggling Team Members - If you see team members struggling, jump in and offer to help. If you offer, follow through and ensure they get the help they need. You may need help in the future so offering help can foster a win/win relationship for you in the future.

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 developer and team member has a 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.

To get started with this, schedule time weekly for code reviews. Code reviews allow people with different experiences and skill levels to objectively evaluate your coding structure and style and make recommendations for maximum reuse and maintainability. You also will learn a lot in the process and allow yourself to approach challenges in a different way.

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 developers see the need to continue honing their skills and love learning new techniques, best practices and approaches. They have a thirst for knowledge, reading every development book they can get their hands on. They also know when to have fun. They recharge their batteries by taking great vacations and by having outside hobbies and activities. Here are a few of our favorite development books:

• Agile Project Management with Scrum - by Ken Schwaber, Microsoft Press
• The Enterprise and Scrum - by Ken Schwaber, Microsoft Press
• Code Complete - by Steve McConnell, Microsoft Press
• Rapid Application Development, by Steve McConnell, Microsoft Press

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 Testers

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 testers. 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 tester's goal in any software project is to ensure that the software is delivered with high quality. When software projects fail due to poor quality, you can either be proactive or reactive when analyzing what caused it. If you are reactive, you will blame other people and circumstances for problems or obstacles. If you are proactive, you will take responsibility for the failure and find ways to correct it in future projects. Upon completion of every project, your team should do a "post mortem" or "retrospective" where you openly discuss things that were done successfully in the project and things that were done poorly. Below are some ideas for being proactive on future projects:

• Be Responsible for Great Requirements - Don't blame others for poor requirements. Instead, work with the team to fully analyze the requirements to ensure they are complete, accurate and testable.
• Analyze Traceability - Creating a traceability matrix of test cases for each requirement allows you to analyze the test cases for coverage, testability, and completeness. Proactively hold team meetings to review your test cases to ensure you have fully understood the requirement and have adequate test coverage. Post your test cases for the development team to review before coding begins, this will reduce rework and QA time.
• Communicate Effectively - During testing, it is imperative that everyone knows the status of the testing effort. Communicate daily status via email or a discussion forum. Include metrics like defect counts, requirement coverage, number of test cases run, passed, failed, and awaiting run, etc.
• Describe Defects Effectively - When creating defects, spend time creating a good defect description, steps to reproduce and expected results. Include screen shots and as much information as needed to fully reproduce the issue. This will reduce QA rework.

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. 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 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, 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.

Habit 3 - Put First Things First
Prioritizing your work effort is critical. You must apply effort to the most important things first, followed by less important things. For example, everyone agrees that negative testing is important to ensure that software gracefully handles scenarios where the user tries things that are not normally done and it was not designed to do. But when stacked up against positive testing, negative testing is definitely less important. So begin your testing effort by testing the software to ensure it works as designed and test it vigorously for this. Once that effort has been completed, then perform your negative testing (testing bounds, invalid data entry, overflow, injection, etc.).

Habit 4 - Think Win/Win
In many organizations, development and testing teams play a blame game and create tension between the teams. This can be very disruptive and can greatly affect the quality of the software project and the user experience. The development and testing teams should have a common goal -- to ensure that the client receives the software with the highest of quality. If this is a unilateral goal of the team, it makes sense for all team members to provide help and encouragement to each other so that when the software is shipped with high quality and the client is happy, everyone on the team basks in the joy of a happy client. If you want to encourage an environment of trust, respect and foster an win/win team, here are a few tips:

• Share Knowledge - Don't hold your knowledge to yourself, share it with others.
• Socialize - Eat lunch with members in different roles in your company. Learn more about them, take a general interest in their hobbies and personal goals.
• Encourage Others - Offer congratulations and compliments to team members that you see are doing a great job. Tell your (and their) manager how well you think they are doing. Tell them how much you appreciate their efforts.
• Help Struggling Team Members - If you see team members struggling, jump in and offer to help. If you offer, follow through and ensure they get the help they need. You may need help in the future so offering help can foster a win/win relationship for you in the future.

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 tester and team member has a 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 testers see the need to continue honing their skills and love learning new techniques, best practices and approaches. They have a thirst for knowledge, reading every testing book they can get their hands on. They learn how to make their jobs easier -- by automating test cases and applying best practices that reduce QA time and increase software quality. They stay in touch with the testing community by visiting testing sites like Sticky Minds, QA Guild and others. They also know when to have fun. They recharge their batteries by taking great vacations and by having outside hobbies and activities.

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