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?"
Do you ever get the feeling that some conflict just can't be solved? The team members in conflict address the issue, it seems to go away but then it comes back. Maybe all dressed up in a new situation or with a different level of intensity, but the conflict is somehow familiar and you know that it has undoubtedly returned. If the team uses humor as a stress-reliever, you may even hear the conflict turned into a sarcastic half-joke, "OK team, just to put you on notice. Julie hates me again." Sounds almost like a marriage, doesn't it?
Teamwork, no matter the intentions at the start of any agile project, can be derailed by even the smallest factors. Learn how to identify the five dysfunctions of a team so that your team can address them and avoid letting them grind your production to a halt.
If you're working on more than one project at a time or if your managers are asking you to do so, it's time to make some decisions. Not every project should be started or finished, and certainly no one person or team should work on all projects at the same time. The organization needs to make some decisions about whether to commit to a project, kill it so it doesn't interfere with other projects, or transform it so it can succeed in a reasonable time.
The step between specifying requirements to working on a system design can be tricky. Fortunately, the basis on which the step is made can be calculated. Paul Reed thoroughly explains how the transition should progress and offers some instructions on how to move properly through this phase.
In most projects, testers are the keepers of quality. Sharing the vision of quality with the entire team helps everyone involved in a project play a more active role in determining the state of quality in a product. In this column, Jeff Patton shares several innovative ideas he's seen in practice lately that have helped an entire team own up to the quality of its software.
Twenty years ago, Clarke Ching fell in love with programming. Then he got a job doing just that and fell out of love within five years. Fifteen years later, Clarke sought the help of a well-known programmer for advice on how to rekindle his dormant passion for programming. The advice Clarke received led to a greater discovery.