Loading ...
Sorry, an error occurred while loading the content.

Re: Scrum evaluation

Expand Messages
  • Ash
    Mike and Matt, I think you guys are bringing up very relevant points. And Mike, I just took your survey too...thought the questions covered the spectrum of
    Message 1 of 35 , Mar 29, 2008
      Mike and Matt,
      I think you guys are bringing up very relevant points. And Mike, I
      just took your survey too...thought the questions covered the spectrum
      of Agile nicely. I want to add to this discussion as I think this is a
      very relevant topic in many companies.

      So, Matt if I understand you right, you are saying that "we got twice
      as better at doing Agile than last year" should be supplemented with
      "we also got twice as productive" or "twice as fast" or "half the
      defects" etc. right?
      In my current company, I can say "we doubled our customer satisfaction
      in two years of Agile" and that helps me get mgmt attention at
      improving Agile practices. I think it is important to have one or more
      metrics to go along with tracking your Agile maturity.

      I think what Mike is saying is
      that you don't need to target AMM Level 4 (or any other benchmark) on
      an absolute scale unless you are sure that your competitor is Level 3
      and even then all you are saying is I need to be better than them.
      Improving on your current state is a noble enough goal.

      I see more and more Agile coaches getting frustrated or disparaging
      other companies for not doing Agile practice X or Y. As long as the
      company practicing Agile is getting better at it and improving the
      practices as well as the results, it shouldn't matter. They are still
      doing the right thing, IMHO.

      I have the same thoughts about process audits (whatever type,
      generally internal in larger companies). If a project fails audit,
      that should also imply that the project will fail to deliver results
      or will cause an adverse effect to the long term health of the
      company. If neither is true and the project failed a process step that
      was there simply for process sake, one that has no effect on the
      productivity, it shouldn't matter.

      lastly, our mgmt also time and again has toyed with the idea of
      measuring productivity at an organization level (or dept level), story
      points are not meant for that so they have toyed with Function points.
      Any comments on if anyone on this list has successfully measured
      productivity at a Dept or Org level?

      Ash Tengshe

      --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@...> wrote:
      > Matt--
      > First, productivity is a dangerous thing. The example I always use is
      > owning a sandwich shop. As the owner I tell my employees I want them
      > productive. I even put a bonus in place for the sandwich cook--the
      > more sandwiches he makes (more productive) the bigger his bonus. At
      > the end of the day I return and there are hundreds of unwanted but
      > well-made tuna sandwiches on the counter. The customers who ordered
      > harder to make sandwiches are an angry mob in the lobby. The cook has,
      > however, been very productive. There have been discussions on this
      > list in the past as to why "throughput" isn't quite the right thing to
      > think about but I still like it as being very, very close. As the
      > sandwich shop owner I want my staff to optimize throughput (in a pull
      > manner). Cycle time is another way to think about it. Perhaps a TOC
      > expert wants to chime in.
      > There are many things that a business cares about. A frustrating thing
      > for me in agile is that we keep trying to make new ones up, e.g.,
      > "business value" and such with corresponding burnup charts of such
      > things. Businesses have ways of measuring what we want. The problem is
      > that things like return on investment, economic value added, revenue
      > per employee are lagging indicators and highly influenced by other
      > factors as well. What a well-run business typically wants is an
      > assortment of *lagging indicators* (like those) and some *leading
      > indicators*. A company should never pursue agile for agile's sake (and
      > I think I said that) but should pursue agile under the premise that
      > the degree to which we are agile is a leading indicator of positive
      > things to come on the lagging indicators. Simply: If told of two
      > companies, one highly agile one not at all selling the same product
      > with equivalently skilled staff, etc I think most or all of us would
      > expect the agile company to outperform the non-agile.
      > Regards,
      > Mike Cohn
      > Author:
      > Agile Estimating and Planning
      > User Stories Applied
      > www.mountaingoatsoftware.com
      > On Mar 28, 2008, at 4:20 AM, matt gelbwaks wrote:
      > > Gee, I am really having trouble making my self clear....I thought I
      > > had my argument pretty solid, maybe I don't.
      > >
      > > I don't mean to say that management does not need to care about
      > > practices, just that they care about results more. On the right,
      > > you have really good, really strong practices. On the left, you
      > > have really good results. They do care about the right, but they
      > > care about the left more. If this was not the case, then we would
      > > not have had Enron nor many other spectacular "failures".
      > >
      > > In my experience, if you are achieving the results desired, no one
      > > cares to see how you are doing it (the sausage effect). Scrutiny
      > > only starts when results begin to flag.
      > >
      > > This being said, going back to Mike's original statement, all I want
      > > to lobby for is to change it from:
      > >
      > > a company's goal should be to be "more agile" than its
      > > competitors or "more agile" than it was on a previous assessment.
      > >
      > > to:
      > >
      > > a company's goal should be to be "more productive" than its
      > > competitors or "more productive" than it was on a previous assessment.
      > >
      > > I, as Mike and a number of others do, believe firmly that the
      > > productivity boost should come from a mix of agile practices. I
      > > just don't think conformance with the practices is the right
      > > measure, because I have seen organizations that are very agile and
      > > are still dysfunctional enough to squander their productivity gains
      > > to the extent that Management has told them to return to what they
      > > were doing before.
      > >
      > > Last attempted point - measure agile and you will get process.
      > > Measure productivity and you will get throughput.
      > >
    • Joseph Little
      Mike and others, Lead in: Mike, in his email below, argues that companies should (or do) want to be more agile than relevant competition rather than
      Message 35 of 35 , Apr 1, 2008
        Mike and others,

        Lead in: Mike, in his email below, argues that companies should (or
        do) want to be "more agile than relevant competition" rather than
        "perfectly agile" (my term).

        Mike's comment makes sense to me. Let me also add a set of related

        My understanding is that Toyota faced this problem with lean (or, as
        they call it, the Toyota Production System). They felt they were (and
        perhaps are) better than everyone at this stuff. "So, how do we
        continue to get better?" "The relentless pursuit of perfection."
        (Lexus tagline, and also a key lean idea.)

        The idea is that as we approach our current definition of perfection,
        we (with new knowledge) re-invent the specifics of it, moving it
        further out of reach...and then aspire to that goal.

        I think that perfection never exists in this all-too-real world, so it
        is not reasonable to ask "have we become perfect yet". So, Toyota
        says "Are we clearly better than Toyota now?" (ie, better than Toyota
        was last year). This is how they instill Kaizen mind.

        This makes sense to me as a reasonable approach, based on other
        experiences in my life. Clearly helps if you feel you are already
        better than the competition.

        When Google gets complacent, it will die quickly.

        To speak with even more guesses than usual, I will say that Google
        becoming more Agile than Google (was last year) would be a worthwhile
        investment for Google. (In a static analysis, the investment might
        seem unnecessary; in the dynamic world, it is needed.)

        Thanks, Joe

        --- In scrumdevelopment@yahoogroups.com, Mike Cohn <mike@...> wrote:
        > Matt--
        > It took me a long time to come to this realization and for years I
        > thought you were right. Here's why I now disagree.
        > I used to think that we should pursue agility for agility's sake. That
        > it was something like a gymnastics competition and companies should
        > strive for perfect 10s on all marks. However, business isn't a
        > competition against a standard of perfection. It is competition
        > against other companies. All one company needs to do is be a little
        > better than another company in a variety of ways to reap tremendous
        > rewards. An example, I just noticed because I got a periodic report on
        > this is that 95% of the pay-per-click viewers to my website come from
        > Google, about 4% from Yahoo and 1% from MSN. Is Google really 94x
        > better than MSN at placing my ads and providing web searches? No,
        > they're not 94x better than MSN. Are they a little (or perhaps a
        > medium amount) better and does being that small amount better
        > translate into huge impact on their revenue from searching? Indeed.
        > Would Google becoming more agile help even more--yes, almost
        > certainly. Would it worth the additional investment? No.
        > I struggled with this for years until I finally thought about it quite
        > hard. What really pushed me was that not a single executive or senior
        > manager I met *ever* said to me, "Gee, I wonder on an absolute scale
        > how we're doing from 1-10." Not once was I asked anything remotely
        > like that. Instead I was constantly asked, "How do we compare to
        > others?" Executives and managers want to know how they are doing
        > relative to relevant others. Lockheed doesn't have to go be more agile
        > than a garage-based web 2.0 startup. But they do perhaps want to be
        > more agile than other defense contractors. For years being asked "how
        > do we compare" bothered me. Eventually I thought through why the
        > question was coming that way and it makes perfect sense to me now.
        > Another thing to think about is how agility improves over time. I have
        > a team from the mid-90s that I remember quite well. They were my first
        > agile team and they were awesome. However, they were less agile than
        > most companies today because of all we've learned in the last 13 years
        > and because of improvements in tools and such. They would have been a
        > 10 on any agility scale back in 1995. Today they'd be lower but
        > comparing them to other healthcare teams they have probably
        > consistently remained well ahead of the average.
        > Finally, I have no idea how you jump to the conclusion that my
        > assertion that agility should be measured relative to others will
        > cause "the agile movement to rapidly devolve like so many other
        > process improvement approaches before it." Since all other process
        > improvement approaches I can recall offhand from the past were based
        > on "do these x best practices" rather than a "be better than your
        > competition" the argument seems backwards if anything. That is, past
        > approaches but failed but I am advocating assessing in a different way.
        > Regards,
        > Mike Cohn
        > Author:
        > Agile Estimating and Planning
        > User Stories Applied
        > www.mountaingoatsoftware.com
        > On Mar 27, 2008, at 11:19 AM, matt gelbwaks wrote:
        > > When stating that a company's goal "should be to be 'more agile'
        > > than its competitors or 'more agile' than it was" is dangerously
        > > close to suggesting a company implement process for process sake.
        > > There must be an obvious and clear link to better productivity by
        > > being more agile or the agile movement will rapidly devolve like so
        > > many other process improvement approaches before it.
        > >
        > > m
        > >
        > >
        > >
        > >
        > > On Thu, Mar 27, 2008 at 1:02 PM, Mike Cohn <mike@...
        > > > wrote:
        > > Kenny Rubin, another Scrum trainer, and I created an agility
        > > assessment for exactly this purpose. The intent of this was to allow
        > > companies to assess themselves or to allow experts in the assessment
        > > to help assess companies. A key aspect of this assessment is that
        > > results are meant to be comparative. That is, a company's goal
        > > should be to be "more agile" than its competitors or "more agile"
        > > than it was on a previous assessment. THis is in contrast to
        > > approaches like CMMI (and others) that hold out that there is a gold
        > > standard or levels of agility.
        > >
        > >
        > > The assessment is completely free to take. It's even free to have
        > > Kenny or I run a report that produces averaged results for your
        > > company,project, etc. If you want to do that, though, be sure to
        > > have anyone taking the assessment enter the same value in the
        > > question about the name of the company (it can be a made up name if
        > > you don't want me to know it). Then email me after you think
        > > everyone has taken the survey and I'll generate a report for you.
        > >
        > > What we plan to do in the future is be able to create comparative
        > > reports. This will allow a company to compare itself to other
        > > similar companies. All data is confidential, though--I don't plan to
        > > say, "Wow, look how bad this company is and look how great this one
        > > is." We're getting close but don't yet have enough data for
        > > comparative reports to be meaningful. Eventually though we hope for
        > > the ability to say "compare my company to other companies producing
        > > commercial software and that have six months of experience with
        > > agile", etc.
        > >
        > > The survey is at
        > >
        > > http://www.surveymonkey.com/s.aspx?sm=0KPuayvaZy1GnXfMJh1dMQ_3d_3d
        > > and
        > > http://tinyurl.com/2tmx2n
        > > (which is just a shorter version)
        > >
        > > Regards,
        > >
        > > Mike Cohn
        > > Author:
        > > Agile Estimating and Planning
        > > User Stories Applied
        > > www.mountaingoatsoftware.com
        > >
        > >
        > > On Mar 23, 2008, at 7:51 PM, <leo.ren@...> <leo.ren@...>
        > > wrote:
        > >>
        > >> Hi
        > >>
        > >> I want to evaluate one team how agile they are. Does anybody
        > >> can tell me what's the
        > >> essential of agile(scrum). For example, if they have daily scrum
        > >> meeting? If they have scrum team? How
        > >> do they do test? What situation can be think they are fully agile
        > >> or only part? Thanks.
        > >>
        > >> Best Regards
        > >> Leo Ren
        > >>
        > >>
        > >
        > >
        > >
        > >
      Your message has been successfully submitted and would be delivered to recipients shortly.