In this article, Lisa Crispin recalls a time when testers alone were solely responsible for software quality, and compares that to more modern thinking where collaboration between developers and testers is king. Software quality is everyone's job, sometimes it takes independence to get there.
This short book, written by Clarke Ching, is a "biztech" parable for software developers who want to survive—and then thrive—through the credit crunch. We have republished the book in a four-part series. In part one, we meet the main characters who have just found out that their jobs are on the line after discovering their major client's business is failing. Follow the story as our characters fight to keep their jobs by implementing creative business ideas and management skills taken from agile development.
Untruths about software testing are common. Managers, programmers, and other people on software projects don't always mean to deceive. Quite often, they fool themselves into believing what they want to believe. But sometimes they lie deliberately and even pressure testers to lie. And testers can also practice deceptions and self-deceptions of their own. In this column, Fiona Charles describes four categories of common deceptions and self-deceptions in testing and outlines what testers need to do to address them.
"Distributed" isn't a word that always has appeared favorably in works about agile methodology. After all, the proximity of agile team members while working is highly regarded. In this article, an excerpt of which originally appeared in the May 2009 Iterations eNewsletter, Chris McMahon takes a look at how "agile" and "distributed" can work together successfully.
If two projects in your organization require specific expertise that only one employee has, what do you do? Projects need to stay on track, but one person certainly can't be everywhere—or even two places—at once. In this column, Johanna Rothman shares a story of an organization stuck in the specialist mindset and offers some tips on how to escape if you're stuck there, too.
Some people freely admit that they're not good listeners. But many who claim to be good listeners aren't. That's because they fall short in a critical aspect of listening. In this week's column, Naomi Karten offers ideas and examples that will help you be-and be perceived as-a good listener.
Esther Derby has been thinking about trust in the workplace a lot lately, and the absence of trust, too. When she asks people what it's like to work in a group where people trust their managers, they tell her information flows freely, conflict is productive, and that they can tell their managers what they think without fear of retribution. On the other hand, when trust is absent, people hide information, look out for themselves, don't bring up new ideas, and withhold effort.
Instead of focusing on the problems, focus on what works. That is the simple premise of "appreciative inquiry." In this week's column, Ellen Gottesdiener explains how to help your team focus on the processes that work by outlining what should be included in your appreciative inquiries, in order to make more positive organizational changes.
Back in the day of cross-Atlantic boat travel, luggage that wasn't needed during the long journey was labeled "Not Wanted on the Voyage" and stowed away below decks. In this column, Fiona Charles suggests that testers can also be viewed as heavy baggage and not exactly welcome by some parties during the journey of software development. To understand why others might think this way, Fiona takes a good, hard look at what testers do that could possibly make them undesirable team mates.
You've probably seen it on Agile teams: conflict seething just below the surface. Barely disguised disregard, sidelong glances, rolling eyes, words that halt conversation for an eternal heartbeat while people think, "Was that meant to be a put down? Did she really just say that?"