Re: [scrumdevelopment] Scrum evaluation
- 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,On Mar 28, 2008, at 4:20 AM, matt gelbwaks wrote:
- 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.)
--- In email@example.com, Mike Cohn <mike@...> wrote:
> 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.
> Mike Cohn
> Agile Estimating and Planning
> User Stories Applied
> 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