Have you ever had to contend with a demanding developer? A testy tester? A cantankerous customer? Why oh why do people act that way? Rather than wondering why they act that way, it can be helpful to consider the circumstances that might account for their behavior.
When Mary Gorman and Ellen Gottesdiener facilitated a game called The Backlog Is in the Eye of the Beholder for the Boston chapter of the International Institute of Business Analysis, both the players and the facilitators learned some important lessons in organizing a project requirements backlog. In this article, they describe the game and what it revealed, including the value of truly knowing your stakeholders.
My team is in the middle of one of the hardest projects—we call them "themes"—we’ve ever tackled. We’re a high-functioning agile team that has helped our company grow and succeed over several years now—we “went agile” in 2003. Here’s one thing I know for sure: No matter how many problems you solve, new challenges will pop up.
It's a special skill to be able to terminate disputes amicably. In this week's column, Naomi Karten offers suggestions for how to resolve disputes so that none of the parties suffers from black eyes or bruised egos.
Tired of guesstimating your estimation process just to create a completion date management will accept? Jonathan Kohl takes the guess work out of estimations by focusing on uncertainties. It may sound counterintuitive, but the idea is to focus on the fact that all projects face unforeseen delays. The rigorous estimation process Jonathan describes here provides your team a way that ensures enough time is scheduled for development and a date for completion management can agree upon.
Giving your customers the opportunity to provide feedback is great, but only if you don't fall into one of the four traps that Naomi Karten describes in this article. Let your customers know that not only do you want their feedback, but that you'll actually use the important info they give you.
When your customers aren't complaining about the services you provide, it's easy to assume you have happy customers. But that could be a serious mistake. In this week's column, Naomi Karten describes what happened in two organizations that misinterpreted the absence of customer complaints.
In this article, Jennitta Andrea explains how a community of practice retrospective differs from a project retrospective. She also explores the motivation for a community to perform this type of retrospective.
On the surface, a Broadway musical, a newspaper, and software may not seem to have much—if anything—in common, but they have one common thread. All are delivered on a fixed schedule. But of the three, software tends to stray the most from the fixed schedule. In this week's column, Jeff Patton says that by focusing on the readiness of the entire product—as done in theatrical performances and when publishing a newspaper—and not just on the completion of the planned bits of work, you can produce software on a fixed schedule that you know is ready to ship.
You don't need to look any further than to your coworkers to see how many different personalities and work styles are in effect. Despite the differences, certain predictable behaviors occur between staff and management when personalities clash. Jonathan Kohl defines a few managerial behavioral anti-patterns that could undermine your project. He also sets the ground work for ways to improve the relationship between staff and management.