In 1787, the English philosopher Jeremy Bentham wrote a series of letters describing a new type of prison. The series was later collected into a book called Panopticon; or The Inspection House. Its preface began:
Morals reformed—health preserved—industry invigorated—instruction diffused—public burthens lightened—[...] all by a simple idea in Architecture!
What was his simple idea? The prison—the Panopticon—would be a ring surrounding a central tower, with some distance between them. Someone stationed in the central tower could see all the prisoners, but the prisoners could not see into the tower. Rather than tossing prisoners into a dark prison, letting them connive together, and punishing whichever ones were caught in the inevitable transgressions, the Panopticon would isolate the prisoners and keep them forever conscious of continual surveillance. In his book Discipline and Punish: The Birth of the Prison, philosopher Michel Foucault later called this strategy of control "lighter, more rapid, more effective, a design of subtle coercion...".
Fast forward to 1997 when I met programmer Mark Miller. He had an interesting habit. If anyone found a bug in his code, he'd buy that person lunch and send out a long email to the entire engineering department, praising the person for finding the bug, describing the bug in detail, and delving into the root cause. He made his bugs maximally visible. As a result, he created fewer of them, and the introspection made him a better programmer. If one spoke with the florid language of the eighteenth century, one might even say his morals were reformed.
Fast forward to today. Now I work mostly with Agile projects, and I've noticed that they’re self-regulating in a way that can also be described as "lighter, more rapid, more effective, a design of subtle coercion...". These projects use visibility heavily. For example, they frequently demonstrate forward progress to the business in the terms the business wants—which are not finished requirements documents, code that’s 90 percent complete, or the like, but rather finished, tested, salable features.
But that visibility happens perhaps once a week or even as infrequently as once a month. Agile projects expose themselves in other ways. They push to get a business representative sitting in the bullpen with the team. Mostly that's so the programmers can get advice and direction. But it also places the team under constant surveillance—a far cry from the tradition of programming teams disappearing from the business's view until a month before the deadline, then popping up from the darkness to say they need the schedule slipped.
Many teams will post the current set of tasks in a visible place. If the tasks are written on 3x5 cards that are X'd out when the task is finished, then people making trips to the kitchen or bathroom can regularly see the team’s progress.
It's also the practice to solve internal problems by making them visible. Here's a quote from BigVisibleCharts.com:
At one of our regular retrospectives a few iterations back, the team decided that we had a bad habit of not rotating our pairs enough. More specifically, we tended to pair with the same few people for all of our tasks. That meant we could improve the sharing [of] our knowledge to other team members.
They solved the problem by putting up a "Who Have You Paired With?" chart and let the team's self-surveillance solve the problem:
The idea here is that you put a mark in the square that intersects your initials and your pair's. We didn't enforce any rules other than that. Instead, we just let people come to the realization that they were filling in some squares a lot, and others not so much.
The story of the Panopticon is somewhat creepy if you resent external control. But in the software examples I've given, the subtle coercion is by free choice. Give it a try.