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.
Every team transitions to agile in different ways, and this column is one of those stories. But what makes this one different is that the main character, a project manager, is transitioning her team to agile in the middle of a project. From this story, Johanna Rothman details a potential survival guide for any project manager and team embarking on the same journey.
Everyone responds to change differently, whether managers know this or not. A good leader knows this, and doesn't hurt the morale of a team by expecting them to act a way that their incapable of, or that feels unnatural to them. Naomi Karten brings this all to light in this article.