You didn’t stumble across a manufacturing blog don’t click the back button! Like Lean Software Development and Kanban, 5S was born in Japan as part of the just in time system (JIT). 5S was and still a widely used practice in the manufacturing world and supports Kanban from the continuous improvement perspective. David Anderson introduced an Agile practice for development from Kanban, let’s take a look at 5S to see how we can adapt that to our development practices. Let’s get lean!

First, let’s take a quick look at what 5S is as a concept. 5S is a method of organizing a workplace or a manufacturing plant.  Once 5S has been applied the area in which team members work is clean and organized. In a manufacturing plant a team member can move from station to station easily and can also identify what tools might be missing immediately. A couple examples are provided below:

5S DrawerBeforeNAfter

Wow, how neat and organized! What are these crazy 5Ss and what do they mean….

  1. Sort – Sort through an area to find and eliminate waste. Waste may be actual trash or an item in the area that is not needed to complete the tasks in that area. 
  2. Straighten – Once the area has been sorted it should be organized and setup to flow in such a way that work is completed with as little waste as possible.  Waste in the way of time, if moving an item could save one minute and you perform that movement a 100 times per day the area is more efficient.
  3. Shine – Make sure that the area is always neat and tidy.
  4. Standardize – Put standards in place to ensure the put forth effort is maintained.
  5. Sustain – Ensure adherence to the policies and standards put in place.

Now that we know what the 5Ss are how can we adapt those to our development.

  1. Sort – We can go through the code and remove legacy code that is no longer in use.  Teams even with a configuration management tool like Perforce will keep commented code around. Get rid of it, you can always review previous changes. 
  2. Straighten – Often times with software development there is a let’s just get it done we can go back and make it pretty later effect. Take time to separate the code and use the object oriented design approach you’ve heard so much about. If you’re embedded don’t have a 200k line main.c file!
  3. Shine – Allow time for refactoring, clean the code up when you have the opportunity. Don’t forget to run your tests again!
  4. Standardize – If your team doesn’t have a coding standard work to put one in place, don’t assume others will look at code for examples.
  5. Sustain – Once the standards are in place paired programming and code reviews can ensure proper technique and also help develop the programmer’s skill set.

Now that some ideas have been put in place take a look at your coding space and think of ways 5S could apply.

Join the Discussion

    • Mike

      Um… I feel the sudden urge to go tidy up my garage. Great blog post, Terry. Without some of the XP practices you speak about, it’s tough to really ‘transform’ an organization’s IT group into a finely tuned Agile machine.

    • Jason Yip

      I’d say “5S is a method of making problems visible by organizing a workplace or a manufacturing plant.” The make problems visible part is essential and commonly missed. It’s not just housekeeping.

    • Terry Densmore

      Thanks Mike and Jason for the comments. @Jason I couldn’t agree more, once 5S is applied problems become visible naturally and a self-organizing team should take care of them as they appear. Whether that is while in a pair programming session or a code review. If the problem is large enough some time might be set aside to talk about it possibly during a retrospective and setting a sprint goal to take care of it.

    24 + = 25