"Baa Baa Mr. Sheep. Careful, you're walking all over your own self now. Walk on, Mr. Sheep. Walk on." - R. Newman, 1977

The common take on effective governance is that it first and foremost requires an effective governor, with perhaps second being a decent overall legislature. It's hard to argue that these are necessary ingredients; however, my vote for top dog is a level of participation and, to take it further, ownership on the part of the governed.

This ground up governance is usually down on the priority list for corporate leadership in my experience, and I think it's mostly because that's a much harder thing to realize. It's gotta start with the organizational model you choose: small teams of multi-disciplined individuals stand a better chance of enabling ground-up governance.

When I say 'multi-disciplined', I don't mean that everyone on the team can develop software, write requirements, test, coach, manage workloads, and so on. I do mean that everyone takes an interest in all those things to a degree. That a programmer is not afraid to attempt writing requirements, that a business analyst doesn't shy away from testing, that a quality assurance specialist doesn't balk at some light software touch-ups. You have your roles and your primary job but it shouldn't box you in and limit your ability to help the team: that's the priority in this ideal.

Ideally, each of these teams would own one or more relatively discrete and preferably deploy able, deliverable, releasable products and would be responsible for those products from birth to death. Members of this kind of team are much more likely to feel empowered than specialists that belong to very large teams and produce a piece of the product, perhaps never to deal with it once development is finished, or never to see it except during "QA testing".

Even small teams that are walled off into these specialized corners have a hard time feeling like they own and are responsible for something.

It's the difference in accountability dynamics: the ideal being more akin to parent/child while the more common org resembles a the math teacher/pupil relationship (or maybe guard/inmate is more accurate).

It's also the difference in efficiency and frustration levels. When you are specialized, and your team is only one piece of a much larger puzzle, you have to cross organizational boundaries much more frequently to get things done. And if Lean Manufacturing has taught us anything, it's that crossing boundaries is very expensive in terms of time and waste. Lean, unlike many concepts/ disciplines/processes/analogies, does translate pretty well from manufacturing and engineering to software development.

This isn't news - there is plenty of empirical evidence to support this from a number of sources. Scrum, XP and other agile disciplines have been espousing this for many years now. Taiichi Ohno proved it back when the Eniac was state of the art.

This is all aimed toward an ideal, I am not kidding myself.

That's the hard part, especially if you've already got a workforce that through attrition (due to previous practices and culture) has rid itself of a large percentage of precisely those kind of people that would thrive in this ideal environment. It also means you've likely retained a goodly bunch of people that positively fear and loathe this.

But ya gotta start where you are and and slowly reverse that attrition cycle.

Empowerment and self management of those doing the work is key to this. Hey, I'm not suggesting a proletarian overthrow of the bourgeoisie management (well, maybe I am to some degree, but with a wholly capitalistic bent). Rather, that we attract and retain those developers and testers and business analysts and product managers that are excited about ownership, decision making and self management in addition to their primary technical skills. In so doing, we can gradually tip the scale, making management more about technical coaching and mentoring. If the managers can't make this transition, either through philosophical opposition or because they don't have the chops, it's time to lose them through position elimination and attrition.

Sure, you still need executive and administrative/HR management in any corporation of size, but the percentage of management to worker bee in most IT departments I've worked with is tipped way out of balance, in some cases with more managers than developers or BAs or testers in a given group (and as a consultant for many years, I've worked in a good cross section of the industry). Mainly this is done because one naturally wants to advance in their profession. Usually that means moving into management and often, the company loses twice (you lose a valuable and eager technical asset and you gain a mediocre and unenthusiastic manager).
But it is hard. Not nearly as hard, though, as fighting against the natural ways in which individuals organize absent traditional governance - throughout history, survival of the fittest as shown this to be true.

Local optimization is only good if ownership is sufficiently complete of the things you're optimizing within that locality: if it isn't, likely as not your optimization will adversely impact another piece of the total package and in the end, the total package is what counts.
After all, you don't hear folks say, "Boy, this web site keeps crashing on me - it's rarely available but when it is, did you see that nifty calculation widget? Makes all the downtime worthwhile".

The other thing is unnecessary waste. One of the "lean" questions often asked is 'how much of your day is spent working on communications with other groups versus work that directly benefits the end product?' We should all aspire to minimize this with the understanding that we can't wholly eliminate it. Communications and traceability documents are waste (they do not directly benefit the end product). They may or may not be necessary waste. If they are necessary, rather than just saying 'that's the way it is', why not look further to see if we can change the landscape such that they become obsolete and unnecessary?

Mother nature, in the end, only yields so much. As a wise woman once said, 'it's not nice to fool Mother Nature' - just as true with organizations as it was with butter.

See Scott Ambler, Kelly Waters, Ken Schwaber, and Phillipe Krutchen for starters and google +organization +software +ownership +empowerment +self-managing +benefits +challenges