You have an approved project that is about to begin - the project team is in place, the product owner has been identified - the stakeholders are eagerly waiting to see results of this agile approach that they have all heard good things about ...

Here's your dilemma ... the stakeholders are expecting to see tangible progress at the end of the first iteration in two or three weeks - having been through presentations of Agile processes. But you know that it's really not feasible to deliver anything remotely useful in that short a period. Agile processes warrant early delivery of business value, stressing on working code. Release planning and iteration planning are all based around user stories completed to the extent of being ready to deploy. But the reality is often different.

A software project is a complex thing. It involves many players, many tasks, and lots of things that could go wrong (and often do). If not for dogged optimism, some projects might not be tackled at all. But optimism doesn't mean turning a blind eye to potential pitfalls. In this column, Esther Derby applies a lesson about asking, "What if..."

Why do some teams "catch fire" and excel, while others never seem to gel? Ms. Dekkers and Mr. Lister talk about this, as well as other topics from Mr. Lister's book, PeopleWare.

Are you inadvertently setting up a one-dimensional team? Managers regularly make statements to recruiters like, "I need another test engineer just like Charlie." Sometimes hiring people with very similar qualifications makes sense, but sometimes breaking the mold makes a better team.