Back in the early 1990's, I was once lucky enough to tour the Basingstoke, UK office of a well known Fortune 100 technology company, on a weekend. I was accompanied by a Senior Director, who attempting to find a machine with which to demo a new product, chanced upon a staff member's desk where some documents had been left in full view. He picked them up and said he would lock them in his own office, so that the staffer wasn't fined. Apparently, company policy at the time was to enforce the clean desk policy through an automatic payroll deduction. :-O
More recently, I have encountered a policy on intellectual property protection which goes beyond clean desks but includes clean whiteboards, clean notice boards, clean walls - pretty much everywhere clean that isn't specifically locked and has limited access. The thing is I don't feel such cleanliness policies are compatible with lean software development.
If you visit the site office for a construction site, you expect to see drawings, plans and project plans lying around. The team doing the building needs to be able to view the blueprints. The same is true in Lean manufacturing. They use a technique called visual control. Visual control means that the intellectual property is in full view, pinned to the wall and openly manipulated by the workforce as they work. Software engineering is best done this way too. Models should be on the wall as reference and tribute to work completed. Feature lists, progress charts, production graphs and defect counts should also be in full view. Group accountability is insured by providing transparency and openness and encouraging debate over the work product. When you lock everything out of sight, you discourage debate and group responsibility for results. People need to hold meetings to share information and there is a tendency towards "knowledge is power" information hiding. The result is poorer productivity at the expense of happy company lawyers.
Clean desk IP protection policies, like all policies are constraints. Sometimes the constraining influence of a policy is not immediately obvious. It requires systems thinking to analyze effect on the software development ecosystem and determine whether a policy is truly advantageous.
