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

RE: [scrumdevelopment] Scrum vs Ad Hoc methods

Expand Messages
  • Ken Schwaber
    I ll back Bryan on this one. When we implement Scrum without the proper engineering practices being started up, we risk having iterative hacking. It s true
    Message 1 of 3 , Jul 11, 2003
      I'll back Bryan on this one. When we implement Scrum without the proper
      engineering practices being started up, we risk having iterative hacking.
      It's true that we get to inspect every thirty days, but the people
      inspecting have to know what to inspect. I think we should emphasize the
      engineering evaluation as part of being a ScrumMaster. The output of every
      Sprint is an increment of potentially shippable product functionality. We
      should take on ensuring that it is truly shippable. Whenever it isn't, the
      corrective work gets rolled over to the next Sprint, along with some new
      product backlog to investigate and implement corrective engineering

      A tip off is the Sprint Backlog. The two administrative responsibilities for
      a Scrum team are the Daily Scrum and the Sprint Backlog. The Sprint Backlog
      is their planning mechanism where the team lays out the Sprint tasks. If the
      team never lays out the tasks, then it doesn't need the Sprint Backlog. If
      the team never thinks through what it is going to do and just starts
      hacking, it certainly doesn't need it. So, to me, the presence of the Sprint
      Backlog comforts me that the team has at least put thought into their work.


      -----Original Message-----
      From: Bryan Zarnett [mailto:bzarnett@...]
      Sent: Friday, July 11, 2003 8:42 AM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] Scrum vs Ad Hoc methods

      On Friday, July 11, 2003, at 07:59AM, Robert Henley <rhenley@...>

      >It seems to me that our biggest foes (and thus greatest potential market)
      are not the users of >heavyweight methodologies, but the users of ad hoc
      methods. The heavyweight method users at least >appreciate that you need a

      I think our biggest foe is not "ad hoc" methodologies but individuals who
      believe that their approach is not "ad hoc" (even though it is), and believe
      that is the only way for development to proceed.

      In a company where I brought in XP (a long time ago in the DOT-COM era), we
      had sme nice success coming in under time and budget while keeping a 1 hour
      Quake game time, and leading by 5, and not starting till 9 or 9:30. It was
      a nice group of people, of various levels of experience -- everyone had good
      ethics though and where fun to be with. After our success another
      individual commented that it was a fluke and cited his years of experience
      where "bugs, delays, etc." where "just how it was"

      In many circumstances, the process is not the issue but the foundation of
      the developers -- often there is none. There basics and attitude are so poor
      that they can not, and do not understand how to do there work properly. If
      we say you need to do test-first development; how do we expect them to do
      this when they can't write basic code or understand the fundamentals of good
      design in a project.

      Given the current percentage of good programmers to poor programmers, our
      biggest issue is lack of skill which leads to poor practices being
      implemented. One Sr. Technical Guru I know on a project does not believe in
      documentation or coding conventions, so the projects have none. That is the
      practice - he also has never written any code other than some Cobol (not
      dishing the Cobol people).

      I think lack of proper education is our biggest foe.

      Sorry for the rant. I still need my morning coffee.

      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:

      Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
    Your message has been successfully submitted and would be delivered to recipients shortly.