If You Don’t Focus on Business Value, Don’t Adopt Agile

by Robert Dempsey on December 3, 2009

Companies adopt Agile for a reason – to solve business problems. What business prroblems can Agile help solve? Well…

I’ve spoken with a number of CEO’s that didn’t know what or when their teams were going to deliver. I’ll give you one guess to what that did to the dynamics in that organization. And it isn’t necessarily anyone’s fault. Well okay, it’s everyone’s fault actually. It typically comes down to a few things:

  • Expectations from business are either miscommunicated or not known by the team; rest assured, they are still there.
  • The systems in place (project management, time tracking, etc.) do not produce the information that business needs to make informed decisions.
  • The systems in place take so much work to keep up that the Team don’t use them as they take loads of time away from them producing value, thus creating the above issue.
  • There is a trust deficit due to weeks, months, or years of non-delivery on the part of the Team. There are many reasons this can happen, including lack of clear project vision, no one prioritizing the work, the plan of action is mercurial at best.

I wish I could claim credit for “trust deficit” but I can’t. I heard it watching CNN. What a great phrase.

You know when it comes down to it, rebuilding trust in organizations is really what I do. The Team is my entry point into organizations, as that’s usually the area that needs help. Business needs to know what is going on and when they’re going to get what they want. The Team wants to know how they can best deliver what is being asked of them and not be performing death marches.

I act as the bridge between the two. That bridge is trust, and needs to be rebuilt in many organizations. But I digress from the original title of the post.

Mike Cottmeyer wrote a great post the other day – Adopting Agile Isn’t the Point. Despite the concerned look on his profile picture, I concur with Mike 100%. The companies I work with want to solve business problems, typically revolving around the software application they are developing. They want to be able to respond better to customer needs (internal or external), gain ground on the competition, or one of a myriad amount of other reasons. Ultimately it comes down to wanting increased value.

If value isn’t your goal, then don’t adopt Agile.

What do you all think? Please let me know in the comments section below.

Bookmark and Share

Other Posts That Might Interest You

  1. If You Are Being Told How To Do Your Job, You Are Not Agile
  2. The Failure of Do-It-Yourself Agile
  3. Gaining Value Through an Agile Transition

Tagged as: agile, scrum, trust, value

  • In my opinion, the strong focus on business value is missing some critical aspects: http://iljapreuss.blogspot.com/2009/12/focus-on...
  • Business value is a confusing term, it could mean almost anything. I would say, don't adopt Agile without having some higher level goal. 'Business value' is vague and often still a proxy variable for what really matters. In my mind, the customer decides what value is, everything else flows from that. So Agile should result in some noticeable improvement of customer value, be it short or long term.
  • Excellent point Machiel.
  • I've given this some thought over the past couple of days. I think I might end up doing a blog posting on the topic, but in the interim, Rob asked that I reply here with comments.

    I've read both articles; this and the one it references. And I agree to a certain extent, but I think Rob's final conclusion is errant.

    Mike's basic point is that we can lose the sight of our actual goal when we phrase our efforts in terms of task rather than objective. "When we allowed ourselves to define our work in terms of our activities, we risked losing focus on the desired outcome of the project."

    He then applies this to Agile adoptions. The goal is not to have a Scrum master or to do TDD. "Those things are the stuff we do to get the desired business outcome."

    I agree with Mike.

    You can analogously extend this to other areas of your life. I am a runner. I've set a 5k goal time for myself. In order to get there, I've laid out a plan that includes certain tasks on certain days. My goal is not to run 30 miles per week. My goal is not to do 8 weeks of hill training. My goal is to run the 5k faster than a certain pace. If I need to adjust the tasks, so be it. If I focus on the tasks, I lose sight of the goal. I may very well finish 8 weeks of hill training and find myself injured.


    Rob takes this fundamental premise and extends it to say, "If you don't focus on business value, don't adopt agile."

    This I do not entirely agree with. This to me is similar to "If you do not focus on cardio-vascular health, do not take up running." While cardio-vascular health is a significant and worthy goal/objective, it is NOT the only reason to run. Fortunately, it is a common and beneficial side effect.

    I might adopt agile to improve code quality, to deliver in smaller increments, or to improve communication. These are also valuable and worthy objectives. They are likely to add value to the business. Just as a goal of a certain time in the 5k can result in improved cardio-vascular health.

    Adopting agile isn't the point. Business value doesn't have to be either.
  • Thank you for the comment Michael. You make a compelling argument. The companies that I have worked with thus far adopt Agile to gain some benefit - increase visibility into projects, implement a stable process that provides predictable delivery, increase customer involvement, and many others. All of these business goals provide value to the business. It is possible that my definition of business value is different than others. In following posts and videos, I will further explain what I mean by business value, and hopefully clear up some potential misunderstanding.

    Thanks again for your comment. Please post a link here when you do your post. I look forward to reading it.
  • Robert - I think you nailed it here. I was equating business value with direct bottom-line initiatives. Initiatives which sometimes appear to be implemented at the cost of quality or even morale. These are things I have experienced directly in my professional career (although certainly not at my current employer). That is my own bias that I need to shed.

    Value for a business (or individual) can mean many things.

    Thanks for the posts and the conversation. Keep it up.

    http://docondev.blogspot.com/2009/12/business-v...
  • Robert,

    great piece. These four seem to be at the core.
    You might like this: http://clearconceptualthinking.blogspot.com/200...

    Have a good one!
    Rolf
  • Thank you for the link to your post Rolf. Trust is so important to the success of teams, and companies as a whole. I find that in many cases it is missing. However, we can work to bring it back in a big way using Agile principles.
  • I would like to hear some talk, or see some writing about Agile for the solo or small ISV. I think there is a huge amount of us out there that are small companies who could really benefit from Agile if done right. The problem I see is much of the talk is about teams, stand up, blah, blah, blah..which doesn't ideally effect my company.

    So, Mr. Agile...explain how the million small software shops can do this.
  • I'm glad that you said that sir. An "Agile for Freelancers" section of the ADS site is in progress.
  • I will be waiting for it. Anytime I hear Agile or Scrum mentioned, I ask about 1-2 person companies but never get a great answer. My feeling is the techniques need to be tweaked or weeded out to work properly.

    As a freelancer or small software business we don't have the time to dedicate to "being Agile" per se, we need to use what we can with the time we have.
  • I agree Robert. As a small business owner or freelancer all of our time is highly valuable, so learning how best to use that time with as little process overhead as possible is key. That will be the focus of the new section of the site.
blog comments powered by Disqus

Previous post:

Next post: