Waste #3: Relearning

Welcome to episode three of our series "The Seven Wastes of Software Development." In episode one, we introduced the concept of eliminating waste from our software development efforts. Waste elimination can be traced all the way back to the the mid-1900's, the birth of lean manufacturing, and the Toyota Production System (TPS). This is how Taiichi Ohno, the father of the TPS, described its essence:

All we are doing is looking at the time line, from the moment the customer gives us an order to the point when we collect the cash. And we are reducing the time line by reducing the non-value adding wastes. [1]

Read the other parts in this series:

• The Seven Wastes of Software Development - Introduction
• Waste #1 - Partially Done Work
• Waste #2 - Extra Features
• Waste #3 - Relearning
• Waste #4 - Handoffs
• Waste #5 - Delays
• Waste #6 - Task Switching
• Waste #7 - Defects

In this episode, I'd like to focus on "Relearning," which is the counterpart to Shigeo Shingo's "Extra Processing." Obviously we all understand that learning is a good thing. It's such a good thing that lean often highlights "the learning organization." So why is RE-learning a waste?

We can gain a bit of insight into this question by looking back at the Poppendieck's first stand-in for extra processing: extra processes. These are extra things that we do that don't provide any direct value to our customers. They are simply pure overhead. Think excessive documentation, signoffs, change control forms, etc.

Now relearning is just another side of the same coin. Since learning obviously delivers value in that we can either deliver a better product or deliver a good product faster, relearning is repeating a value adding activity. If we must repeat an activity that supposedly provides value, then at a minimum we can assume that the first instance of that activity did not provide any value. The more times we repeat it, the more waste we create.

A few of the other wastes are "gateway drugs" to relearning:

• Handoffs naturally cause knowledge to degrade as it is passed from person to person. Eventually that knowledge must be "relearned" somewhere down the line in order for it to provide value.
• Delays fuel relearning by lengthening feedback loops. Requirements that are gathered far in advance of development become obsolete and must be regathered. Defects that lie undetected in a QA wait queue force relearning as developers swap the related knowledge back in to address them.
• Task switching leads to continual relearning. Every time you switch tasks, it takes you an average of fifteen minutes to "reload" a task into your mind before you can be productive.

So what are some common manifestations of relearning?

• Poor knowledge capture will quite often lead to rediscovery of that same knowledge. How many times have you solved a particular problem and not logged your solution for later use? How many times have you had to rediscover that same solution and smacked yourself when you realized you'd seen it all before?
• Many times there are available knowledge experts that you can leverage to the benefit of your project. However, many times we'll ignore them and go at it alone. Every bit of knowledge that we "uncover" that these experts already had is relearned knowledge. Every minute we spent uncovering it was wasted.
• Poorly written or undocumented code leads to untold amounts of relearning. A 1984 study measured the amount of time that we spend understanding code that we're tasked with maintaining at 50% [2]. Poorly written code obscures its intent and behavior and forces us to relearn every time that we need to maintain it. Undocumented yet well-written code that manages a great deal of essential complexity leads to the same result.
• Haphazard project management also generates a great deal of relearning. If developers are constantly being reassigned to different features, leaving their current work unfinished, then each new developer assigned to that work must relearn the knowledge already in the original developer's possession.

Depending on your organization's maturity, each cause or relearning is more or less avoidable. However, we will have some success mitigating any of them by more effectively capturing and preserving knowledge. Here are some strategies:

• Every developer on your team should maintain some type of knowledge base, solutions log, developer journal, etc. Each time knowledge is gained it ought to be documented. Wikis are fantastic for this purpose as they can evolve into "external searchable brains." Daily developer blogs are also an excellent way to capture this type of learning.
• Refactoring is a technical practice which can effectively minimize relearning when practiced well. It produces cleaner and simpler code that is easier to understand. Easier to understand code takes less time to "relearn" when we have to visit it to make changes.
• Automated testing at the unit and acceptance level provides guaranteed up-to-the-minute documentation of your system's code-level and feature-level behavior. Assuming that these tests always pass, you can read them to quickly understand how a given feature or code module behaves.
• Team-based problem solving allows you to bring everyone's knowledge to bear when faced with a difficult issue and reduces the chances that you must rediscover something another developer already knows in order to solve a problem. It also gives everyone exposure to the lessons learned by the team when solving the problem, better preserving that new knowledge for the future.
• Nurturing a kaizen culture of continuous improvement builds knowledge in to the very life of a team. By adding small improvements to your processes on a regular basis you will create new habits that will protect your team's learning for years to come.

That's all for this episode of "The Seven Wastes of Software Development." Stay tuned for the next installment: Handoffs.

References

[1] Ohno, Taiichi. Toyota Production System: Beyond Large Scale Production. Productivity Press, 1988.

[2] Software Maintenance Costs: http://users.jyu.fi/~koskinen/smcosts.htm

Other articles in this series:

• The Seven Wastes of Software Development
• Waste #1: Partially Done Work
• Waste #2: Extra Features