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.