software development

Pull promotes quality

In this post I contend that pull systems enable and promote working at a higher level of quality than is allowed by working according to a push system.

In traditional software development scenarios, project plans and timelines are imposed on development work. In addition, work is pre-assigned to specific developers. It is fact that any type of worker can only do so much work per hour, and there are so many hours in a day. When timelines (and a set number of human resources) are imposed on a creative, innovative process like software development, either the quality of the work decreases, or the amount of work decreases (if quality is kept constant).

If you give Michaelangelo 10 days to paint the Sistine Chapel, he will either paint only a corner of the ceiling to the desired quality (which is why you hired him in the first place), or he will paint the entire ceiling but it will look like rubbish.

This is a push system. The deadline is pushed onto the work. Work items are pushed onto specific developers.

However, if you don’t impose a deadline, and you don’t pre-allocate tasks to developers, the developer has the time available to him to ‘do a proper job’, i.e. complete the task to the level of quality required by the system. He is not under pressure to cut corners in either scope or quality. He is also not inclined to optimise to the incentive.

The challenge of these systems then becomes managing the uncertainties around such a project, like ‘when will it be complete’, ‘how much will it cost etc’. But in general, the quality of the finished product should be higher.


6 thoughts on “Pull promotes quality

  1. I think this is true, but the best balance is to get the developers to be good at estimating their productivity rather than imposing it from the outside. There are many very successful examples of this, such as Team Software Process (TSP) or various flavours of Agile development. If implemented well, these give very good certainty on both delivery times and quality.

  2. I don’t have any experience with TSP. In Scrum and XP, there is the notion of velocity, and Scrum also provides the burndown chart.

    What’s most important though is that there is feedback and continual improvement in the estimations. Its also important to go into an estimation with eyes open, i.e. lets be aware how close we are to our estimation, as early and as often as we can. This is one function of the burndown chart.

    Another tool used in some pull systems, similar to a burndown chart, is a cumulative flow diagram, which looks very powerful (I have no direct experience with it yet).

    The point of my post though, is that by imposing timelines on your work, even if that timeline comes from the most educated estimation, mitigates your ability to work at the required level of quality. Estimations are estimations, and when dealing with new technology, complex requirements etc, estimations become less precise and appropriate.

  3. After thinking about this some more, I think that letting developers (the people with the most knowledge, therefore best for the job) make estimates based on previous experience may indeed be a ‘pull’ system. Whereas a ‘push’ would be more the situation of someone external to the team, with less information (and possible no feedback) imposing timelines.

    What do you think?

  4. I’m thinking now that the characteristics described in the post (i.e. allowing a task to be worked on until done instead of imposing a deadline) can’t be described in and of itself as ‘pull’ but rather a result of a pull system.

  5. Another note on this: The perspective with which you view this argument is affected by the question of success. For a software project, which is more important, for the feature to be released on time, whatever the cost, or for the feature to be released as complete, at an appropriate level of quality? I think what is often misunderstood is that these are competing constraints. It is not always possible to provide the appropriate level of quality and scope in a fixed time. Its up to the organisation to decide which provides more value.

  6. When I wrote this post, my thinking was as follows: in a typical pull system, including work-in-progress limits, I will be allowed to work on a task until I am satisfied that it is at the appropriate level of quality (as defined by the task requirements). I am not allowed to pull another task ‘on to my plate’ until I this task is done, and where ‘done’ really means done. This is much harder to achieve when I am pressured by a deadline – even if there is slack built into the deadline.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s