We recently got some questions about the story "We'll Try". Send us your questions!

The article assumes that the deadline is fixed and that the client should trade off the project objectives. It seems to ignore the possibility that there are other things the client might want to trade off such as cost and deadline or more complex issues like aspects of quality such as maintainability, flexibility, reliability, usability, etc.

Yes, that's right. The story is there to make just one point: if you know what is going on, you can make the project better. It's intended to remind you of the horrible feeling of an impossible deadline, and to offer the hope that if you know how long things will take, you can improve the situation. To do that, it deals with the "normal case" where management says "take these 6 guys, write the program, get it here by Wednesday, and it had better be perfect".

The reality of most projects is that resources are fixed, and if management won't trade scope against time, there will be a hidden impact on quality. That's why quality is so public in XP, because it's the thing most damaged when the information about scope vs time isn't available.

There are other tradeoffs that sometimes work. You can (rarely) add people to a project and make it go faster. To save time by reducing quality, you have to reduce the work that needs to be done. Since an XP project derives all work from stories (and the functional tests that back them up), even if you did want to save time by reducing quality, you'd have to approach it from scope.

I think even things like the satisfaction of project stakeholders and the satisfactions of the project team are legitimate things to trade off. For example on a Y2K project the client might really care about deadline and project objectives but care less about cost and stakeholder satisfaction (e.g. it's Ok to [ tick ] off HR).

Whoever is controlling the scope (the manager in "We'll Try) is in charge of the satisfaction to the real stakeholders. That's why we want the real customers as part of the project. If the real customers are remote, whoever acts for them owns the problem of keeping them happy.

Even then, how can he speed up the project by reducing stakeholder satisfaction? Basically, by not doing something that the stakeholders think they want. That is, by reducing scope. Realistically, there's just no other handle

As for team satisfaction, in a very real sense, I think trading that off would be wrong. We're talking about real satisfaction, the satisfaction of having done a good job. Any manager who feels the need to make his team less satisfied on that dimension is simply not in touch with his project or his humanity.

People are satisfied when the work they do meets the need they perceive, and when they are treated generally decently. There's no need to reduce satisfaction to get anything done: instead you need to be sure that the people understand what is really needed. The XP value called Communication.

As for actual human satisfactions, we plead guilty. We think that it is not to the long- or even medium-term benefit of anyone to make the team unhappy. They slow down, do poor work, and quit. And it hurts. Hurting people for the benefit of companies went out of style a long time ago ... except that people still do it. We don't think it helps.

I know this isn't the subject of the article but it seems to me it gets at the heart of something about XP. XP seems to say "here is how you should organize your project if you want a good result" and thus builds in assumptions about what is a good result.

I guess in the end, any methodology has to plead guilty to this. You have to identify the dimensions of good result and give controls to manage them. We define XP as a humanistic discipline of software development. Thus we focus on the human values, and identify resources, quality, scope, and time as the variables management should control. It seems to me that that's the best one can do: pick values and go for it.

Some other methodologist can write the book about not satisfying the stakeholders and the team members. We think that methodology wouldn't work to satisfy anyone.

Thanks for asking!