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
Showing posts with label leadership. Show all posts
Showing posts with label leadership. Show all posts
Monday, August 10, 2009
Lean on me
I've been reading up a lot on the roots of lean manufactoring. It's become in vogue to apply these principles to the practices of software development and while I applaud that, I think it's important that one understands the genesis of an idea, especially if that idea has lived through several generations and has been translated from one very different arena (in this case, from automobile manufacturing in the 50s, 60s, and 70s as part of the Toyota Production System) to another (envisioning, developing, deploying and managing software in the 21st century). Most folks that have a cursory understanding of lean tell me it's about the reduction of waste - throwing away all of those things that do not directly add value to your endeavor. Queues, inventory, task lists, etc. are all bad because they are things that are sitting around and not adding value. 'Just in Time' production - that's the key. That's all certainly core to the 'what', but unless you dig into Taiichi Ohno's teachings, you miss the 'how'. Central to the 'how' is the role of 'management'. To Ohno, a good manager is a master craftsman, mentor, and teacher. Managing is Teaching. That is the real power of this philosophy. If you believe management is about anything else, then you've already lost. You may go, grasshopper.
Oh, But I was so much older then - I'm younger than that now
What's worse - poor management or poor leadership? I saw the former get a beat down from the latter today and much as I am pained by bad management, it can be worked around. I don't think bad leadership can be, especially if it is unquestioned. It brings to mind that old Hans Christian Andersen classic, ' The Emperor's New Clothes'.
Sometimes I feel like a deck hand on the Exxon Valdez with Capt Joesph Hazelwood at the helm. With all the officers going on about how fine the good Captain navigates around those icebergs after polishing off his third bottle of rum - please, have another, Captain! That's a great idea!
Hans, I wish you were here ...
Sometimes I feel like a deck hand on the Exxon Valdez with Capt Joesph Hazelwood at the helm. With all the officers going on about how fine the good Captain navigates around those icebergs after polishing off his third bottle of rum - please, have another, Captain! That's a great idea!
Hans, I wish you were here ...
'I wish that for just one time, you could stand inside my shoes. You'd know what a drag it is to see you' - Robert Allen Zimmerman, 1966
I can't believe I missed this presentation when it first came out - very instructive and relevant in my neck of the woods. The advice is easier given than taken (and its lessons applied). But it's gotta be better than business as usual.
Anyway, on to other things.
Rummaging through the blogs, I thought that these posts were worth a plug:
Anyway, on to other things.
Rummaging through the blogs, I thought that these posts were worth a plug:
Subscribe to:
Posts (Atom)
Posts
