Common Muda in Software
A POSTER SERIES BLOG
A series of blogs exploring the featured concepts in The Poster.
In the world of software engineering and technology, people who are fans of LEAN apply the concepts of ‘The Seven Wastes’ to become Leaner. The wastes were first developed by Taiichi Ohno, the Chief Engineer at Toyota as part of the Toyota Production System.
Often referred to by the acronym ‘TIMWOOD’ the seven wastes or ‘Muda’ as they are known in Japanese are:
Transportation, Inventory, Motion, Waiting, Overproduction, Overprocessing and Defects.
■ ■ ■
Wastes are contextual to each company’s unique domain, culture, tenure and other factors. Here are a subset of FOUR that I see in every software team and organisation.
1. OVERPROCESSING
We put too much work into what we produce. This could be too much thrashing out of ideas before starting to build, and too many meetings or discussions and workshops to define features.
Could we instead do some easy customer tests before committing to Ideas and building them?
Overprocessing software solutions and ideas results in situations that are hard to walk back from. Ideas are fully built out conceptually up front, companies are nervous to release until feature-sets are perfect and products that are failing are left for too long before they are trashed. No one wants to cancel projects or products that they have invested work into.
TRY … aggressive Test and Learn cycles focusing on "The simplest thing that could possibly work”. Focus teams on outcomes, use Design Thinking techniques including ample Customer Testing and of course all of the Cultural and Leadership elements such as having a “Safe to Fail” culture.
Another form of Overprocessing is Context Switching, this is very common in tech work when knowledge workers who are working on complex tasks are expected to switch context and work on more complex tasks in parallel. More processing is required to get up to speed on a task, as they pick them up and start parts of them several times over, only to switch rapidly before completion, and that cognitive processing time is waste.
TRY … Managing your WIP levels (Work In Progress) and focus on single tasks to completion, try allowing teams to “Pull” their work (rather than pushing more work and deadlines towards them) , Ruthless Prioritisation of backlogs as well as reducing or destroying backlogs helps us focus on the most important things.
Meetings are a common pain point and a form of Overprocessing. Usually people are frustrated at ineffective meetings, or meeting time breaking their ability to concentrate for long periods of time on complex tasks, causing Context Switching again.
TRY … Continual attention to which meetings are important and/or need tuning. Lean Coffee Technique - agenda-less meetings, and a practice of ‘Using your two feet’ to leave a meeting that’s of no value - make it safe for people to choose where to spend their time. There are so many other meeting hacks and alternatives to make meetings more productive: Meeting free days and weeks, Asynchronous information exchange, do your meetings standing up, do your meetings walking, move meeting time outside of your regular sprint boundary, use the last 2 mins of every meeting for feedback on the value of the meeting, make meetings fun, and many many more.
2. WAITING
As companies move beyond 1-2 teams, waiting time starts to creep into everything. If we have built our ‘small agile team cells’ well that are empowered and autonomous and organised around delivering value, then we can reduce the amount of time teams are waiting for others to get their work done. However, even within teams work can be plagued by waiting for others before it can complete. Waiting creates other problems in that it allows INVENTORY – another waste type, to build up in other work queues.
TRY … Overlapping more on work, pairing is excellent for this, Mob Programming also. For technical dependencies that are outside the team, devote some sprint time to reducing these over time enabling teams to become more independent. True Continuous Delivery culture is the ultimate aim where teams can release their own changes to their customers, however if dependencies hit other teams or Value Streams then a Collective Code Ownership culture can help, ie “If Our team can’t do it now, then the Other team is empowered to change our code”.
Despite all best intentions, well designed team structures and empowerment of teams it seems that some waiting is a factor of people working together to achieve outcomes, for example, you might be waiting for a response to an email or meeting request, or an answer about someone’s availability, or a decision on whether or not you can purchase a product or hold a team event. These small niggles can really grind your gears and cause workplace dissatisfaction.
TRY … having a conversation face to face over relying on a calendar, email or other messaging that you know goes into someone else’s queue. Face to face communication is really fast so this can make waiting disappear. If there’s someone who loves to interact and chat on your team they may LOVE these kind of small jobs that often create big outcomes. In fact if you know people who are ‘get Sh!t Done’ people it’s often because they are good at this. Up the skill level by walking your Face to Face conversation over to a whiteboard.
You can also decide that if it was a priority, the thing you are waiting for would get done. Maybe it’s not a priority? Therefore, deciding to let it go may preserve everyone’s sanity.
3. OVERPRODUCTION
For software products and companies this means too meany features are built into products. It’s very common to believe that certain features are MVP (Minimum Viable Product) but this can be built up by our individual and collective biases over years of using software products. Because we work in technology that is reinforced because we are expert users of many products, and because Confirmation Bias is so strong in humans we find it hard to accept and learn contradictory models and ideas. The statistic from the Standish report in 2002 was that 64% of features in products were ‘rarely or never used’. This seems to have improved since then as so many more applications are created using Lean and Agile techniques building true MVPs and iterating on them over time, however feature-itis hasn’t gone away altogether, and we can reduce it by being vigilant about what we DO prioritise.
TRY … aggressive Test and Learn cycles focusing on ‘The simplest thing that could possibly work’. Focus teams on outcomes, use Design Thinking techniques including much Customer Testing.
4. MOVEMENT
For technology and knowledge workers this equates to too much movement of the individual worker to accomplish tasks. This can be the number of different applications you need to invoke to make your system run or it could be things outside the team such as frustration at how hard it is to book a meeting room or lodge an expense claim. It could be things like getting access to systems, finding relevant supporting documentation, or getting Video Conferencing software to work effectively. It could also be doing much of this while de-bugging critical issues in production - which is more serious as it could be directly impactful to revenue that keeps the company running.
TRY … the tools of reducing movement waste are centred around automation, automating tests, builds, and other manual tasks. In addition, awareness and a bias toward continuous improvement. Try having a ‘wastes’ section on your team board where you collect sources of waste, or ask about it explicitly as a question in regular Retrospectives “Where did we encounter movement waste this sprint?” Build time into the sprint for the ‘constant gardening’ of your environment, tooling and tidying up. Create relevant documentation if you can’t automate movement waste away.
■ ■ ■
ABOUT THE POSTER
We created The Poster in response to the many frustrations we hear from our community and clients about how difficult it is to embed agility, adaptiveness and all the crucial elements that are needed to empower teams to deliver amazing outcomes for their businesses. It contains what we believe is important in terms of principles, values, practices, culture, and mindset for a great delivery transformation that achieves great outcomes for you, and your customers.
If you’re interested in getting your teams closer to the customer, get in touch with ReBoot Co. to find out more about how we bring agility and customer centric approaches to your teams.