The IT Skeptic - Comments for "Agile and Lean need Renaissance Man"

trust but verify before putting into Production

skeptic — Fri, 15 Apr 2011 03:18:01 +0000

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.

I've had some good results

Tom Rankin — Fri, 15 Apr 2011 00:16:53 +0000

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.

old school

skeptic — Thu, 14 Apr 2011 19:25:17 +0000

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.

Old school thinking

Vin D'Amico — Thu, 14 Apr 2011 18:38:14 +0000

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.

Accountability, complex systems and failures

J Dress — Thu, 14 Apr 2011 15:34:52 +0000

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 ...

enlightened doesn't mean looser

bobgrins — Thu, 14 Apr 2011 12:47:07 +0000

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

enlightened

skeptic — Thu, 14 Apr 2011 03:20:38 +0000

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.

You don't get what you expect, you get what you inspect

CaryKing — Wed, 13 Apr 2011 23:36:18 +0000

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.

Right Brained World

Chris York — Wed, 13 Apr 2011 20:17:58 +0000

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

trusting

skeptic — Wed, 13 Apr 2011 19:15:34 +0000

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.

What brought this on?

CaryKing — Wed, 13 Apr 2011 16:13:42 +0000

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.

Trust, but verify

Dan Kane — Wed, 13 Apr 2011 04:27:17 +0000

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.