Skip to content
* / softthoughts

Effectiveness and getting there efficiently

Dan Rawsthorne wrote an interesting post about “Scrum is Effective, not Efficient“. I don’t follow fully so i made some comments. I write it here again because it has some aspects that are related to software architectures and which are important to produce quality. To have the full context of this post it is important to read Dan’s post.

Dan says: “The more feedbacks you have the more effective you’ll be… ”

I think the amount of feedback is not so important to determine the  effectiveness, what is more important is the quality of the feedback which is aligned with business goals. Can’t a few good feedbacks be enough to know how effective you are? You can specifiy some quality scenario’s for measuring your effectiveness. Ofcourse lines of codes or function points are to vague and don’t tell much business/product relevant effectiveness. Thereby, finding the right feedback through quality scenarios can help to reach the effectiveness efficiently instead of going for a lot of feedback.
Maybe it is not easy to specify precisely what needs to be done, this is where agility comes into the picture i think, but in general every project has some clear business (case) goals and for those, quality scenarios can be provided to measure the overall effectiveness.

Dan says: “In order to be efficiently agile, you would need to have feedback loops that got you the answers you needed as fast as possible, and have as few feedback loops as possible. And we don’t know how to do that, now do we?

If you can specify how to be effective, and you say that agility is effective it means you can specify effectiveness, than you can specify a way to reach it efficiently. I think too that agility is effective and i would measure it with quality scenarios. This also gives the possibility to have a reduced set of feedbacks related to the Q scenarios and allow us to get there efficiently because we know our goal.

Dan says: “…if you can’t produce the right product every time (or virtually every time) then don’t start adding efficiencies to your process.”

Why can’t you add efficiencies in your inspect and adapt cycles?  Rethinking and implementing the way to produce a powerfull effect can also ask for incorporating some efficient steps.

Dan says: “waterfall is efficient — agility is effective”.

I think if you say it is efficient, it means that it also has to be effective.  Saying something is efficient means its result is effective.  So in the conclusion it sounds to me that waterfall is the ultimate way to go, which i doubt and probably also not the one of Dan.



