teams
Articles
|
How Agile Practices Address Five Team Dysfunctions 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. |
||
|
Decisions, Decisions, Decisions 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. |
||
|
A Word with the Wise: Configuration Management Tips from Steve Berczuk In this short interview with editor Joey McAllister, Steve Berczuk offers some tips to organizations dealing with configuration management (CM) issues. |
||
|
Transitioning from Analysis to Design 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. |
||
 |
Simple Strategies to Keep Quality Visible 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. |
|
|
Relearning to Program 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. |
||
|
Five Tips for Retrospective Leaders and Meeting Moderators 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. |
||
|
Does Name Matter? 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. |
||
|
Multitasking Is Evil Multitasking is often seen as a desirable skill—you can buy books or pay to attend courses that will teach you how to do it—but it is a surprisingly debilitating idea. |
||
|
Keep Both Oars in the Water - Tips for Modeling Requirements If you hear that someone doesn't have "both oars in the water," you know he's out of control, he doesn't "get it," or he's going in circles. Why? To move forward in a rowboat, you need both oars in the water to steer and to gain speed. In this week's column, Mary Gorman explains how this concept applies to modeling requirements. |
Pages
Recommended Web Seminars
Featured Resources
Visit Our Other Communities
AgileConnection is a TechWell community.
Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.