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

Re: To SCRUM or not

Expand Messages
  • urpenguin
    The article: http://www.australianit.news.com.au/story/0,24897,22667903- 24170,00.html I think for organizations that are resistant to Agile methods you ll
    Message 1 of 8 , Nov 2, 2007
      The article:

      http://www.australianit.news.com.au/story/0,24897,22667903-
      24170,00.html

      I think for organizations that are resistant to Agile methods you'll
      have to find a way to reframe Agile. What is the value of the method
      and how can you inject the value of Scrum into daily practice, not as
      Scrum officially but as a set of good practices (standups, continuous
      delivery, ...)? People who believe that sequential linear processes
      are what they must have refuse to believe anything else is possible.

      Dan



      --- In scrumdevelopment@yahoogroups.com, Roy Morien <roymorien@...>
      wrote:
      >
      > You may be interested in an article in The Australian newspaper IT
      section of October 16th, 2007, entitled "Changing course to dry up
      the waterfall model".
      >
      > The story is about the adoption of agile methods by "Five years as
      the head of IT at some of Australia's largest businesses has given
      Suncorp CIO Jeff Smith a reputation ..."
      >
      > "Mr Smith urged businesses to consider dumping the dominant
      waterfall system of project management which relies on heavy-duty
      governance structures , linear phases and gating".
      >
      > "You know why we do the sign-offs at the end of each phase? It adds
      no value and it was put in place to fail. The reason we do sign-offs
      is so we can b;ame someone later on, when something fails".
      >
      > The article is in this vein. Unfortunately it does not seem to be
      available to be read online.
      >
      > Regards,
      > Roy Morien
      >
      >
      > To: scrumdevelopment@...: banibrata.dutta@...: Tue, 30 Oct 2007
      19:37:12 +0530Subject: Re: [scrumdevelopment] To SCRUM or not
      >
      >
      >
      >
      >
      > My issue with Scrum is not a fight against management (thankfully),
      but against ignorance and limited knowledge and experience with usage
      of "pure" Scrum within the team itself :-) ! I am more of less sold
      on the benefits of Scrum, but I've been hearing few PoV's on "all or
      nothing" approaches to Scrum, which have led me to think that
      Scrum'ming with partial knowledge of the same, may mess more things
      than it may sort.
      >
      >
      > What you wrote appears quite appealing and an interesting
      suggestion, -- a middle path (apparently), setting the way for pure
      Scrum eventually. Also that link about IID & mini-waterfall was very
      helpful.
      >
      > - bani
      > On 10/30/07, Martin Jul - Ative <mj@...> wrote:
      >
      >
      >
      >
      >
      > Banibrata,Even if you don't want to change entirely to Scrum I
      would at least take a few of the practises:First, I would introduce
      iterative development driven by business value - implement the most
      business-valuable features first, and deliver production-ready,
      running, tested software in small increments, say bi-weekly. Since
      you are on a tight deadline this takes a lot of the risk out of the
      project - or rather, moves the risk to the lowest-value features
      rather than any feature. Also, even if management does not think
      there will be much change my experience is that they get inspired at
      the demos of working software and see all the missing features and
      the features in the spec that are not really needed. Inside an
      iteration make sure that you are not doing a mini-waterfall (see my
      post Iterative Development Gone Wrong about the Mini-Waterfall
      http://community.ative.dk/blogs/ative/archive/2007/03/18/Iterative-
      Development-Gone-Wrong-_2D00_-The-Mini_2D00_Waterfall-
      Anti_2D00_Pattern.aspx). Rather, try to teach people to complete the
      application feature-by-feature. Using a daily stand-up meeting to
      talk project and a status indicator such as a burndown chart is
      really useful, too. If you are used to estimating in hours you can
      use this - you don't need to learn user stories to get benefit. Just
      track the total estimated-time-remaining for the tasks in the
      iteration every day and you will have good visibility into you
      status. Also, if you have to deliver frequently you will see all the
      impediments in your organisation - so even if you don't call your
      project manager a Scrum Master, listen to the team and try to help
      the team work around the dysfunctions of the organisation - or change
      it for the better if possible. I realize the above has most of Scrum
      in it, albeit with other wording, so I guess it is kind of a Trojan
      Horse approach to implementing Scrum - or at read it as an advice to
      get the "frequent delivery of valuable business functionality" cycle
      going and then take it from there. Best
      regards,Martin________________________________________Martin Jul,
      partner A|T|I|V|E|www.ative.dk <http://www.ative.dk/> | mj@...
      <mailto:mj@...> | +45 21 63 34 72|Lav bedre software hurtigere!Vær
      med på http://community.ative.dk/blogs/
      <http://community.ative.dk/blogs/> ________________________________
      Fra: scrumdevelopment@yahoogroups.com på vegne af Banibrata
      DuttaSendt: ti 30-10-2007 11:01 Til: scrumdevelopment@...:
      [scrumdevelopment] To SCRUM or not
      > Hi,I've been following this group's posts for a while, and also
      have read some bit of material on Scrum etc., however, in everyother
      way, my experience with Scrum is "theoretical". Given a situation
      description, I'd request the practitioners and experts to kindly
      comment, if Scrum would be appropriate in the given situation or not.
      1) Product in question (objective of development), as we understand
      it currently, has 15% UI/presentation, 70% application (business)
      logic, 15% support utilities/tools.2) Development team is a mix of
      people with varying skill-sets and expertise. Some actually are
      fairly good already, and some need some (infrequent) hand-holding.
      Team though is a lot more comfortable with waterfall model. 3) No one
      with real Scrum experience (no purists), however, people have some
      exposure to Scrum-like methodologies. There is no certified Scrum
      master, and most of all, no budget to hire an expert to tutor / hand-
      hold this team (or Scrum master). 4) Development schedule is quite
      tight. 5) 75% of product requirements are known upfront (right now).
      Only 25% is expected to evolve / change in next 3-4 months. Real-
      customer (external) doesn't care about Agility, and doesn't need to /
      expect-to see snapshots periodically (well they'd be happy to see
      monthly or every-other-monthly milestone based progress). However,
      considering our management as an internal customer, they'd like to
      see more frequent milestones being met. To me, it looks like
      something with which Scrum would be too much of a risk (at the
      moment), and might be simpler to stick to waterfall. Comments and
      suggestions are more than welcome.thanks & regards, Banibrata
      >
      >
      >
      >
      >
      >
      >
      >
      >
      > _________________________________________________________________
      > It's simple! Sell your car for just $30 at CarPoint.com.au
      > http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%
      2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%
      5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT
      >
    • Roy Morien
      Thanks Dan. :) To: scrumdevelopment@yahoogroups.comFrom: dsw@juno.comDate: Fri, 2 Nov 2007 11:39:41 +0000Subject: [scrumdevelopment] Re: To SCRUM or not The
      Message 2 of 8 , Nov 2, 2007
        Thanks Dan. :)




        To: scrumdevelopment@yahoogroups.com
        From: dsw@...
        Date: Fri, 2 Nov 2007 11:39:41 +0000
        Subject: [scrumdevelopment] Re: To SCRUM or not

        The article:

        http://www.australi anit.news. com.au/story/ 0,24897,22667903 -
        24170,00.html

        I think for organizations that are resistant to Agile methods you'll
        have to find a way to reframe Agile. What is the value of the method
        and how can you inject the value of Scrum into daily practice, not as
        Scrum officially but as a set of good practices (standups, continuous
        delivery, ...)? People who believe that sequential linear processes
        are what they must have refuse to believe anything else is possible.

        Dan

        --- In scrumdevelopment@ yahoogroups. com, Roy Morien <roymorien@. ..>
        wrote:
        >
        > You may be interested in an article in The Australian newspaper IT
        section of October 16th, 2007, entitled "Changing course to dry up
        the waterfall model".
        >
        > The story is about the adoption of agile methods by "Five years as
        the head of IT at some of Australia's largest businesses has given
        Suncorp CIO Jeff Smith a reputation ..."
        >
        > "Mr Smith urged businesses to consider dumping the dominant
        waterfall system of project management which relies on heavy-duty
        governance structures , linear phases and gating".
        >
        > "You know why we do the sign-offs at the end of each phase? It adds
        no value and it was put in place to fail. The reason we do sign-offs
        is so we can b;ame someone later on, when something fails".
        >
        > The article is in this vein. Unfortunately it does not seem to be
        available to be read online.
        >
        > Regards,
        > Roy Morien
        >
        >
        > To: scrumdevelopment@ ...: banibrata.dutta@ ...: Tue, 30 Oct 2007
        19:37:12 +0530Subject: Re: [scrumdevelopment] To SCRUM or not
        >
        >
        >
        >
        >
        > My issue with Scrum is not a fight against management (thankfully) ,
        but against ignorance and limited knowledge and experience with usage
        of "pure" Scrum within the team itself :-) ! I am more of less sold
        on the benefits of Scrum, but I've been hearing few PoV's on "all or
        nothing" approaches to Scrum, which have led me to think that
        Scrum'ming with partial knowledge of the same, may mess more things
        than it may sort.
        >
        >
        > What you wrote appears quite appealing and an interesting
        suggestion, -- a middle path (apparently) , setting the way for pure
        Scrum eventually. Also that link about IID & mini-waterfall was very
        helpful.
        >
        > - bani
        > On 10/30/07, Martin Jul - Ative <mj@...> wrote:
        >
        >
        >
        >
        >
        > Banibrata,Even if you don't want to change entirely to Scrum I
        would at least take a few of the practises:First, I would introduce
        iterative development driven by business value - implement the most
        business-valuable features first, and deliver production-ready,
        running, tested software in small increments, say bi-weekly. Since
        you are on a tight deadline this takes a lot of the risk out of the
        project - or rather, moves the risk to the lowest-value features
        rather than any feature. Also, even if management does not think
        there will be much change my experience is that they get inspired at
        the demos of working software and see all the missing features and
        the features in the spec that are not really needed. Inside an
        iteration make sure that you are not doing a mini-waterfall (see my
        post Iterative Development Gone Wrong about the Mini-Waterfall
        http://community. ative.dk/ blogs/ative/ archive/2007/ 03/18/Iterative-
        Development- Gone-Wrong- _2D00_-The- Mini_2D00_ Waterfall-
        Anti_2D00_Pattern. aspx). Rather, try to teach people to complete the
        application feature-by-feature. Using a daily stand-up meeting to
        talk project and a status indicator such as a burndown chart is
        really useful, too. If you are used to estimating in hours you can
        use this - you don't need to learn user stories to get benefit. Just
        track the total estimated-time- remaining for the tasks in the
        iteration every day and you will have good visibility into you
        status. Also, if you have to deliver frequently you will see all the
        impediments in your organisation - so even if you don't call your
        project manager a Scrum Master, listen to the team and try to help
        the team work around the dysfunctions of the organisation - or change
        it for the better if possible. I realize the above has most of Scrum
        in it, albeit with other wording, so I guess it is kind of a Trojan
        Horse approach to implementing Scrum - or at read it as an advice to
        get the "frequent delivery of valuable business functionality" cycle
        going and then take it from there. Best
        regards,Martin_ _________ _________ _________ _________ ___Martin Jul,
        partner A|T|I|V|E|www. ative.dk <http://www.ative. dk/> | mj@...
        <mailto:mj@. ..> | +45 21 63 34 72|Lav bedre software hurtigere!Vær
        med på http://community. ative.dk/ blogs/
        <http://community. ative.dk/ blogs/> ____________ _________ _________ __
        Fra: scrumdevelopment@ yahoogroups. com på vegne af Banibrata
        DuttaSendt: ti 30-10-2007 11:01 Til: scrumdevelopment@ ...:
        [scrumdevelopment] To SCRUM or not
        > Hi,I've been following this group's posts for a while, and also
        have read some bit of material on Scrum etc., however, in everyother
        way, my experience with Scrum is "theoretical" . Given a situation
        description, I'd request the practitioners and experts to kindly
        comment, if Scrum would be appropriate in the given situation or not.
        1) Product in question (objective of development) , as we understand
        it currently, has 15% UI/presentation, 70% application (business)
        logic, 15% support utilities/tools. 2) Development team is a mix of
        people with varying skill-sets and expertise. Some actually are
        fairly good already, and some need some (infrequent) hand-holding.
        Team though is a lot more comfortable with waterfall model. 3) No one
        with real Scrum experience (no purists), however, people have some
        exposure to Scrum-like methodologies. There is no certified Scrum
        master, and most of all, no budget to hire an expert to tutor / hand-
        hold this team (or Scrum master). 4) Development schedule is quite
        tight. 5) 75% of product requirements are known upfront (right now).
        Only 25% is expected to evolve / change in next 3-4 months. Real-
        customer (external) doesn't care about Agility, and doesn't need to /
        expect-to see snapshots periodically (well they'd be happy to see
        monthly or every-other- monthly milestone based progress). However,
        considering our management as an internal customer, they'd like to
        see more frequent milestones being met. To me, it looks like
        something with which Scrum would be too much of a risk (at the
        moment), and might be simpler to stick to waterfall. Comments and
        suggestions are more than welcome.thanks & regards, Banibrata
        >
        >
        >
        >
        >
        >
        >
        >
        >
        > ____________ _________ _________ _________ _________ _________ _
        > It's simple! Sell your car for just $30 at CarPoint.com. au
        > http://a.ninemsn. com.au/b. aspx?URL= http%3A%2F% 2Fsecure% 2Dau%
        2Eimrworldwide% 2Ecom%2Fcgi% 2Dbin%2Fa% 2Fci%5F450304% 2Fet%5F2% 2Fcg%
        5F801459%2Fpi% 5F1004813% 2Fai%5F859641& _t=762955845& _r=tig_OCT07& _m=EXT
        >




        Check our comprehensive Salary Centre Overpaid or Underpaid?
      • Roy Morien
        I supervised nearly 60 student industrial experience projects during 2003 - 2004. I insisted on the student project groups doing these projects in an iterative
        Message 3 of 8 , Nov 2, 2007
          I supervised nearly 60 student industrial experience projects during 2003 - 2004. I insisted on the student project groups doing these projects in an iterative fashion, at least. Whether they could really be said to be doing it in an agile manner is another matter, given that they had no clue whatever about what agile development meant.  My thoughts on the outcome of these projects were variously published, but perhaps the most complete is in the paper that was published in the IS Education Journal in 2005 (which I have attached for those who may be interested in reading it).

          I started with a cohort of students who had no information whatever about agile development, iterative development, Scrum. In fact, they had been inculcated in the waterfall approach, with heavy emphasis on documentation as the measure of project success (and academic success). I met even overt hostility at the start, and significant disbelief that the iterative approach, without full up-front analysis activity, was even viable, practical, allowable etc.
           
          However, even just requiring the students to get started and actually deliver small components of their system, able to be demonstrated to their client, very quickly caught their attention. They quickly realised that there were many beneficial outcomes. A happy client who could see progress almost immediately, greater confidence in themselves as being abe to deliver useable software quickly, greater satisfaction at seeing the client's delighted response etc etc.

          And this came about from very humble beginnings of using an iterative approach. There were no daily stand up meetings. The students had no idea about user stories. It was all very informal and not in accordance with any known agile approach; except iterative development, with real, useable results very early in the project activity. The niceties of Scrum or DSDM etc. would hopefully follow.

          Perhaps, Banibrata, you could follow this approach to get started. Softly, softly. Small successes building into bigger successes.
           
          Regards,
          Roy Morien

          To: scrumdevelopment@yahoogroups.com
          From: mj@...
          Date: Tue, 30 Oct 2007 11:59:21 +0000
          Subject: SV: [scrumdevelopment] To SCRUM or not

          Banibrata,
           
           
          Even if you don't want to change entirely to Scrum I would at least take a few of the practises:
           
          First, I would introduce iterative development driven by business value - implement the most business-valuable features first, and deliver production-ready, running, tested software in small increments, say bi-weekly. Since you are on a tight deadline this takes a lot of the risk out of the project - or rather, moves the risk to the lowest-value features rather than any feature.
           
          Also, even if management does not think there will be much change my experience is that they get inspired at the demos of working software and see all the missing features and the features in the spec that are not really needed.
           
          Inside an iteration make sure that you are not doing a mini-waterfall (see my post Iterative Development Gone Wrong about the Mini-Waterfall http://community.ative.dk/blogs/ative/archive/2007/03/18/Iterative-Development-Gone-Wrong-_2D00_-The-Mini_2D00_Waterfall-Anti_2D00_Pattern.aspx). Rather, try to teach people to complete the application feature-by-feature.
           
          Using a daily stand-up meeting to talk project and a status indicator such as a burndown chart is really useful, too. If you are used to estimating in hours you can use this - you don't need to learn user stories to get benefit. Just track the total estimated-time-remaining for the tasks in the iteration every day and you will have good visibility into you status.
           
          Also, if you have to deliver frequently you will see all the impediments in your organisation - so even if you don't call your project manager a Scrum Master, listen to the team and try to help the team work around the dysfunctions of the organisation - or change it for the better if possible.
           
          I realize the above has most of Scrum in it, albeit with other wording, so I guess it is kind of a Trojan Horse approach to implementing Scrum - or at read it as an advice to get the "frequent delivery of valuable business functionality" cycle going and then take it from there.
           
           
          Best regards,
          Martin
           
           
           
          ________________________________________
          Martin Jul, partner                        A|T|I|V|E|
          www.ative.dk | mj@... | +45 21 63 34 72|
           
          Lav bedre software hurtigere!
           


          Fra: scrumdevelopment@yahoogroups.com på vegne af Banibrata Dutta
          Sendt: ti 30-10-2007 11:01
          Til: scrumdevelopment@yahoogroups.com
          Emne: [scrumdevelopment] To SCRUM or not

          Hi,
           
          I've been following this group's posts for a while, and also have read some bit of material on Scrum etc., however, in everyother way, my experience with Scrum is "theoretical". Given a situation description, I'd request the practitioners and experts to kindly comment, if Scrum would be appropriate in the given situation or not.
           
          1) Product in question (objective of development) , as we understand it currently, has 15% UI/presentation, 70% application (business) logic, 15% support utilities/tools.
          2) Development team is a mix of people with varying skill-sets and expertise. Some actually are fairly good already, and some need some (infrequent) hand-holding. Team though is a lot more comfortable with waterfall model.
          3) No one with real Scrum experience (no purists), however, people have some exposure to Scrum-like methodologies. There is no certified Scrum master, and most of all, no budget to hire an expert to tutor / hand-hold this team (or Scrum master).
          4) Development schedule is quite tight.
          5) 75% of product requirements are known upfront (right now). Only 25% is expected to evolve / change in next 3-4 months. Real-customer (external) doesn't care about Agility, and doesn't need to / expect-to see snapshots periodically (well they'd be happy to see monthly or every-other- monthly milestone based progress). However, considering our management as an internal customer, they'd like to see more frequent milestones being met.
           
          To me, it looks like something with which Scrum would be too much of a risk (at the moment), and might be simpler to stick to waterfall. Comments and suggestions are more than welcome.
           
          thanks & regards,
          Banibrata
           
           




          Join Lavalife for free. What are you waiting for?
        • Peter Hundermark
          ... value - implement the most business-valuable features first, and deliver production-ready, running, tested software in small increments, say bi-weekly.
          Message 4 of 8 , Nov 4, 2007
            --- In scrumdevelopment@yahoogroups.com, "Martin Jul - Ative" <mj@...>
            wrote:
            >
            > Banibrata,
            >
            >
            > Even if you don't want to change entirely to Scrum I would at least
            take a few of the practises:
            >
            > First, I would introduce iterative development driven by business
            value - implement the most business-valuable features first, and deliver
            production-ready, running, tested software in small increments, say
            bi-weekly. Since you are on a tight deadline this takes a lot of the
            risk out of the project - or rather, moves the risk to the lowest-value
            features rather than any feature.
            >
            > Also, even if management does not think there will be much change my
            experience is that they get inspired at the demos of working software
            and see all the missing features and the features in the spec that are
            not really needed.
            >
            > Inside an iteration make sure that you are not doing a mini-waterfall
            (see my post Iterative Development Gone Wrong about the Mini-Waterfall
            http://community.ative.dk/blogs/ative/archive/2007/03/18/Iterative-Devel\
            opment-Gone-Wrong-_2D00_-The-Mini_2D00_Waterfall-Anti_2D00_Pattern.aspx)\
            . Rather, try to teach people to complete the application
            feature-by-feature.
            >
            > Using a daily stand-up meeting to talk project and a status indicator
            such as a burndown chart is really useful, too. If you are used to
            estimating in hours you can use this - you don't need to learn user
            stories to get benefit. Just track the total estimated-time-remaining
            for the tasks in the iteration every day and you will have good
            visibility into you status.
            >
            > Also, if you have to deliver frequently you will see all the
            impediments in your organisation - so even if you don't call your
            project manager a Scrum Master, listen to the team and try to help the
            team work around the dysfunctions of the organisation - or change it for
            the better if possible.
            >
            > I realize the above has most of Scrum in it, albeit with other
            wording, so I guess it is kind of a Trojan Horse approach to
            implementing Scrum - or at read it as an advice to get the "frequent
            delivery of valuable business functionality" cycle going and then take
            it from there.
            >


            Martin,

            I find your description appealing, yet for me there are some gaps that
            need filling:

            1. You refer to prioritising feature development by business value. In
            the absence of a formal sprint planning session, how does the team get
            to know what to do?

            2. You refer to delivering production-ready software bi-weekly
            [fortnightly?]. In the absence of a formal review, to whom are these
            shown or delivered and how does the team know that they are, indeed,
            shippable?

            3. You mention the team seeing the impediments in the organisation. In
            the absence of a formal retrospective, when and how does the team expose
            these or examine and improve its process?

            4. You mention listening to the team and trying to help them. Who does
            this? What (Scrum) skills does she need to do this?

            I'm always curious to learn more about managing people's fear of change.

            -ph
          Your message has been successfully submitted and would be delivered to recipients shortly.