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

Scrum vs Ad Hoc methods

Expand Messages
  • Robert Henley
    I had a thought about Ken s classic diagram showing the probability of project success for Defined vs. Empirical project management methods: I think it s
    Message 1 of 3 , Jul 11, 2003
      I had a thought about Ken's classic diagram showing the probability of project success for Defined vs. Empirical project management methods: I think it's missing a crucial line. It needs a line showing the probability of success for Ad Hoc project management approaches. I am curious where one would draw it -- starting at 50% and falling off rapidly, perhaps.
       
      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. But when their waterfall methods breaks down, they fall back on ad hoc solutions (and on blaming others, but that's less to the point). So maybe if we fight adhocracy, we'll have a better chance of beating bureaurcracy as a side-effect. In the meantime, thinking about the problem of transitioning people from an ad hoc mindset to an agile one may shed light on our real problem: changing people's minds.
       
      I look forward to your thoughts on the subject.
       
      All the best,
      Robert Henley
      Software Architect & Engineer
      Java/J2EE, XML, and Web Applications
    • 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 2 of 3 , Jul 11, 2003
        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 3 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
          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.