Friday, March 31, 2006
Hold your horses there... Giving in to all your customers whims all the time is not really good business. But the customer is always right! Right? Technically, yes... But nothing is stopping you from telling your customer: "Look... We can do this given enough time. Now yesterday's gone, and we only have today. And tomorrow will be gone, because it will become today tomorrow. Now what do you want done first?"
Being firm is not bad business -- but being inconsistent and unreliable is. When your customers know that you're working on it and that they see constant and verifiable progress then you now have chips that you can play with. If you've given your word before and you pushed through, then you have a reputation of delivering -- and that's what you want. The problem is when you have given your word before, and failed to deliver: then that's another point of discussion.
Allowing your customer to evaluate what is of most value to him alleviates the risk from the technical team of telling the customer what is important (and being wrong). The User Stories that have already been written should have the priority as an attribute -- meaning, the most important things are done in the beginning of the project. However, the priority doesn't have to be written down on the index cards -- though it would be nice to put them down somewhere else.
This post is about prioritizing stories which is not the job of the technical team. The customer should tell the technical people what they need, when they need it, and which needs should be addressed first. When the technical team already has all this information, then they can start working on providing the solutions and working with the customer to fulfill the needs.
If your customer still wants things done yesterday, then tell them the reality of things -- or charge them a little more so that you can put in more resources, but nonetheless involve them in the solution process. Building software should not be like a fast food drive through service -- where people just line up, tell the programmers what they want, and wait at the end for the delivery. It's more like a "I'll build your house" shop, where you tell the architect and engineers what you want, and be there every step of the building process -- that way, when your house sucks, then it's not the builders fault because you made the decisions on how it should look.
Allowing technical people to be creative on solving the problem doesn't mean you let them determine the priority of the deliverables. It means you allow them to solve the right problem at any given time. It's like leading a pack of wolves and directing them to the right flock of sheep.
How do you lead a pack of wolves? That's another discussion.
Continuing on to the prioritizing of stories, it also allows the technical team to solve the harder problems first. You ride the productivity wave by allowing the most productive people to do the most demanding tasks first, and not worry too much about the plateau in productivity later in the project.
The last thing you want in a project is delivering the non-important features of the software while leaving out the more important ones. I as a customer would rather have the important parts there than have the extras first without the core functionality. I wouldn't mind too much if I see that the extras will come later, but the really core functionalities are already there.
Prioritizing stories allows project managers to determine a lot of things at the start of the project, as well as while the project is on-going. It allows customers to communicate exactly what they want in the order that they will be satisfied in. It also allows the technical team to be productive and creative in the most efficient manner.
First things first. One after another. You don't get to the next one if you don't start with the first one.