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

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

Expand Messages
  • Michael Vizdos
    ... and remember you are dealing with people who *love* splitting hairs. Me... I just use comic strips as an outlet... and working with teams to deliver
    Message 1 of 22 , Aug 1 11:49 AM
    • 0 Attachment
      ... and remember you are dealing with people who *love* splitting hairs.

      Me... I just use comic strips as an outlet... and working with teams
      to deliver working software around the world :).

      Thank you,

      - Mike Vizdos
      Vizdos Enterprises, LLC

      Contact Information

      Phone: (262) MVIZDOS / (262) 684-9367
      Web: www.implementingscrum.com
      www.michaelvizdos.com
      AOL IM: MikeV Work
      Twitter: www.twitter.com/mvizdos
      Skype: mvizdos

      PS: Come to one of my workshops. Visit michaelvizdos.com/enroll.

      PPS: Visit implementingscrum.com/subscribe. Receive 2 FREE videos.





      On Sat, Aug 1, 2009 at 6:39 AM, Peter Stevens (cal)<peterstev@...> 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@..., 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>> 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>, 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>, 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>>?"
      >> >>>>
      >> >>>> 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>
      >> >>> To Unsubscribe, send a blank message to:
      >> >>> scrumdevelopment-unsubscribe@...
      >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
      >> >>>
      >> >>>
      >> >>>
      >> >>>
      >> >>
      >> >>
      >> >
      >> >
      >> > ------------------------------------
      >> >
      >> > To Post a message, send it to: scrumdevelopment@...
      >> <mailto:scrumdevelopment%40eGroups.com>
      >> > To Unsubscribe, send a blank message to:
      >> > scrumdevelopment-unsubscribe@...
      >> <mailto:scrumdevelopment-unsubscribe%40eGroups.comYahoo>! Groups Links
      >> >
      >> >
      >> >
      >> >
      >>
      >> --
      >> Sent from my mobile device
      >>
      >>
      >
      >
    Your message has been successfully submitted and would be delivered to recipients shortly.