People & Teams
Articles
Issue Priority and Severity There are several topics that can trigger near religious fervor in software developers--languages, indentation, and comments come immediately to mind. One of Peter Clark's personal favorites is the relationship of issue priority to issue severity in defect tracking systems. Just what the heck do all those levels mean, anyway? In this week's column, Peter describes a solution that his company devised to clearly define the characteristics of severity and priority and help them better understand how the two work together. |
Peter Clark
December 30, 2005 |
|
Helping Your Team Weather the Storm Jim is mad at Hal. Sara is complaining to Jason. Hal feels hurt; Susan shows up late. Jason thinks only Sara and he have a clue. Is this team falling apart—or just experiencing a normal part of group development? In this column, Esther Derby describes what their team leader Jenny goes through as she learns about the predictable ups and downs of team formation and the one thing any team member can do to help. |
||
Cases Against Applying Schedule Pressure Do you think that by removing deadlines from a project a team will have enough time to create perfect software? Theoretically, it's possible, but in this column Mike Cohn explains that this theory might not hold against ingrained behavior. He recalls how several teams reacted when deadlines were lifted from the projects they were working on. Their only goal: to produce perfect software. But that goal inadvertently brought something to the surface, that old habits die hard. |
||
![]() |
How Much Work Can You Do—Developing and Managing Your Project Portfolio Knowing how much work your group can accomplish—and how much it takes to complete that work—is critical to your success as a manager. Johanna Rothman explains how to ascertain your team's potential and how to use that information to define and manage your project portfolio so it doesn't manage you. |
|
Take Time to Make Time Scheduling a project can become a comedy of errors if you don't remember to plug in all the necessary pieces. In this week's column, Peter Clark takes us to a project kick-off meeting and shows us how to spot several common mistakes people make when creating project schedules. |
Peter Clark
October 6, 2005 |
|
![]() |
Executor or Engineer Software testers are typically grouped en masse in the world of information technology (IT). Many in the software testing profession, however, know that this should not be the case. In this column, Dion Johnson exposes the dichotomy in testing that has produced two distinct groups—software test engineers and software test executors—and why these groups are embroiled in a struggle to possess the crown as the industry's true software quality professionals. |
|
![]() |
Unearthing Buried Feedback Most managers realize that giving feedback is an important part of their job. But not all managers are skilled at providing feedback. Some make vague comparisons, mistakenly apply labels as feedback, and others just hint and hope you'll get the message. Esther Derby offers advice on how to probe for the information that will help you understand your manager's concerns when he doesn't state them clearly. |
|
![]() |
Is the Grass Greener on the Other Side of the Fence? We may be creatures of habit—adhering to and promoting processes we know well—but we also habitually look to other work environments that appear capable of nurturing our ideas once an old environment becomes depleted. Ed Weller believes that searching for greener pastures is unnecessary. You just need to learn how to cultivate your managers in order to create an environment that will harbor your ideas. Ed explains why you'll end up grazing fruitlessly if you can't plant your ideas with management. |
|
Information Gathering If your customer interview questions focus too narrowly on a problem that must be solved, you run the risk of missing information that could be critical to a successful outcome. In this column, Naomi Karten says playing detective improves your ability to gather information. To improve the odds of success, it's important to ask questions from multiple perspectives—and to pay attention not only to the customers' response, but to how they say it as well. |
||
![]() |
Openness, Trust, and Healthy Paranoia Trust must be earned in any relationship; it is not automatic nor can it be assumed. You only learn how much you can trust someone over a period of time. The same principle rings true in project management. In this week's column, Peter Clark shares a valuable lesson for project managers and other management professionals, demonstrating that a healthy level of paranoia must precede openness. If openness is premature, one's trust could prove to be unfounded in the end. |
Peter Clark
July 15, 2005 |
Pages
Recommended Web Seminars
On Demand | Building Confidence in Your Automation |
On Demand | Leveraging Open Source Tools for DevSecOps |
On Demand | Five Reasons Why Agile Isn't Working |
On Demand | Building a Stellar Team |
On Demand | Agile Transformation Best Practices |