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.
Before you schedule or moderate another retrospective meeting, read this column by Esther Derby. Esther offers five tips that will help improve the productiveness of retrospective meetings. You'll also learn how letting the meeting participants run the conversation will solicit more feedback and ownership than traditional moderation methods.
The names we give to things can have a powerful influence on how we think about them and also on how we get others to think about them. In thiscolumn, tester, test manager, and consultant Fiona Charles examines names we have given to two essential roles in software development and explains why at least one of them is both inaccurate and a problem for testers.