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

Re: [scrumdevelopment] Scrum evaluation

Expand Messages
  • Pascal Thivent
    I m not an expert but my understanding of the optimized throughput you are describing in your example looks related to the concept of Takt Time (the rythm
    Message 1 of 35 , Mar 28, 2008
      I'm not an expert but my understanding of the "optimized throughput" you are describing in your example looks related to the concept of "Takt Time" (the "rythm of the demand") picked up by Toyota for the TPS. In a lean environment, the pace of production flow is set to the takt time. And in such an environment, or in a sandwich shop, the priority is indeed the Takt Time, not the productivity. Great example !

      On Fri, Mar 28, 2008 at 1:15 PM, 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


      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.  

      m

      On Fri, Mar 28, 2008 at 1:53 AM, Tom Poppendieck <tom@...> wrote:

      Matt –

      Good results come from good people using good practices.  Which part does management not have to care about?

      - Tom

       

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of matt gelbwaks
      Sent: Thursday, March 27, 2008 10:54 PM


      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Scrum evaluation
       

      Mike,

         I don't think I was clear in what I was trying to get across.  What I meant was that unless we can show a definitive connection between how agile your team is and how productive they are, I am not sure a company really cares how agile they are.  Most of us on this list know innately that being more agile means being better able to meet customer expectations and more effectively releasing the "right" software.  However, senior management really does not care about the methodology we use to produce those results, what they care about are the results.
         Lockheed is not going to care if they are more agile than the garage shop nor if they are more agile than Northrup.  They will care if they can produce the code necessary to manage the next gen ATC software, because that immediately translates to higher probability of success and therefore better margins and better chances at the next big contract they bid on.  
         Agile is a methodology and a tool.  The better we use it the better equipped we are and the more we will "win". My comment on devolution is centered around process improvement.  Our real process is that of producing software.  Agile helps us improve that process.  However, if people in business perceive (rightly or wrongly) that we are honing our process skills at the sake of the business objectives, interest in the enablements and transformations will dwindle (and rapidly, my opinion).  If we connect the dots for the business, they will continue to give us latitude (and budget).
         A last point is that we may find that particular companies are "not very agile" on our maturity scale only to find that they are continuously beating us in product release (and efficiency).  Rather than get them to conform to our understanding of agile, we should understand what they are doing because they might be the next step in the evolutionary search for software nirvana.

         m








      --
      Pascal Thivent
    • 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).

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

        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.