"Are you done yet?" The answer to this question may sink your career, your team, and your project. If you respond with a "yes," you may be forced to take on additional work you can't handle. If you say "no," you may be branded as someone who can't get things done. Mitch Lacey notes that this innocent question is asked countless times on almost every software project. Establishing an upfront, common understanding of "done" can save teams and businesses countless hours of rework, process-thrash, unclear communication, and hidden work. Mitch describes what a "done list" is, how it adds value, and the value it communicates to stakeholders. Mitch takes you through an exercise on how to establish a common understanding of done and provides an exercise that you can use with your project teams.

Although the Agile Manifesto has worked well to help many organizations change the way they build software, the agile movement is now suffering from some backsliding, lots of overselling, and a resulting backlash. Brian Marick believes that is partly because the Agile Manifesto is almost entirely focused outwardly—it talks to the business about how the development team will work with it. What it does not talk about is how the team must work within itself and with the code. Even though those omissions were appropriate then, now more is needed. Teams starting agile need to know that more discipline is required of them, and that discipline is fruitless without a strong emphasis on skills. Teams need to recognize that success is not just fulfilling requirements. It is also increasing productivity and decreasing the consequences of mistakes.

It's a technique children and teenagers have mastered: asking "why" until they get to an acceptable response (or until we're too tired to continue answering). Find out how Michele Sliger uses a similar approach designed by Six Sigma to drill down into the underlying cause of any problem within software projects. She then continues the inquisition with a series of other questions in order to find out how these problems affect business value and technology. Read on to learn what these questions are and how you can start using them to find out why things aren't going as planned.

Database locking is a complicated technical issue for some testers. Although we often think that this issue belongs in the realm of the developer and the DBA-"It's not my problem"-database locking is the enemy of functional and performance testers. As Justin Callison can personally attest, locking defects have led to many disasters in production systems. However, there is hope! Justin sheds light on the problem of database locking, how it varies among different platforms, and the application issues that can arise. Armed with a new understanding of database locking, you can develop effective testing strategies. Join in and learn about these strategies: designing explicit locking tests, ensuring appropriate test data, implementing sufficient monitoring, and combining manual with automated testing to avoid disaster.