Why do we insist on calling people “resources?” If software projects were a factory, people would be fungible-interchangeable equipment just like desks and computers. Because software development is highly creative work and not a manufacturing factory, we need to manage people as human beings, not as tasks or resources. Johanna Rothman describes how to find and develop the right people for your teams and projects-people who fit your culture, share your values, and will become integral parts of your team. She explores what skills make a team great and how great managers model those skills and reward people who use them to help the project. Find out how to empower your team, including protecting it from bad influences, making sure the team has what it needs, and helping team members learn to be accountable to each other. It's the people working in teams-and not their managers-who make software projects successful.

It is nearly impossible to work in software development and not end up on a project which one day ends as a death march. These projects are characterized by being extremely overdue, significantly over budget, and, at the same time, critical to company success. Death marches can happen regardless of development methodology because the contributing factors often include dramatic scope change, lack of vision, and unrealistic deadlines-factors that are methodology neutral. Bob Hartman shares his experiences with death march projects and the approaches he has used to redirect them into successful efforts. He focuses on how stakeholders can identify and address underlying problems early in the project. Learn how to lead rather than manage, encourage creativity rather than stifle it, and become successful rather than beaten.

When people work closely together, there's bound to be friction and irritation. Some people find it difficult to discuss these issues directly. So they hint and hope or simply procrastinate and don't do anything. Then, the irritation can grow out of proportion. Team members' ability to give peer-to-peer feedback-both about the work and the working relationship-is critical to developing a highly productive team. Esther Derby discusses the four parts of feedback conversations-opening, description, impact, and request-so you can say your piece without breaking the peace within your team. There's an exception to every rule, so Esther also explains when not to use all four parts and reveals the words that you should never use when offering feedback, the words that will always derail the conversation.

In tough times, both shoes often drop simultaneously. Then, unsustainable "scarcity thinking" takes over. Many times, the tendency is to say "yes" to impossible dates, take on too much, quietly suffer the budget cuts, and pray that heroics will save the day. Resulting dysfunction can wreak havoc on your projects in the form of scope greed, death-march deadlines, and budget cuts. It takes a skillful manager to "right size" critical projects-right team, right scope, right dates-from the beginning. Michael Mah describes how to lead difficult conversations and discuss the undiscussable when needed resources are threatened. He shares how to artfully frame trade-offs for stakeholders to help them set priorities. Learn how to get buy-in for realistic scope, schedules, and team size using a blend of common sense, essential measurement concepts, and rules of software estimation.