Leave a Comment
  1. Dan Rawsthorne / Jan 17 2009 4:34 am

    I disagree with your last paragraph, obviously. Efficiency does not imply effectiveness. Efficiency means that you get where you are going with little waste. Effectiveness means that you found the right place to go.

    You can very efficiently go to the wrong place. For example, say you are going to dinner with friends. You know a shortcut to the restaurant, and get there in record time, hitting all the lights. You were very efficient. Unfortunately, it is the wrong restaurant. You were not effective.

    The main purpose of agility is to have feedback loops to improve your aim at the target, that is, to figure out how to be effective. The act of being agile may include many false starts and turns as you go. Generally speaking, it does not try to find the fastest way to the correct target, which would be efficient. It is only trying to find the right target eventually.

    Once you can always find the right target, then you worry about improving your process to be more efficient. That’s the point of my blog. Unfortunately, many businesses focus on efficiencies before they are effective. By doing this they make it very hard to be effective, and wind up doing the wrong thing very efficiently time after time.

    Just a quick response… Dan 😉

  2. softthoughts / Jan 17 2009 8:59 am

    Hey Dan,

    Thanks for the response. 🙂

    I have to say that in your example you are measuring efficiency with an intermediate state and only effectiveness with your end target. In you definitions:

    – Efficiency means that you get where you are going with little waste.
    – Effectiveness means that you found the right place to go.

    you also measure with your end goal. Although you are going to the restaurant you talk about it to be efficiently but was this really where you need to be? No, so it is not effective and first it looks efficient, but it is not where you need to be so it was a waste of your time and not efficient. Your example measures efficiency and effectiveness with different goals. Measuring these qualities can only be done/or being relevant when it is done against the same end goal.

    You initially don’t have to measure efficiency when you are at the restaurant. You have to first evaluate the effectiveness. If this turns out to be ok then it is relevant to take a look to the efficiency part else talking about it and saying it is efficient is not relevant. Like you say first tackle the effectiveness than efficiency.

    You say “Once you can always find the right target, then you worry about improving your process to be more efficient. “.
    In this phrase you also state (implicate) that when you talk about something to be efficient it has to be first already effective.


  3. charliealfred / Feb 12 2009 11:03 pm

    I like both of your perspectives on efficiency and effectiveness, although I’d like to take a slightly different angle.

    I think that efficiency is a measure of effort required to achieve a goal that is important to the subject. While effectiveness is a measure of utility, seen from the perspective of whomever the effort is intended to satisfy.

    For example, suppose a software project wants to achieve very high quality and measures this by defects (weighted by severity) per thousand lines of code.

    One approach the team takes is to fix all of the easy, low severity bugs. If viewed (myopically) by engineering management, this project could be the model of efficiency. The bug elimination rate is the highest in the company.

    However, if we look at effectivenss from the perspective of the customers of this software system, this low-severity bug jihad is not very effective. The relatively small number of high-severity bugs still cause frequent crashes and data corruption at hundreds or thousands of customer sites daily.

    So, this is a typical value modelng scenario, the things one chooses to measure and the value they place on various measurements is subjective.

    Engineering management measures bug removal effectiveness strictly in terms of quantity, severity, and effort, and on those measures the project team appears to be extremely effective.

    Customers measure bug removal effectivenss based on the amount of damage the defects cause, and how quickly the bad ones are eliminated. Using these measures, the project team is relatively ineffective.

    Charlie Alfred

  4. softthoughts / Feb 13 2009 11:51 am

    Hey Charlie,

    I think you make a very nice point to show that the end goals are not needed to be aligned, or perhaps better said the same, when talking about efficiency and effectiveness, at least if I grasp fully your definitions. From some perspective this unalignement can be obvious and needed, still I have the idea that being more customer-oriented and for example less solution-oriented is more generally suited, ofcourse for your customer but also for the software company. The customer naturally has his perspective on these quality aspects and so the software company.

    If the software company was customer-oriented and fully aligned with the goals of the customer I still have the impression that the relevance of efficiency would still come after the effectiveness aspects. If the approach the software company would use, reduces most of the big crashes and thereby provide a higher availability, which is for example an important business goal of the customer, the approach is effective for the customer. If the software company helps achieving this goal fast, it is an efficient approach for the customer. A part of the customers main goal is reached, namely high availability. The approach of the software company looks thereby to the customer primarily effecitive and secondary efficient and I think the software company can also gain a lot by using this perspective.

    Ofcourse like you say (if I understand well) perspective (and/or context) says it all. Your definitions are more general perhaps than my customer-oriented view. In a way I think customer orientation is the best way for whatever outcome of the business. Agility helps in this area too. We do our job to satisfy our customers, at least I try. 🙂 But this is another discussion, but I think you are right with your more general definition. But if I may ask, should customer orientation than not be the main orientation of a software company?


  5. charliealfred / Feb 16 2009 3:01 am

    Yes. You definitely got the idea! Context and perspective alter what we think is effective.

    I certainly agree that as a general rule having customer focused goals are prefereable to internal goals. After all, our customers provide our revenue, which is like food or water to a business.

    But things are always more complex then they seem!

    What happens if the software manager is under pressure from his boss to improve quality, or what if the software project team will get bonuses if their achieve certain quality metrics.

    People behave in certain ways for lots of complex reasons. That’s because everybody has their own “value model” which establishes their priorities and guides their behavior.

    One of my favorite documented examples of this is in Chapter 2 of the book Freakonomics, by Levitt and Dubner. After examining thousands of real estate deals in metropolitan Chicago, they found that real estate agents who represented themselves kept properties on the market for an average of 7 days longer and sold homes for about $10,000 more than when ther represented another client.

    Hmmm, you’d think that the real estate agent was working in the best interests of their client, right? Problem is, their client’s interest has two driving variables: time to sell and sales price.

    In this case, when the real estate agent sells their own propery, the extra $10,000 goes into their own pocket. This is enough to justify waiting a week for a better deal.

    However, when they represent a client, the 6% commission on the $10,000 price difference is $600. When split 50-50 with the buyer’s agent, the difference is $300. Given this, which real estate agent accepts the risk of losing the buyer by stalling, and tries to hold out for a better sale price?


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: