We should use project postmortems to improve our software process. But few teams do, and fewer teams reliably learn from project postmortems. You can introduce postmortems to your team easily with a timeline postmortem process. If you are already doing postmortems, a timeline-based approach may improve your results.
This process:

• Takes little time (a few hours).
• Has a high degree of software engineer acceptance.
• Provides immediate feedback into your development process.
• Increases team cohesion and rapport.
• Reduces finger pointing.

Test data has long been a challenge for testing; privacy legislation, identify theft, and the continued trend towards outsourcing has made it even worse. Just establishing and maintaining a comprehensive test environment can take half or more of all testing time and effort. In this column, Linda Hayes adds in the new and expanding privacy laws that inevitably limit your testing options. Yet from the quagmire of laws and company standards, better testing can emerge.

The problem with urging outside-the-box thinking is that many of us do a less-than-stellar job of thinking inside the box. We often fail to realize the options and opportunities that are blatantly visible inside the box that could dramatically improve our chances of success. In this column, Naomi Karten points out how we fall victim to familiar traps, such as doing things the same old (ineffective) way or discounting colleague and teammate ideas. Thinking outside of the box can generate innovative and ingenious ideas and outcomes, but the results will flop when teammates ignore the ideas inside the box.

Forming, Storming, Norming, and Performing. No, they are not a law firm, but the stages of team development proposed by Bruce Tuckman in 1965. I wish I had known about this model much earlier in my career. If you haven't encountered it before and want to help your requirements team, read on.