Pull based Organization : A new way to organize tasks

In the previous blog post on post-Agile and the one previous to that on how to prioritize tasks, we discussed the issues with current method of prioritizing the tasks and how doing with all process [including prioritizing of tasks] are being discussed.

Before we go further, lets analyze why we need to prioritize tasks? The most obvious reason seems to be to get a handle to organize them : what to manage, how to manage, when to manage etc. In addition, prioritizing tasks also is the bigger part of our strategy of overall management. Hence, we basically prioritize to organize tasks and our other management. From this angle, if we look at the problem of prioritizing tasks as one of organizing tasks, we might be able to come up with a different approach.

An example of pull based organization [planning] is someone calling fire station and fire system being despatched to the location. After the drill, the fireman gather and adapt – what they improve is their response time as well as their overall efficiency [by not considering all catastrophes or situations and using calculated guesses]. Similarly, in a shop floor, spare parts are made only when someone needs it downstream. The emphasis is on being able to assemble these parts quickly and also keeping the inventory low. Focussing on this helps you minimize the steps in production and get your act together. This is Lean at its Best.

Similarly, in software, pull based organization would occur from customers demanding features [or pulling features] and product teams implementing them. As there would be too many requests [and implementing all would take time and no delay being non-negotiable item], the team picks the requests that are asked by most customers and implements them and then moves to the next most requested item and then the next one and so on. All this, while the item list keeps getting added to. The teams pick up as many items as they feel comfortable. This is almost akin to a parallel micro-Scrums [with sprint lasting as long as one item and multiple teams implementing the items]. Such an organization needs close coordination between design, programming, testing and analysis teams and often with all steps being performed at the same time and recursively till a solution emerges.

A problem in approach like above is how do you know if you are moving fast enough or if you can do better. The problem can be overcome is speed of delivery of features becomes important. Once it does, the team itself comes up with solutions or ways to implement which will lead to faster delivery. The emphasis has to be on “how fast do we get a request once it comes to us implemented.” If this is fast enough, you would not need much prioritization. The only problem here is to come up with effective team size so that you are always implementing high enough priority features. If you get these variables [team size and getting features fast enough], the prioritization would take time.

Advertisement