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

Re: [scrumdevelopment] Scrum vs Ad Hoc methods

Expand Messages
  • Bryan Zarnett
    ... 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
    Message 1 of 3 , Jul 11 5:42 AM
      On Friday, July 11, 2003, at 07:59AM, Robert Henley <rhenley@...> wrote:

      >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 method.

      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.
    • 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 2 of 3 , Jul 11 6:29 AM
        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
        practices.

        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.

        Ken

        -----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@...>
        wrote:

        >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
        method.

        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:
        scrumdevelopment-unsubscribe@...

        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.