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

40272Re: [!! SPAM] Re: [scrumdevelopment] Re: How popular is SCRUM and agile?

Expand Messages
  • Dan Rawsthorne
    Aug 1, 2009
    • 0 Attachment
      Ah, but as a trainer and coach, my job is to make you better. I use hair
      splitting to get you to look at yourself and start introspection... I
      try to make sure it's not about me, it's about you and scrum.

      Dan Rawsthorne, PhD, CST
      Senior Coach, Danube Technologies
      dan@..., 425-269-8628



      Peter Stevens (cal) wrote:
      >
      >
      > Hi Dan,
      >
      > Obviously hairsplitting can be the basis of a lively thread ... ;-)
      >
      > My experience with hair splitters in a live context is that they often
      > end up playing a game of "My Scrum is better than your Scrum." The
      > players argue about whether some practice is true Scrum or not. This
      > frustrates all involved parties and leads them away from the values
      > and principles of Scrum. So like a sharp knife, hair splitting is a
      > tool to be used carefully, at the risk of cutting off your own finger.
      >
      > Cheers,
      >
      > Peter
      >
      > Dan Rawsthorne wrote:
      >
      >>
      >>
      >> Ah, MJ, I agree with you. But I think that hairsplitting is important on
      >> this group, because if we don't know exactly what we're talking about
      >> here, how can we expect to explain it to others? The fact that I do
      >> split hairs has allowed me to have conversations like "yes, you're doing
      >> something like scrum, but you're not really Agile", and "yes, you're
      >> using C++, but you're not object oriented." I think that bad behavior
      >> hides in the mushiness, if we allow it.
      >>
      >> And, MJ, of course you should prioritize with a customer-centric focus.
      >> But that does not mean that you prioritize only things that have
      >> customer value. I know, more hair-splitting... but I've seen and heard
      >> of a lot of teams that have a hard time justifying something that
      >> obviously needs to be done (like rearranging the team room) because it
      >> doesn't have "customer value." The good news is that it's the SM's job
      >> to question all this and ask "why is this valuable again?" and "don't we
      >> need to do this?" when working with the PO. It's all about the
      >> conversations, remember... there really aren't that many rules.
      >>
      >> Dan Rawsthorne, PhD, CST
      >> Senior Coach, Danube Technologies
      >> dan@... <mailto:dan%40danube.com>, 425-269-8628
      >>
      >> Michael James wrote:
      >> >
      >> >
      >> > I find Dan technically correct in the hairsplitting contest, but I
      >> > sympathize more with Peter -- especially on the need to prioritize
      >> > with a customer-centric focus instead of appeasing all the internal
      >> > organizational crud that builds up as companies scale.
      >> >
      >> > If we're brought in to transform organizations, what's the point of
      >> > emphasizing loopholes that encourage them to keep doing what they've
      >> > been doing?
      >> >
      >> > --mj
      >> >
      >> > On 7/31/09, Dan Rawsthorne <dan.rawsthorne@...
      >> <mailto:dan.rawsthorne%40drdansplace.com>
      >> > <mailto:dan.rawsthorne%40drdansplace.com>> wrote:
      >> > > * value to the user or customer -> what exactly should the
      >> product owner
      >> > > prioritize which doesn't have value to the customer or user? Lots of
      >> > > things, including things that have value to the business, the
      >> > > organization, the team, the product...
      >> > >
      >> > > Dan Rawsthorne, PhD, CST
      >> > > Senior Coach, Danube Technologies
      >> > > dan@... <mailto:dan%40danube.com>
      >> <mailto:dan%40danube.com>, 425-269-8628
      >> > >
      >> > >
      >> > >
      >> > > Peter Stevens (cal) wrote:
      >> > >>
      >> > >>
      >> > >> Hi Dan,
      >> > >>
      >> > >> I agree with your summary, but am puzzled by your disagreement
      >> on the
      >> > >> constraints.
      >> > >>
      >> > >> * value to the user or customer -> what exactly should the product
      >> > >> owner prioritize which doesn't have value to the customer or user?
      >> > >>
      >> > >> * 'done' at the end of the sprint. -> Agreed. Oops. 'Must' is too
      >> > >> stong. The team commits to do its best to meet the sprint goal and
      >> > >> backlog commitments. Timebox and Quality (Definition of Done)
      >> are more
      >> > >> important than Scope.
      >> > >>
      >> > >> * definition of done. I agree that the definition is agreed betweeen
      >> > >> P-O and Team (or perhaps even part of a departmental or company-wide
      >> > >> standard, but that is advanced magic ;-) ), but what is the
      >> problem of
      >> > >> the word 'formal'? You have X points, and the team commits to
      >> > >> satisfying all X points before presenting the result to the P-O.
      >> > >>
      >> > >> I have seen some variation of how the definition of done is taught.
      >> > >> Most CST's that I have seen thought of the definition of done as a
      >> > >> collection of quality checks, e.g. we have checked in the SW, done a
      >> > >> code review, all unit tests green, etc. Ken Schwaber (I had the
      >> honor
      >> > >> of attending his CSM course in Zürich last month) presented a
      >> template
      >> > >> defining all the tasks needed to complete a product backlog
      >> item. His
      >> > >> goal was to prevent 'undone' work:
      >> > >>
      >> > >> Developer: It's done.
      >> > >> P-O: OK, so we can release it.
      >> > >> Dev: Uh, no.
      >> > >> P-O: Why not?
      >> > >> Dev: Because we have to...
      >> > >>
      >> > >> Anything after the ellipses was undone work. As teams mature, the
      >> > >> amount of undone work after a sprint should approach zero. So
      >> you get
      >> > >> a rather long template for assuring that all PBI's are completed to
      >> > >> satisfaction.
      >> > >>
      >> > >> Cheers,
      >> > >>
      >> > >> Peter
      >> > >>
      >> > >>
      >> > >> Dan Rawsthorne wrote:
      >> > >>
      >> > >>> I love what you wrote, especially about the principles and
      >> values of
      >> > >>> scrum, but I disagree with all of your constraints :)
      >> > >>>
      >> > >>> * work committed at the beginning of a sprint must have value
      >> to the
      >> > >>> customer or user - I disagree. There are many sorts of value.
      >> > >>> Scrum is silent on which ones to use. All you know is that the PO
      >> > >>> prioritized it
      >> > >>>
      >> > >>> * work committed at the beginning of a sprint must be finished at
      >> > >>> the end of the sprint. - I disagree. There is a commitment. It is
      >> > >>> unclear what that commitment means. If there is pressure to finish
      >> > >>> nomatter what, technical debt and unsustainable pace naturally
      >> > >>> follow. So, again, what do you value?
      >> > >>>
      >> > >>> * the team must complete the work according to a formal definition
      >> > >>> of done - I nearly agree.I only disagree with the word "formal"
      >> > >>> here. I say "agreed to" definition of done
      >> > >>>
      >> > >>> The main think I know about scrum is once you get past the
      >> basics of
      >> > >>> "inspect and adapt" for both your product and process, virtually
      >> > >>> everything is malleable. That's on purpose, I think, because the
      >> > purpose
      >> > >>> is to maximize what your organization values, whatever that is.
      >> > >>>
      >> > >>> Dan Rawsthorne, PhD, CST
      >> > >>> Senior Coach, Danube Technologies
      >> > >>> dan@... <mailto:dan%40danube.com>
      >> <mailto:dan%40danube.com>, 425-269-8628
      >> > >>>
      >> > >>>
      >> > >>>
      >> > >>> Peter Stevens (cal) wrote:
      >> > >>>
      >> > >>>>
      >> > >>>>
      >> > >>>> Hi Adam,
      >> > >>>>
      >> > >>>> That's the problem with any self-reporting and lack of
      >> branding. What
      >> > >>>> the asker of a question means with the question and how the
      >> > respondent
      >> > >>>> interprets the question can be two entirely different things.
      >> > >>>>
      >> > >>>> At last year's Agile Business Conference in London, keynote
      >> speaker
      >> > >>>> Rob Thomsett defined Agile as a set of values, not as a set of
      >> > >>>> practices: Openness, Trust, Honesty, Courage and Fiscal
      >> > >>>> Responsibility. So projects using everything from Scrum to XP
      >> to DSDM
      >> > >>>> to RUP could claim to be Agile.
      >> > >>>>
      >> > >>>> I conducted a poll last summer asking the 8 questions of the Nokia
      >> > >>>> test. "Is anybody really doing Scrum
      >> > >>>>
      >> >
      >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html
      >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>
      >>
      >> >
      >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html
      >> <http://www.scrum-breakfast.com/2008/06/quick-poll-results-is-any-body-really.html>>>?"
      >> > >>>>
      >> > >>>> 3/4th of the respondents scored 7 or less. Because of the tool
      >> > used to
      >> > >>>> collect the data, I couldn't tell how many satisfied Nokia's
      >> > >>>> definition of Agile (First 3 questions). The number of
      >> > respondents was
      >> > >>>> also rather small -- 47 -- so one might question how
      >> representative
      >> > >>>> this poll was. Since then, Robin Dymond has been started a
      >> project to
      >> > >>>> get 1000 respondents to answer an extended version of the test.
      >> > Last I
      >> > >>>> heard, he had 360 respondents, so he hasn't published any results
      >> > yet.
      >> > >>>>
      >> > >>>> The speaker at last month's the Scrum Breakfast, Silvan
      >> > Mühlemann, CTO
      >> > >>>> of tilllate.com, described his company's getting started with
      >> Scrum.
      >> > >>>> When he started, he didn't believe that Scrum would work in his
      >> > >>>> company, so he changed it. Pretty dramatically. For instance, time
      >> > >>>> boxes yes, fixed length iterations no. At the beginning of his
      >> > talk, I
      >> > >>>> wondered if we could even call his process Scrum. He
      >> definitely broke
      >> > >>>> a lot of rules of Scrum. But he stayed true to inspect and adapt.
      >> > That
      >> > >>>> process brought him closer to Scrum by the book (adding
      >> > >>>> retrospectives, daily scrums, ready to try again with fixed length
      >> > >>>> iterations, etc).
      >> > >>>>
      >> > >>>> The talk was a real eye opener. If your top management gets the
      >> > >>>> principles of Scrum, the practices are less of an issue. If they
      >> > >>>> don't, well, it can be tough.
      >> > >>>>
      >> > >>>> Scrum doesn't actually specify any engineering practices. It
      >> > specifies
      >> > >>>> three constraints:
      >> > >>>>
      >> > >>>> * work committed at the beginning of a sprint must have value to
      >> > >>>> the customer or user
      >> > >>>> * work committed at the beginning of a sprint must be finished at
      >> > >>>> the end of the sprint.
      >> > >>>> * the team must complete the work according to a formal definition
      >> > >>>> of done
      >> > >>>>
      >> > >>>> These constraints drive most teams to move towards XP engineering
      >> > >>>> practices (even though there is no requirement to do so). I am not
      >> > >>>> aware of any evidence which shows that doing agile engineering
      >> leads
      >> > >>>> companies to adopt agile management practices, so Scrum is the
      >> place
      >> > >>>> to start.
      >> > >>>>
      >> > >>>> So, coming back to your original post, I think you've got the
      >> numbers
      >> > >>>> and messages you need:
      >> > >>>>
      >> > >>>> 1. > 50% of all IT projects are doing (or trying to do) agile.
      >> > >>>> 2. 84% of them do (or are trying to do) Scrum -- and this is the
      >> > >>>> place to start.
      >> > >>>> 3. Scrum is hard, so management buy in and commitment are
      >> essential.
      >> > >>>>
      >> > >>>> Now it's time for management to self organize: "How do you
      >> convince
      >> > >>>> yourselves the Scrum and Agile are worthy of serious
      >> commitment? How
      >> > >>>> do you learn to walk the walk?"
      >> > >>>>
      >> > >>>> Cheers,
      >> > >>>>
      >> > >>>> Peter
      >> > >>>>
      >> > >>>>
      >> > >>>>
      >> > >>>> Adam Sroka wrote:
      >> > >>>>
      >> > >>>>> Ken's numbers match my experience, but I wonder how many of
      >> > those 84%
      >> > >>>>> are doing some kind of Scrum-but with absolutely none of the
      >> Agile
      >> > >>>>> "engineering practices." And, of those who claim to be doing
      >> > some form
      >> > >>>>> of Agile that isn't Scrum, I wonder how many are actually doing
      >> > >>>>> anything that would remotely resemble Agile to you or I.
      >> > >>>>>
      >> > >>>>> Also, as an aside, I've noticed that nearly every job
      >> > description now
      >> > >>>>> says "Experience with agile methodologies - especially Scrum
      >> or XP -
      >> > >>>>> is desirable," or something quite similar. It makes using the job
      >> > >>>>> boards more difficult, because nine out of ten of the results for
      >> > >>>>> "agile," "XP," and "Scrum," are false positives (For my
      >> purposes.)
      >> > >>>>>
      >> > >>>>>
      >> > >>>>
      >> > >>>
      >> > >>>
      >> > >>> ------------------------------------
      >> > >>>
      >> > >>> To Post a message, send it to: scrumdevelopment@...
      >> <mailto:scrumdevelopment%40eGroups.com>
      >> > <mailto:scrumdevelopment%40eGroups.com>
      >> > >>> To Unsubscribe, send a blank message to:
      >> > >>> scrumdevelopment-unsubscribe@...
      >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>
      >> > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
      >> > >>>
      >> > >>>
      >> > >>>
      >> > >>>
      >> > >>
      >> > >>
      >> > >
      >> > >
      >> > > ------------------------------------
      >> > >
      >> > > To Post a message, send it to: scrumdevelopment@...
      >> <mailto:scrumdevelopment%40eGroups.com>
      >> > <mailto:scrumdevelopment%40eGroups.com>
      >> > > To Unsubscribe, send a blank message to:
      >> > > scrumdevelopment-unsubscribe@...
      >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>
      >> > <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
      >> > >
      >> > >
      >> > >
      >> > >
      >> >
      >> > --
      >> > Sent from my mobile device
      >> >
      >> >
      >>
      >
      >
    • Show all 22 messages in this topic