Is your team missing delivery dates? Is your velocity inconsistent from sprint to sprint? Are customers complaining about defects or the time it takes to add new features? These are signs that you are mired in technical debt-a metaphor that describes the long-term costs of doing something in a quick and dirty way and not going back to clean up the mess. Fadi Stephan shares a technical debt management approach to help you make prudent decisions on how much effort to invest in reducing technical debt. Discover ways to measure the quality of your current code base and determine the cost of eventual rework hanging over your system. Learn how to engage executives and get buy-in on a debt removal plan that will improve system design, increase the quality of your code, and return your team to high productivity. If you are burdened with technical debt, the choice is to pay now or continue paying more every day-forever.

Don’t let anyone tell you differently: agile testing is hard! First, we have to get over the misconception that you don’t need testers within agile teams. Then, we have to integrate testers with the developers and engender a holistic quality approach. And those are only the challenges when the going is easy! In more difficult contexts, testing in agile environments is-well, even more difficult. Bob Galen explores how to handle testing in difficult contexts-lack of test automation capabilities, agile in highly regulated environments, testing when your team is spread globally and real-time interactions are nearly impossible, and more. He describes contexts and approaches for blending existing, traditional testing techniques with their agile counterparts. With real-world examples, Bob describes how teams have achieved a good working balance between the two-for example, in test planning and quality metrics reporting.

Testers and managers have wrestled with the problem of evaluating software products and testing efforts, often using approaches derived from manufacturing, construction, and physical sciences. These approaches have been partially successful because software products aren't physical products.

Many managers look to formal techniques-requirements reviews, code inspection, and testing-to improve the quality of their software. While these techniques are valuable, they only evaluate the state of quality rather than improve it. The key is to create quality software in the first place. This can only be achieved by a change in management style. Jason Bryant proposes a set of simple and effective principles you can employ to produce high quality software. First, you must foster a culture where people are given the freedom, time, and resources to do the job correctly the first time. By embracing user centered and incremental development practices, you will go a long way toward ensuring accurate and timely software delivery. Focus on training your staff to become masters of their craft and invest equally in architecture, new features, and maintenance.