Code smells and their corresponding refactoring recipes can give a team a common vocabulary to help identify patterns and prevent technical debt. Similarly the 7 Wastes of Lean Software development can provide a similar framework that can help detect team and process smells in order to become more effective.
The word ‘waste’ can get people’s attention and when used to describe behavior or results it can cause them to be defensive. However, in Lean Software Development, which was adapted from the Toyota Production System, it’s a regular, everyday word that is used to describe any dynamic that prevents or slows down the delivery of value.
A couple of months ago we started what we called ‘Waste Awareness Wednesday’. Each Wednesday one or more wastes were presented and discussed for an extra 10 minutes after our regular standup. The objective was to focus on an area of waste, introduce a new (in some cases) vocabulary word, and then take the week to identify examples of each waste with peers and within teams. With the greater awareness and common vocabulary everyday is now waste awareness day.
I’ll now cover each of the 7 wastes, some of the ‘smells’, and what can be done to eliminate the waste.
7 Wastes in Lean Software Development:
I’ll now briefly go over each of the wastes and share insights, but before I do, I want to say that even though some of them might seem obvious, by digging deeper we were able to see the more subtle value in killing aspects of these wastes. In other words, don’t be fooled by their simplicity; chances are the challenges and frustration that you might be experiencing is likely a result of one or more of these wastes. Okay, let’s get started.
This waste is usually a result of other wastes (I’ll explain later, keep reading) or from an over eager team that may lack discipline. Although the desire to start work is rooted in good intentions, if a team is not careful they will find themselves with too much work in progress. When that happens, less value is delivered while members of the team often feel overwhelmed by the overhead of too many open pull requests, too many user stories or tasks in development and having to switch between them. Product managers may feel the pressure to switch between customer requests in an attempt to make them all happy while only delaying the happiness of all customers.
Some of the smells of Partially Done Work include:
- Feeling a lack of focus
- Feeling the need to switch tasks in order to make everyone happy
- Long Daily Stand-ups
- The ever growing need for status meetings or updates
- Not being able to get timely feedback on code reviews or design decisions
- The need for a project manager
- Too many open pull requests and branches in source control
- Loss in confidence in product management or engineering
- Slower, less frequent releases
- Slipping deadlines
- Lack of gratification that you are doing good work
The list can go on. Basically when you get that frustrated feeling that you or your team cannot move quickly, it’s probably due to partially done work.
What to do about it:
- Do less at a time (smaller batch sizes)
- Say no to new work, even talking about new work is creating partially done work
- Focus on done and what each task needs to get done (focus on flow)
- Track how many items are in progress (from customer request to release) and focus on decreasing that number
- Discuss with your team the situations that cause work to be started before existing work is completed and find out ways to fix the cycle as a team
The waste of creating extra features is an interesting one because this kind of waste can multiply once a team or company has accepted that it is okay. For example, if a product manager insists on requirements that don’t add direct value it can create a culture where engineers can more easily justify over engineering. This vicious cycle can lead to all of the other 6 wastes. In fact Taiici Ono said that “Extra features is the worst waste because all of the other wastes go along with the extra features.” For example, code that doesn’t need to exist to add value to customers still requires maintenance, can cause delays, have defects, and require more relearning across the team, especially if the value isn’t evident. Bad.
Some of the smells of Extra Features include:
- Requirements/code that cannot easily be explained or justified with data
- Time spent on design or coding that seems off to others on the team
- Anytime justification for a requirement or code starts with “I think it will…” or “If we do this now then in the future we will” (aka. YAGNI) or “Just watch, once this is done they will see how brilliant my idea was”
- When individuals can’t hold back how proud they are for a solution and all they want to do is tell everyone. (could have false positives)
- When you build features that customers aren’t using
- Resume Driven Development / Introducing new technology just because
This waste is something that everyone can spot when others are doing it but it can always be harder to spot when you are doing it. This is usually because of the stories that we often tell ourselves.
What to do about it:
- Get all disciplines (engineering, design, etc) working together to understand the problem before the best solution is decided
- Verbally agree as a team that you won’t tolerate extra features
- Hold others accountable by asking “Why” questions
- Measure feature usage from customer interactions (and remove unused code)
- Always be testing and getting feedback (UserTesting is a great solution for this, BTW)
- Clarify hypotheses that are being tested so everyone can more easily identify extras
- Start small and iterate into solutions, leaps in solution scope are dangerous
- Avoid waterfall practices that include hand-offs
- Avoid high fidelity mockups that hide complexity and value in early stages of development
It can sometimes be hard to distinguish between learning and relearning. Generally speaking the relearning waste is evident when organizations learn the same lessons two or more times. It’s investing time and energy into doing more or less the same thing without any additional value being delivered.
Some of the smells of Relearning include:
- Experiencing the same production problem a second time
- Individual teams learning the same lessons about bad tech, practices, and process
- Feeling frustrated that others on your team ‘don’t get it’ or ‘aren’t being trained properly’
- Individuals or team learn late in the process (or never) about knowledge, experience, and resources that are around them
What to do about it:
- When unexpected problems arise get to the root causes and take the time to share learning across your teams
- Turn learning into code and automation when possible so the same kind of problem can never happen again
- Document and systematize repeated patterns or subtle cultural expectations in the organization or team that typically cause confusion and frustration (branching strategies, releasing procedures, code review standards, coding styles, etc)
- Avoid excessive documentation that can get out of date and create the deception that everyone understands but because of the quality and quantity of the documentation people won’t read it at all
- Share learnings openly across teams, pair across teams, demonstrate and discuss work across teams to find experience and knowledge early in the process
Although handoffs are difficult to avoid completely, the more they happen the dumber an organization gets resulting in failure. Individuals who are are handed off work take longer to get up to speed through (relearning) and crucial knowledge is lost. In fact, it estimates that half of all of the tacit knowledge is left behind. The worst part about it is that humans can’t see what was left and it’s not until it manifests itself in people doing the wrong thing, the wrong way, for the wrong reason, that it is recognized. Then even when it is recognized it’s usually seen as the fault of the engineer or designer who is often incorrectly judged for their lack of competency. The result is that value is reduced and delayed. Sad.
Some of the smells of Hand-offs include:
- A process where work is transferred between teams, roles, or people
- A product manager thinking that more upfront work and learning done by the PM will save engineering time and speed up the delivery of value
- An engineer who takes requirements literally and moves forward without discussing requirements in depth and getting to the bottom of WHY
- Projects that get behind and are moved to more knowledgeable, senior, or skilled people in the organization
- Team structures that optimize by building separate devops, platform, design, _____ teams
- Starting work on a team because they are available with the expectation that the project will be completed by another team
- Projects that skip around people and teams
- The IT mindset of ‘software engineers just need requirements and then they can just code’
Eliminating hand-offs may not be completely achievable, especially before teams evolve to a lean organization. But any effort that reduces handoffs will help transform the organization and team structure towards less waste.
What to do about it:
- Make sure teams are structured to be cross-functional and self-sufficient to complete projects end to end
- Get the people who will be doing the work together as early as possible
- Don’t create or rely on requirement documents for understanding (remember a story is only a promise for a conversation, the acceptance criteria may be the conclusion of the conversation but lacks context and understanding)
- Finish the work where it started, avoid moving projects across teams
- Individuals within different disciplines/roles should work together to uncover understanding and needs at the same time (reduces having to hand-off partial information lacking context)
- Compare the cost of deferring the start of a project to starting a project sooner knowing that hand-offs will occur
Delay is a waste that is often caused by other wastes. For example, time spent ramping up on a project that is handed off delays the project. Delay is also a catalyst for waste because while people are waiting they may start new projects which increase the amount of partially done work. In my experience, some of the largest technical debt increases happened immediately following a large delay. Pent up frustration, urgency, or pressure creates an environment where poor decisions are made resulting in poor quality and the justification for poor practices. Delay is a deceptive waste and is the antithesis of flow.
Some of the smells of Delay include:
- Feeling of sitting idle
- A large amount of partially done work
- Individuals working on lower priority work because they are blocked (creating more partially done work)
- Nothing getting done
- Continually getting blocked
- Intense increases in development activity followed by slow waiting for feedback, or on QA, etc
What to do about it:
- Identify the root cause of the Delay. Is it because of another waste (likely) or a dependency on a third-party (sometimes unavoidable)?
- Don’t take the “let’s start something new because I feel idle” bait when blocked (push hard to get unblocked instead)
- Reduce the work in progress so more resources can be focused on the root cause for the Delay
Task Switching is when one switches from task to task either because of a lack of discipline (the path of least resistance) or because of interruptions. The cost of a task switch can be 15-40 minutes. With enough task switches it becomes clear that flow is not obtained and productivity and job satisfaction suffers.
Some of the smells of Task Switching include:
- A feeling that you aren’t moving forward or getting anything done
- Extra frustration when you get interrupted by other teams or individuals
- A lack of discipline (being bored or starting work without being conscious of it), being delayed, or having too much work in progress
- When passive communication like Slack or email replace active communication
- Managers who interrupt flow (push vs pull)
- Too many scheduled meetings that cut up the day
- People on their computers in meetings (this attempt at multi-tasking reduces absorption of information when it’s available which requires relearning, which usually involves having to interrupt others, which triggers a task switch — OUCH!)
- Too many bugs or production outages that distract the team from focus
- Too much partially done work, delays
- Constant change of priority or direction
- Reconsider how office layout and seating arrangements impact interruption and task switching
What to do about it:
- Discuss the problem as a team and identify root causes of task switching and how you will communicate around minimizing them, for example:
- Use the Pomodoro technique
- Pair programming can help keep focus and discipline
- Creating a PULL culture where engineers pull work and information from the process instead of others pushing the information through meetings and interruptions
- Put Work in Process (WIP) limits to ensure focus on fewer tasks
- Evaluate meeting effectiveness and reduce and eliminate meetings
Defects might be obvious waste. The key here is to recognize that the waste and cost increases significantly between the time of a defect’s creation and the defect being fixed. Having fewer bugs and ‘building quality in’ is the most efficient way to avoid this waste.
Some of the smells of Defects include:
- Teams discover defects late in the process (even production)
- A mindset that QA is supposed to find defects instead of prevent them
- Build ups in defects
- Defect databases systems (storing defects)
- Moving on to new features when there are outstanding defects in recently built ones
- Defect fixing marathons or ‘bug scrubs’
What to do about it:
- Engineering practices that include writing automated tests
- Continuous integration
- Continuous delivery of code and features
- Policies around not tolerating defect build up
- Eliminating ‘Defect Trackers’ that accumulate defects or hide them from the teams
- Spending time with customers to see how defects impact their experience with software
- Fixing defects as part of the regular flow instead of only fixing them when they build up
- Invest in preventing bugs (code reviews, TDD, etc)
As we have grown so quickly, tripling our team last year, it’s become evermore important that we find areas where we can create a common vocabulary around things that are important. Mary & Tom Poppendieck wrote a few books on the subject and did a great job translating the Lean Manufacturing wastes to Lean Software. Delivering value to our customers quickly and constantly is important to us.
While we emphasize code design, quality, readability, maintainability, and overall cleanliness, and look for code smells and opportunities to improve our code, we should also be just as vigilant about looking for waste smells and opportunities for individuals and teams to work more effectively together.
Working to build teams of people who value and invest in the continuous improvement of individuals and team interactions is just as important. I often tell my teams that the soft skills around identifying opportunities to eliminate waste, running experiments, and constantly looking to improve towards maximum effectiveness is just as rewarding as clean, maintainable, and code smell-free code. These are the skills that set engineers and organizations apart.