Agile and Lean need Renaissance Man
Agile and Lean both seem to be based on idealistic, some would say naive, assumptions about human nature and capabilities.
I have been in discussion with Mike Orzen, the Lean IT guy, about both Lean and Agile concepts. I was talking about my concerns about both Agile and Lean, and how they may provide a clue to the general resistance to these concepts.
Many of the disciplines of IT Ops arose because of a healthy cynicism about human nature based on bitter experience. Like airline safety, each control is introduced based on a past disaster (or occasionally a near-disaster, although change in the aviation industry seems to require dead bodies).
On the other hand, both Agile and Lean seem based on a rosy view of human behaviour that many in IT Ops would regard as naive.
First, they want to unravel the operational controls and instead trust people to act in the best interests of the organisation, not themselves. They also want to trust them to act carefully, within the organisation's risk parameters, and complying with all regulations and standards. This seems sophomorically idealistic to me. See my past comments on "cowboys".
Second, the concept of small teams seems to be predicated on Renaissance Man, the miracle polymath who can fulfill multiple roles and leap tall buildings; who is seemingly skilled at most things, and interested in everything else. Human progress can be put down in large part to specialisation, and Agile seems to want to put that into reverse. Developers who understand operations; wild creative types who respect risk mitigation; project managers who are relaxed about changing deliverables; programmers who are good at supporting and training end users; system geeks whom can focus on business value; hackers who document. I reckon each one of those wears a hen's tooth around their neck - they're hard to find.
Waterfall and agile are two ends of a pendulum. So I accept there may be some room for loosening up in some orgs. But business operations is largely about mitigating risk. If you think that isn't true then go ask the shareholders. I find faith in human nature endearing but not practical in a business context. In some cultures it would be an unmitigated disaster.
So I'm all for empowerment but only within a framework of ownership, accountability, verification, audit, measurement, reporting and individual review. "Do what you think best and know that we will check and measure and you will be held accountable for anything unauthorised, noncompliant or outside bounds of quality and risk".
I think concepts of creativity and freedom have their place and that place is not in Production.
And as for finding the right Renaissance Man Person for the job, that might be happening now when Agile and Lean teams are new, exciting, well-funded groups operating in a specialised niche. I don't see it being so easy to find the multi-skilled, idealistic people if Lean and Agile get to be run-of-the-mill.
Made in New Zealand 
Comments
Old school thinking
The old school, centralized, "command and control" mindset is outdated. Software projects have become too complex for centralization. The pace of change in business is far too fast for a small group of managers to control.
Furthermore, the younger generations have grown up around "socialization" and group dynamics. They demand more of a say and more control over their work products. The world has changed.
Agile approaches are not perfect, far from it. They offer clear distinctions from the old and outdated waterfall approaches that have failed us time and again. Bottom line: If you work in a staid and slow-moving company, use waterfall. It can succeed. If you work in a fast-paced and dynamic company, go agile. It works better.
old school
I'm old enough to welcome the label "old school". We old farts have heard "the rules are different now" often enough to take it with a grain of salt.
I've had some good results
I've had some good results by giving people a fair bit of freedom on the where & how of creating knowledge - where I've had the balls to give people enough freedom.
trust but verify before putting into Production
As Dan said, "trust but verify".
I'd extend that to "trust but verify before putting into Production". Giving people freedom works most of the time. Other times they let you down. So it is all about managing risk. In most IT Production environments I know, the costs of realised risk are high. Giving freedom in development is admirable. Giving freedom in production is ... sooner or later... disastrous.
Accountability, complex systems and failures
What does accountability mean for you when you take into account that [[site:Great paper on failure of complex systems | all complex systems are broken]]?
My point of view is:
Agile is not about getting rid of accountability. It's about redefining accountability in a complex world. When we think of SCRUM: Roles and the corresponding duties are defined. Therefore a person assigned to a role is accountable for the fulfillment of the duties assigned to the role.
Agile is about: How can we optimize learning and adaptability to cope with complexity and change?
Agile does not ask for the Renaissance Man. It asks for good teams.
And there will always be someone how cleans up the room after the meeting ...
Right Brained World
Rob,
As you have pointed out, historically, to reduce the number of fires we have to put out, IT has introduced process and controls to minimize the risk of things going wrong. We like to control things (and attempt to control the people who use these things) to help alleviate our resource constrained lives.
The concept of increasing controls to get higher performance from IT is a fallacy. These controls tend to work for people that are following a specific set of tasks and that don't require any creativity. Left-brained work. However, the people who work in IT Operations aren't isolated to performing work that has been pre-defined and has a clear set of instructions that can be measured and incentivized to follow. Creative work isn't just for the developers. Everyone in IT has some level of creative right-brained work that they must do. Having a set of principles to follow and a clear view of the purpose can dramatically help to increase performance. This is why Lean and Agile attempts to lay a foundation of principles that helps guide work.
High performing people work better when they have freedom. This has been proven. I suggest watching Daniel Pink's TED talk from 2009 on Human Motivation. http://www.ted.com/talks/dan_pink_on_motivation.html
So while I agree that the current management style of IT can and does produce the need for higher levels of auditing, measurements, and attempts to control, this is not the best approach. There is a more enlightened way. Maybe I am naive, but I am an optimist and have a core belief that people by nature want to do good. They just need the right system to work in that allows them to do so.
Of course we can't simply remove the controls and expect everyone to follow some mission statement that we hang on a wall. There is much more effort needed for a Lean transformation.
Chris
enlightened
People have different ideas of "good". And a lot of IT people have a different idea of good than say the Board of Directors. The governors - the Board - define good. Others must comply. They may not want to.
I don't disagree that "High performing people work better when they have freedom". In IT generally, dev and ops, I'd bet there are hundreds of millions of practitioners worldwide. They range from "High performing people" to those you wouldn't trust to organise lunch.
yes I think you are naive and optimistic. Neither is a good trait when you are tasked with protecting the organisation and managing risk, which i contend are some of the primary functions of IT Ops. And as Cary said, that only becomes more important as more is externalised to third parties. I don't think these Agile and Lean ideas of looser control are "enlightened", I think they are dangerous.
enlightened doesn't mean looser
I've lead several Lean projects at our company, and one of the outcomes is always, or should always be, a process document. The goal is to reduce wasted effort and unnecessary steps and thus have a more efficient way of doing the work. But since you are bringing something new to the team or changing something existing, you can expect to experience resistance; everything from "convince me why is this better" to "I don't care, I'm not changing." Management support and enforcement of the improvements has to happen, it won't be assimilated organically. So I've never seen Lean as requiring fewer controls, but enabling people to find better solutions that get evaluated and implemented properly.
Best Regards,
BobGrins
You don't get what you expect, you get what you inspect
I certainly agree that people want to do good. Often, however, what is good is not well expressed.
And, as we increasingly modularize and outsource IT, we must consider consider that those performing tasks may not even be part of your organization - just performing a specified service.
IT has a need to exercise good governance and management practices. ITIL processes are fine, but governance (CobiT, for instance, supercedes that need). IT also has a need to deliver services at a price - so appropriate risk and fiscal controls are essential. Especially if we're to be services oriented.
What brought this on?
I'm not sure why you lumped Agile and Lean together.
What event has triggered this?
I've used Agile, or Agile predecessors, since the late 80's. Agile can be used within Waterfall steps. And, to my knowledge, there is nothing about Agile, evolutionary, development that prevents good management control. Other than good managers, of course.
Realized benefits are primarily an outcome of good management and not necessarily the best technology.
Most "development" these days is really modular configuration of COTS software. Agile actually works better for that purpose - use the COTS software as a starting prototype. Let management decide just how much tailoring goodness they want to afford.
As to Lean, empowering a team, within management constraints, to see the whole, deliver as soon as possible, build integrity in, eliminate waste and prototype so that you can decide as late as possible from alternatives does not seem like a bad idea to me.
Drucker wrote that, "Nothing is less productive than to make more efficient what should not be done at all."
Proceeding deep into a project with a waterfall approach before there is a prototype and real understanding of what is being asked, is one of the chief reasons that 67% of projects fail to meet expectations.
Risk to computer projects does not usually arise from technical failure, but from a steady drift in intent, which persistently widens the gap in expectations between the technologists and their customers. Dealing with that risk early on and consistently is more likely to achieve a good outcome.
trusting
In terms of what they do, agile and lean have little(?) in common. In terms.of attitide they have much. Both are often presented as idealistic, "small government", trusting philosophies that assume the best of human nature.
Trust, but verify
As I read this post, memories of 1980's Ronald Reagan come to mind. "Trust, but verify." I am no Lean or Agile expert, but I have to assume that proper application also means accountability for outcomes. My concern, and I think you are saying essentially the same thing, is the likelihood of unintended negative outcomes.