Scrum - the Pull System

In my previous post Introduction to Scrum I said that the team estimates the effort that is needed to complete the stories and he choose amount of work to be done in the next sprint. Please notice that it is uncommon in many projects.

In standard project the client says on which date he wants the project to be completed, shows the needed functionality and manager tries to slice the requirements and assign them to the exact developers - you will be doing this, then this and then that. He will probably ask about how much it take but if he won't be satisfied with the answer, he will ask you to work harder, be smarter, stay in office longer... whatever to get the project map not looking as something impossible. To see what is wrong with that approach, ask several questions:

• Do you think in this approach the quality of produced code will be on the constant, high level?
• Do you think the developer will feel satisfaction of his work, will be really motivated to do it right and will do the work in optimal way?
• Do you think that developers will be smarter, especially working long hours?
• Do you think the client will be satisfied that you silently drop the quality or when this is an internal project that you are mining the well being of the company in the long run?

I guess you have answered NO to many of those questions, so why so many projects still not using pull system? Hard question. I'm not going to answer it now. I'll just show the benefits of the pull system in Scrum.

• If someone says that he will do something he is more motivated to do it than when someone else will say that he must do it.
• Client or Product Owner must explain why he needs the story, so he must know what he wants. If developers will say that they still do not understand what he wants, they can choose another story. This way only well prepared stories will be done in the next sprint ensuring less slowdowns and questions in sprint.
• The quality will be constant because the only way for client to get more done is to drop functionality, rearrange stories or pay for another team.
• The team will work in sustainable peace, so no burn-out.
• Everyone in the team is responsible for selected work, because they all agreed on it, so better team work, more knowledge sharing etc.
• You know at the beginning of the sprint that something cannot be done, not in the middle or at the end.

Now we can co back to hard question. Why so many projects still do not use the pull system?

• They think that dropping quality has no cost.
• They think that development is a defined process (assembly line). In reality it is empirical process (uses creativity).

Imagine you want to order a painting, a complicated and big one. You also have limited amount of money and time. You go to a good painter and tell him the impossible deadline. Do you want him to silently agree and after some time give you a picture but in reality a crap (because doing it right is not possible in mentioned timeframe) or want him to say to you at the beginning that it is impossible and ask for change of requirements or deadline?

Do it for your projects too...