Queues understanding to improve productivity

I work with Agile cross-functional team who don’t meet Scrum prerequisites but still want to move toward Agile. I don’t have the authority or can sell the tenet to management to change their team set-up.

People in the team came from different departments and there is lack of understanding of queues and hand-offs. We are not waterfall, rather we are Lean concurrent parallel work in analysis, design, coding, testing and system test.

Understanding the queue between two people for me is critical. We should understand what goes to the queue, how often an item is added, how often an item is removed, what is the typical number of items in the queue. We should try to set limit on the items in the queue. For example, the testing people in the team should not have more than 5 items in their queue ready to be tested at time. This limits the batch size which according to the law of physics will improve quality and increase speed (Little Law).

Drawing the team process map is simple but vital for leveling the team understanding about what happens, and to allow us visualize the queues and therefore drive process changes.

This can be done during project retrospectives. After mapping the as-is process, we should agree on the what the problems are. This could be defects escape, low Throughput, and high rework.

Look, we make money to stay in business, and to stay in business we should make money! We need to deliver customer valued software fast with quality and cheaply. Our success lies in locating the queues, control them and ensure flow from one step to the next.

When you ask the 5 whys for each  problem and start to collaboratively see which areas in the process has originated the identified causes, avoid attribution. You probably find complain from the people involved in the process steps that they get the work in bursts and very late (our testing friends).

Thinking about improvement in terms of reducing issues with existing queues is objective approach. You can have for example process step called rework which has spikes in its queue size which causes excessive delays. Think about reducing such avalanches in the queues, then, quality and productivity will follow. After all we create our own rework because of failing to understand the queues.

One thought on “Queues understanding to improve productivity

  1. Sameh, computing the average and maximum queue size could be easily computed using the global arrival rate (for incoming issues), it will always always have a poision distrubution with that global arrival rate (lamda).
    The challange will alwasy be to identify the distribution of service or the execution of those issues, it could be exponitional, normal, lognormal, any kind of distrubution.
    So, a good approach we be to log around 30 to 40 days of execution time and then using run a simple monte-carlo simulation using a “bootstrapper” techique that keep re-sampling the execution history sample (those sample of 30 or 40 days) you will get all the queuing performance for your pipeline and that will include:
    1- avarage queue size
    2-avaerage time for a single issue to stay in the queue
    3- avaerage time for a single issue to stay in the overall system
    4- average count of issues in the overall system (queue and in-progress)
    5- the team utilization factor

    Also, what you get maximums and minimums.

    Thanks for simulation !

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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