Sunday, February 7, 2010

But the Business Doesn't Care How Successful IT Works!

In my experience most business managers are more concerned with getting results out of their IT resources than how to get them. There was a time that I wanted to zealously evangelize the business about the benefits of Agile and other lean concepts that lead to high-performing engineering teams and quality IT development. I'd receive the invisible rolling of the eyes, the gentle long sigh, or the blank stare with a merciful yes-nodding of the head out of kindness. As an eager, sometimes naive, and ambitious young professional I tried not to let these reactions dissuade me from continuing. I thought to myself, "...eventually someone will listen to what I'm saying and help me make it happen."

These business leaders, of some the companies I've worked for, heard my words but didn't necessarily listen to them. They're all fine with following the latest proven productive trend if it lets them claim that they're a better organization for it. But the bottom line is that most don't really care how a successful IT project is implemented so long as it gets done with the results they expect. My answer to this problem is don't worry about explaining the "how" to them...just show them. Nowhere is this even better expressed, in my experience and that of my other professional colleagues, than within the financial industry. Everything here is about "P&L". Profit and Loss.

Now for those of you reading my past posts, you know I have a bias towards leveraging an Agile approach to successful software development. The problem that I and other Agile advocates face is that some business managers hear all the Agile jargon and perceive it as "touchy-feely", or even downright confusing. Here are some of the reactions I find to some of the Agile/Lean concepts I present to them. Heck, some are just plain good management practices:

Concept 1: Self-managing & self-organizing teams

  • "We're losing control by doing this. Some times you need a top-down approach to getting things done."
  • "It's no wonder there isn't focus on the work that needs to get done...we've got everyone acting like chiefs since they're self-managing."
  • "How will we know who's working on what?"
Concept 2: Estimating in Points, Using Velocity & Burndown Charts
  • "How the heck am I going to know when something is going to be done if there aren't days and hours attached to each and every task!!"
  • "Points are meaningless. This kind of talk is childish and full of garbage."
  • "Where's my Gantt Chart, the critical path tasks and the assignees for each?"

Concept 3: Priorities and Identifying Release/Sprint/Iteration Focus

  • "We already told you what's important, and what we're trying to sell/build. Just get started and get it done ASAP!"
  • "We've got a lot of contracts pending on all of these projects, so they're ALL IMPORTANT!"

Concept 4: Motivating & Empowering Your Teams

  • "If we get this product completed by year-end, we'll be able to close on a $3 million deal. Isn't that motivation enough?"
  • "These engineers get a guaranteed salary and generous bonus every year without having to worry about making any sales numbers. What more do they want?"

In the coming days and weeks, I'll be writing about my past experiences with the issues surrounding these concepts and the solutions I implemented to address them. The main point is I started to walk away from the jargon (Agile-speak). To make successful IT development work at these organizations I began focusing exclusively on just doing it and showing them the results they wanted.

Have you had some notable quotes and reactions to any Agile/Lean concepts you presented like the ones listed above? If so, what was said and how did you manage it?

1 comment:

  1. Gabino

    In the example that I want to explore the resistance was from the head of information security with a political agenda and no mandate. He tried to use this project as a lever and trashing my approach was one way to generate a voice and "credibility".

    He objected to agile in principle because it was unstructured, undisciplined and there was no project control! As this was a new concept to the company(management and IT) there was nobody knowledgeable to back me up in rebutting the statement. I managed to maintain my point but with the need to change his perspective. I achieved this with a direct approach pointing out his ignorance on the subject (which went down badly) and challenged him to inform himself and prove me wrong. I used this approach based on the personality I was dealing with. It took some time but working together he eventually conceded that he did not know enough to have made the statements he did and agreed that an agile approach was in fact the correct one. By this time the project was underway but it did not follow traditional agile lines, morphing rather into a loose iterative approach supported by both IT and management without either having to commit to an agile methodology.

    In principle the business did buy into the following:
    - iterative approach
    - self managing teams (with difficulty).

    I produced cost and budget estimates using story points and velocity but this was not transparent.

    For this company an agile approach to both project management and IT development was badly needed given time and budget constraints across all projects but the company lacked a practitioner and my time as a consultant was too limited. The head of information security was not that person even though ultimately convinced.