The Latest

Why do some teams "catch fire" and excel, while others never seem to gel? Ms. Dekkers and Mr. Lister talk about this, as well as other topics from Mr. Lister's book, PeopleWare.

Are you inadvertently setting up a one-dimensional team? Managers regularly make statements to recruiters like, "I need another test engineer just like Charlie." Sometimes hiring people with very similar qualifications makes sense, but sometimes breaking the mold makes a better team.

Is the tester doing a good job or a bad job when she proves that the program is full of bugs? It’s a bad job from some developers’ points of view. Ridiculous as it seems, there are project managers blaming testers for the late shipment of a product and developers complaining (often jokingly) that “the testers are too tough on the program.” Obviously, there is more to successful testing than bug counts. Here are some tips about how testers can build successful relationships with developers.

The slick brochure promises every feature you can imagine, and the sales rep assures you that his package will do just what your users want. But that's what the other vendor's sales rep said, too. Sound familiar? Karl Wiegers recommends several requirements development practices that can help you select the right commercial package solution. Key practices include identifying user classes, defining their use cases, creating test cases from the high-priority use cases, documenting pertinent business rules, and exploring the users' performance goals and other quality attributes.

"No Fred, we're not considering you for that promotion. You're too valuable where you are." How many of us have heard those words, or said them at least once to our staff? Sometimes, we use the "too valuable" phrase to avoid discussing problems with a staff member, problems you can bring out in the open and manage.

The challenge was to introduce agility (Scrum) across the AOL Publishing organization. If we subtract the editorial staff, the agile transformation affected roughly 3,000 employees one way or the other. The agile consultant and coach tried to tackle several issues under one “reward and recognition program” umbrella. For example, “How do we know that the 50-70 project teams, who were working in parallel at any given moment, were really doing agile?”

Many of us would like a precise answer to the question: "What's the correct staffing ratio for developers to testers in my product organization?" Usually, though, the only answer is "It depends." Your answer depends on your situation: the kind of project you're working on,
your schedule constraints, the culture you work in, and the quality expectations for the product. This paper discusses the thought process involved in deciding on your correct staffing ratios.