This short book, written by Clarke Ching, is a "biztech" parable for software developers who want to survive—and then thrive—through a credit crunch. We have republished the book in a four-part series. In part two, Bob, Bill, and Sam discover how a rocky economy can flip project costs and return on investments and how much money could be lost by canning the FBU project. Can they use these projections to save the project and their jobs?
When people begin to get overworked, it's common to fall back on blaming the old chestnut "time management." But the problem may have less to do with how you allocate time to projects than your inability to say no to some of those projects in the first place. In this article, Johanna Rothman takes a look at the difficulty of saying no and offers some suggestions for overcoming it.
Implementing change can be a colossal challenge. People tend to prefer what's familiar, safe, and predictable to that which is new, unfamiliar, uncertain, confusing, or potentially risky. But the timing of a change effort can influence how readily people accept the change and adjust to it.
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.