In short, the number one goal in lean manufacturing is eliminating waste. In this series I'm looking at the seven categories of waste identified in lean manufacturing, how these translate to software development, and how scrum can help eliminate that waste, or not. This is the second post in the series.
In this post I want to focus on transport waste, one of the seven categories of waste targeted by lean manufacturing.
Transport doesn't sound like something that's really relevant in software development, but there are some typical wastes that happen in software development projects that are analogous for various reasons.
Transport waste in software development doesn't happen when physical material is transported between locations, but rather when focus is shifted and tasks are transported. I like to split this into two categories:
- Task switching
- Task reassignment
Software development can be very complex and, especially when done well, requires deep levels of concentration. To exit that state of focused concentration and switch to something else, which in turn most likely requires a similar level of deep concentration, is not trivial. If you don't take the time to focus properly you're likely to make lots of errors and what you produce is likely to cause more problems than it fixes, in other words it will create more waste.
Modern culture has created the false impression that humans can "multi-task", but this is a myth. There are lots of studies in psychology on this topic and it falls somewhat beyond the scope of this post, but the findings show that people do not multi-task, they just task-switch. I'm not going to go into more detail here, but this is nicely summarized in this blog post by Aza Raskin.
The bottom line is, switching between tasks costs time. The time spent switching between tasks will make everything go slower and is waste.
Another form of waste in software development is task reassignment. This is similar to transport waste in that you're essentially transporting work from one person to another, either internally in the team or to new team members that are joining the team. It's almost intuitive (especially for most project managers) when a project is in trouble to throw extra resources at it. But this is fundamentally flawed. Software development complexities mean that ramp-up time for new people joining a project will be big and often prevent the existing team members from effectively continuing with their work. Adding and removing people from a project, or moving tasks between people on the team, creates a special type of waste because of handovers. The goal with these changes is usually to make things go faster, but the result is usually that things actually go slower, at least in the short term.
How does scrum address this?
Let's start with task switching. There is a lot of emphasis in scrum on getting things done and especially on not starting anything if you still have partially completed tasks. Implemented properly by a team, this eliminates task switching waste very effectively. It's therefore important to make sure team members are doing one thing at a time. Daily scrums are especially useful for this purpose to keep this focus.
Ideally, the team should also focus on completing one thing at a time, i.e. nobody should start working on feature two if there are tasks waiting on feature one. Two partially completed features at the end of a sprint will do no good. This may seem counterintuitive, but when a team gets it right it does wonders to bring focus and increase flow.
On to task reassignment. Teams change over time, especially if you're busy with long term projects, and in most cases it would be naive to assume that a team can remain completely static for the duration of a project. Also, if something isn't working on a team you have to try and fix it. In extreme cases that may involve changes to the team structure. But this should be a last resort and should come from within. Scrum puts a lot of emphasis on team autonomy and generally a change shouldn't be made to a team unless the team demands it, however scrum doesn't really dictate when our how this should happen, so the onus is on the team to handle this responsibly.
The iterative nature of scrum does provide an advantage though, in that when task reassignments happen the impact is smaller. Since the project team will always be working on a relatively small subset of overall requirements, the potential damage in task reassignment is somewhat limited. To be clear, it still causes a lot of waste, but the potential size of that waste is much bigger if you're using a waterfall-type approach.
In summary, scrum directly addresses transport waste by encouraging task completion before moving on.
More indirectly and incidental scrum also reduces the potential risk in task reassignment due to its iterative nature.
Where scrum doesn't have a direct impact and the team needs to make sure they apply good common sense and engineering practices is in watching for individual task switching at a micro level (e.g. individual team members should apply discipline and not be distracted too often by things like e-mail) and by making sure task reassignments are only done when absolutely necessary.
