What I mean by this is: A job is delegated to you and it is made clear that you are responsible for the success of that job. This can be the implementation of a feature, managing a new client, bringing a certain amount of business this year, correctness of your project estimation, whatever. The responsibility is made yours, but you can't make the decisions required to get the job done most effectively and most efficiently. You have to stick to what someone else thinks is best.

In this conflict, the course is already set. You're standing on the command bridge of a proverbial ship where all controls have been removed. Yet you are responsible for the save arrival of all passengers. Sounds familiar?
It is important to me to make clear that this is not an issue only affecting non-management employees. It affects everyone in a hierarchy.

I recall one particular incident which I'd like to share. I was the assigned consultant for a new client. The responsibility was to identify all tasks required for that project and come up with an estimation. I did and do that regularily. The catch? We already knew the maximum budget the client had, and also the required release date. In fact the offer had already been sent and signed based on both. Even worse, a quick glance through the requirements made it clear that it was unrealistic to expect everything in good quality, for that budget, at that date.

At that time we did estimations mostly for the purpose of creating a realistic offer, only rarely were these estimations used internally for quality control and such interests. In that regards, an estimation was not required anymore. Think about this. If the goal of the job (a realistic offer) is already obsolete (offer had been sent and signed), the job itself might be obsolete as well. Nonetheless I finished that estimation as I saw a chance to track the actual efforts and compare it to my estimation after the project was over.

The estimation caused a huge uproar in the management, who claimed it was too high. I had a long discussion to convince them that the efforts are realistic - in the end it took a second estimation done by a colleague who came to a similar figure. Nonetheless the client had been convinced that time and budget were fine and no one wanted to change that. So there I was, responsible for a project that I already was convinced would not meet time, budget or quality (pick one), yet unable to do something about it.

I believe everyone of us can recall a similar scenario?

Of course I am not free from comitting the same crime. I have a vision for a new feature and stake out the route I believe is best and 'convince' my team to stick to that. But during development they might learn that another approach might be better. Yet, I staked the route, so they will tend to try to follow it. My fault, not theirs.
Yet I frequently see that if decisions are left to the team, after a learning period they usually come up with pretty clever ideas. They prove that I can trust them. Sure, guidance and mentoring is required every now and then but that is good - I hope not to become obsolete any time soon.

This is a call to all managers and leaders out there to trust your people. Give them the responsibility, delegate to them, but don't forget to give them the power and freedom do act as they see fit at the same time.

By no means do I want to advocate anarchy. Rules and guidelines are there in all but the smallest of organizations. They are there for a reason. So yes, we have to stick to that rule. Unless they make no sense and you can prove it. What is wrong with that? I don't see the point of sticking to a regulation 'because it is there', knowing that another approach might be better, faster, cheaper.

Managers! Trust your team! Let them make their own decisions! Ask for their opinion and listen to it! Mentor them instead of keeping them on a short leash.

Team! Learn to say no! Do what is right, not what is easy! Be opinionated and share your thoughts and doubts! Make suggestions, especially when no one wants to hear them!

How about you? Did you experience similar conflicts? Let everyone know how they were resolved. I'd really like to know so leave your comments!

Go and read the thread for quite a few interesting points. In a nutshell though, the question was how Scrum can help in fixed price contracts. I think that's an interesting question since at first sight a fixed price environment - and hence a fixed time environment - is contradictory to the agility that Scrum offers in terms of rescheduling tasks that have not begun yet, replacing items with others etc.

The consensus in the Yahoo group seems to be that fixed price contracts generally are a bad idea, will fail and that Scrum will not help you with that other than in damage control.

Well, in part I agree to that. Fixed price environments are tricky. Maybe they come into place because the client does not trust the agency, maybe it is a new relationship. Maybe they come to be because the sales staff of the agency gives the wrong impression in the first talks and no one dares to tell the inconvenient truth to the client after that, before the contract is written.

Maybe it is just how it always has been and we've all grown used to the process and the suffering involved?

I agree that some clients are politically important, door openers, key players. Whatever you call them, you will want a contract with them. Not for the sake of that contract but because of the things you believe you can get after that first contract runs well. And yes, in that situation it might not be very important to make profit on the initial contract.

But let's muse a bit on that thought. What good is a disappointed door opener client?

What I often see happening in fixed price contracts is that the agency over promises (too many features for too little money/time). With that being the base line the developer team is forced to deliver more functionality per day than they can deliver in good quality. Due to time restrictions, development becomes sloppy. Bugs creep in, further delaying the progress. In the end the developers are exhausted, the project manager has a hard time convincing the client that 'everything is still going really well' and the client senses that something is off. In the end he is presented a system that is riddled with bugs and sub-standard usability, and with reduced or missing features.

What happens next is usually a free-of-charge bug fixing period. In the meanwhile new requirements come in, which again tend to be priced below what the actual effort is. To make the client happy, after the initial disappointment. This vicious cycle repeats.

So in the end, don't we have a project in debt and an unhappy client? Did the agency really impress that client? Will he play the door opener role that management had hoped for?

So what might be the solution to that? What role might Scrum play?

Well I think the solution is trust. If the client is convinced that you're not stealing from him he probable is willing to agree to a more flexible approach.

So deliver early, deliver often. The sooner the client sees what you are doing, the earlier he will trust you.

Make sure that the client understands the MoSCoW method and that his feature list has a lot of 'should' and 'could' items. Deliver the most important features - those with the highest business value for him - first.

That way, even if progress gets delayed, the most important features will be done, and in perfect quality.

Ensure that the client spends a significant amount of time checking the interim states on the staging environment. You will need his feedback early. As Pete Deemer explains it, bugs are like tigers: At first they're little cute babies but if left unattended they become man eaters hiding in a thick jungle, waiting for the kill. So better to take care of them early on, and don't let them enter the thick undergrowth of your project where they will hide and grow.

I believe to some extend this picture applies for features in general: Only the client knows what he really wants. So the sooner you show him a working part of what you think he wants, the faster he can correct you, while the gap is still small and easy to bridge.

Bottom line

Being honest with the client is not the easiest approach. He might be irritated when two people from the same company (Sales, Project Manager/ScrumMaster/...) tell him two different things.

Management in your own company may not approve this seemingly radical paradigm change. Make sure you introduce it gradually.

Not all clients may be willing to work in an agile way.

So there is no silver bullet. There is no single solution that works every single time.

But I'm convinced that with open communication (think: full disclosure) and early delivery, Scrum can do a lot in damage control. Fixed price contract or not.