everything in its place
July 8, 2004 in 5S, CM, agile, gemba, kaizen, lean, leansoftwaredevelopment, manufacturingmetaphor

A couple of weeks ago I finished reading Gemba Kaizen by Masaaki Imai. Just like all the other books on lean manufacturing, I found it extremely rewarding and thought-provoking, while at the same time being somewhat longer and more repetitive than I might have wished (the second half comprises an interminable list of case studies, many of which add very little to the value of the book).
The main idea I took away from the book was that of 5S. This is basically rigorous and institutionalised house-keeping (translated as Sort, Straighten, Scrub, Systematize, Standardize). The idea is that an untidy or disorganised workplace can contribute significantly to reducing the throughput of value for the customer.
Can this concept be applied to software development? I believe so. All our tools have to be readily accessible when needed. Our codebase, workspace and CM system should all be well-organised, and should contain nothing that isn’t needed to add value or promote flow. Our build should be clean and automated, and driven only from components that are CM-controlled. And when we’re working as a team, all our processes and techniques should be standardized so that each person’s actions are understandable by all.
I don’t necessarily promote the idea of documented standards for everything. But any task that requires arcane knowledge is a potential contraint on the future execution of some process. And similarly anyone who stubbornly does things their “own way” is often going to cause headaches for the team down the line.
Likewise, if the codebase is a part of the gemba, then it too must be tidy and well-organised. That doesn’t mean it should be full of documentation, but at least we should practice “a place for everything and everything in it’s place”. Our code should be easily understood and easily navigated, and should contain no duplication of concepts.
Kaizen activities in lean manufacturing often begin with red-tagging, in which all superfluous inventory, tools and rubbish are marked with a red tag and moved into one corner. At the end of a week, if any tagged items haven’t been used, they can safely be disposed of. Perhaps software projects and teams could begin the move to agile by red-tagging tools and code…
-
Top Posts
- in-place editing in Rails 2.0
- reek, a code smells detector for ruby
- setup and teardown for a ruby TestSuite
- hexagonal soup
- people problems vs process problems
- the middle hexagon should be independent of the adapters
- avoid boolean parameters
- if...
- process improvement metrics - some questions
- gravity and software adaptability
Category Cloud
Twitter
- RT @martinfowler: OH: Certified Scrum Master ought to be renamed Certified Scrum Novice 13 minutes ago
- Wicked 5 hours ago
- RT @jchyip: A culture where it is considered disrespectful to challenge decisions is a culture on the path to failure. 7 hours ago
- @marcjohnson Yes, good to finally meet up! (Not insightful, just old) 9 hours ago
- Just spent a very enjoyable evening ranting on my usual hobby-horses with the @shruggers. Must get this side of the Pennines more often 18 hours ago
- Arrived Sheffield! Disappointed there's no snow; going straight back home 21 hours ago
- @ashleymoran @shruggers See you there :) 22 hours ago
- @marcjohnson I'm coming to ShRUG at Mojo; I feel like a walk tho, thanks all for the offers of a lift @andygoundry 22 hours ago
2 Replies
[...] for de-commissioning the term ‘refactoring’. (And I suppose me calling the codebase gemba is no [...]
[...] So instead the development team will carry out some maintenance work: refactoring the codebase (tidying gemba), improving test coverage, installing new tools etc. (As things turned out, analysis generated some [...]