Visualising waste

Visualising waste

Big Thoughts

2 December 2014 • Written by Prajakta Panse

The changing face of software delivery has forced all IT projects to think about ways to increase productivity, work efficiently and get things done right, first time. 

Every project team is striving to get the project delivered at a fast pace, with minimum risk and fewer defects. We want to work leaner and cleaner to achieve these results. It’s a no-brainer that anything wasteful along the way is going to slow us down.

Working in a Lean way is all about keeping in mind the seven principles of Lean, one of which is ‘eliminating waste’. There are a number of ways that explain how we can eliminate waste, but to start with, a comprehensive understanding of our processes is a must before identifying what is wasteful. This can be achieved by using simple techniques like the Spaghetti Diagram, a model that helps us identify and analyse waste effectively. 

If we conduct an analysis to find waste in our system, one of the top reasons would have to be communication issues (written or spoken). Communication issues can be anything ranging from incorrect documentation, multiple communication pathways like duplicate emails or conversations for the same subject matter, not asking correct questions or incorrect interpretation of words etc. 

Spaghetti Diagrams prove to be very useful at rectifying communication issues like this.

What is a Spaghetti Diagram?

A Spaghetti Diagram is a visual way of portraying the material or information flow. Imagine if we tie a string to a piece of information, document or a person and then track its process of flow along different points to its destination. If we draw a diagram to depict this journey, it would look like a bowl of spaghetti, hence the term.

Traditionally, Spaghetti Diagrams were used by Toyota to analyse floor plans and understand the efficient floor structure to eliminate wasteful routes to save time. If we consider the same analogy for software development, our routes for product, documentation or people flows should be similarly effective. Some common examples of such flows may be:

  • Process for collecting document sign-off from various stakeholders
  • Communication patterns followed while discussing defect resolution
  • Process to approve a Change or CR
  • Product deployment workflow

Before we look at an example, let’s briefly discuss and look at who the audience is, when we should be doing this and why.

Who: Let’s first discuss who should be part of this visual modelling exercise i.e. spaghetti diagramming process. First off, it’s critical to consider the team dynamics. If your team is cross-functional, it’s crucial that all teams are represented in this conversation. If you have a small team of three amigos, then all should participate. But if you have a large team, then representatives who deal with the activity on a regular basis would be required. For example, in a traditional hierarchical team, the Test Manager or Dev Manager would not be good candidates while modelling a defect resolution activity if they are not involved in the day-to-day conversations regarding the defect. People who can accurately draw the virtual thread of information flow are the key people involved in the activity.

When: This activity is best suited when the team recognises that they need to understand the current workflow and move towards improved future workflows. Sometimes this conversation can be triggered by team members during retrospectives when they highlight that some tasks are taking more time than required. This needs to be analysed and fixed for the future.

Why: There are a number of advantages to conducting this activity. First, in our day-to-day work, seldom do we get time to stop and analyse our processes and think if they are helping or dragging us. Secondly, it brings the team together to conduct a self study of what the current state is and what should be the future state. It’s an activity which can stimulate ideas of improvement or, in some cases, recognise value in some process that may seem long and tedious, but adds value to the larger team.

Example of a Spaghetti Diagram 

Now that we have understood these three aspects, let’s look at an example.

This example discusses spaghetti diagramming of information flow between teams for defects raised.

Context of the project: Imagine a small collaborative team of eight people who use sticky notes to track its issues or bugs. This team is co-located in the same premises with test, development and business pods on the same floor. The process when a defect is raised is to create a sticky note and paste in the dev section. The dev team consists of people who work in a collaborative way which means anyone can pick any task from the pool once they are free from previous tasks. The same case with the test team. Anyone from the team can pick one of the fixed defect sticky notes from the pool and re-test.

The business team acts as support to the dev and test teams to clarify the product vision.

Who: Participants are two developers, two testers and two BA’s from the business team.

When: Meeting arranged post-project retrospective of last release.

Why: One of the BA’s raised concerns – seconded by his team – that they have to repeat a lot of information on the same subject to different people. The objective of the meeting is to understand what’s going wrong and how we can improve.

There are many ways in which we can approach modelling the process flow:

  • We can identify key people handling the information at some point and then plot the process flow. For example, in this case, all key members are identified and virtual information flow of defect is plotted
  • Another way would be to identify teams instead of people. And plot the sticky note‘s journey from test pod to dev pod to business pod. Remember, we can have multiple lines that represent each communication pathway

The below diagram represents option 1:

Visualising waste table


Please note that this diagram is a simple example represented by colour coding. We can add details and have variations to make this diagram more effective. For example, instead of colouring duplicate patterns, we can add a small note next to each path to explain exact details. Another variation can be to add the time taken to discuss each communication pattern. This variation would help us identify delays more effectively.

After the Spaghetti Diagram is plotted and the visual representation is in front of us, it is now easier to identify the pain points.

If we retrospect and look at the patterns, we can notice a few things that introduced waste:

  • Task switching between testers
  • Communication issues due to duplicates
  • Delays that may have been caused by communication issues
  • Delays caused by hand-offs between developers for support activities
  • Re-learning about tasks due to task switching and hand-off. Also, re-learning done due to missing information from the first time the defect was identified

Now that we have a visual representation and issues have been identified, the team can come up with ways to optimise the process to save time, reduce redundancy and avoid rework. Every team operates differently and will have simple solutions that may work for them. There are no best practices when it comes to finding solutions. Saying that, we can always look at solutions that have worked for other teams for similar issues. Here are some examples of solutions used by different teams:

  • Kanban boards
  • Visual test management techniques
  • Standard or defined way to write information while raising defect (description/steps to replicate/expected/actual results etc.)
  • Keep important flowcharts and wireframes visible and clear. Displaying splat diagrams/end-to-end transition diagrams
  • Clarity on your assumptions and inputs
  • Effort spent by the team to study the solution and try to get things right the first time
  • Using centralised test management tools
  • Make sure the tasks are detailed enough in the sprint planning meeting and identify any external dependencies upfront
  • Wherever more complexity is involved, then go with the Specification By Example approach


In conclusion, visualising processes would in turn help us visualise our waste. The key is not to over-simplify or kill the communication between teams, but to make it more effective by optimising the way we work.

Once we can see the wasteful ways we are communicating, we can identify strategies to reduce our waste. This helps us to adopt a leaner way of working which will likely leave us better-equipped to achieve success in the fast-paced world of modern software delivery.

Search the Assurity website (Hit ESC to cancel)