Peter Clark's company recently embarked on a "Lean Office" initiative. Now, Peter thinks many of you have steam shooting out of your ears just from reading those words. You probably think that it is just another lame management initiative that will take valuable time away from what is really important: coding and (maybe) testing. But in this week's column, Peter explains why this is the best initiative yet.
I think "Lean Office" initiative is the best thing since sliced bread.
When I was growing up, my father had a few simple sayings he lived by, such as "There's no point in being stupid unless you can show it," "Eat!" and my favorite, "When in doubt, throw it out."
My happiest time of the year (after Christmas) was springtime bulk garbage pickup, when we'd throw out all the junk of the past year. We would scamper madly through the house, looking for anything that might be added to our pile. My dad took great satisfaction in having the largest pile on the block.
Nowadays, I practice the same clean up at work. My team and I had several training sessions, where we learned about the "five Ss": Sorting, Storing, Shining, Standardizing, and Sticking to the Rules. I was enraptured to learn that Sorting involved looking through all of our stuff and figuring out what to keep, what to store, and what to throw away. Here was the leverage I needed to finally get people to throw away the cruft that accumulates around the office like toenail fungus.
Before I go any further, I have a word to say about backups and revision control systems. You need to have all of your source code, test plans, requirement specifications, design documentation, installation plans, etc., under a revision control system. The repository for that system has to be backed up daily at a minimum and a backup stored off-site at least once per month. If you don't do this now, stop reading this article and go set it up!
Here are some of the guidelines I give my people:
- Project Binders: The problem with typical project binders is that they are almost always out of date. An outmoded binder is worse than useless; it is a great root cause for implementing the wrong thing. People have a sentimental attachment to their binders, but I encourage them to throw away any that are not for the most recent projects.
- Backups: We back up all deliverable equipment before it leaves our shop, so I tell them to dispose of all backups prior to the most recent version.
- Release CDs: Our process requires that we burn the project tree from the repository onto CD every time we release to the customer. Trusting in my revision control system and backup facility, I encourage people to dispose of all release CDs. The process has been rewritten so that release CDs can be disposed of as soon as a new one is generated.
- Development Environments: People will keep backups of source code from four revisions ago, but they are reluctant to save the environment that was used to build it. I encourage people to create and save virtual machines (VM) of the build environment for each project.
- Test Environments: It can easily take a week or more to set up a test environment for an obsolete system--if you can find compatible hardware. I encourage people to VM every computer in the test environment.
- Paper: A piece of paper more than a week old is suspect. You are safer getting the information from your repository, which (hopefully) has the latest and greatest version.
- Computer Parts: I throw out virtually every computer part (e.g., memory, disk drives, video cards) that I find. Most of the equipment is antiquated and of unknown provenance.
- Documentation: I throw out all obsolete documentation in our library. I encourage people to dispose of duplicate documentation, but I allow them to keep it at their desks if they really want it.
My collection of project materials