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

Re: [scrumdevelopment] To SCRUM or not

Expand Messages
  • Banibrata Dutta
    My issue with Scrum is not a fight against management (thankfully), but against ignorance and limited knowledge and experience with usage of pure Scrum
    Message 1 of 8 , Oct 30, 2007
    • 0 Attachment
      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 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





    • Ryan Cooper
      I have to agree that the best thing you can do to minimize risk is to begin delivering iteratively, with the most important features first. When you re on a
      Message 2 of 8 , Nov 1, 2007
      • 0 Attachment
        I have to agree that the best thing you can do to minimize risk is to
        begin delivering iteratively, with the most important features first.

        When you're on a tight schedule, pretending you can eliminate the risk
        of missing the deadline through sheer willpower can be deadly. It can
        lull you into not making sure you get the most important stuff done,
        since you "know" you'll get it all done in time. I'm not suggesting
        this is what you're doing, but I've seen a lot of teams do this
        without realizing it.

        It's better to recognize and accept the chance that the team won't the
        deadline, and then do what you can to minimize the *cost* if that
        happens. The best way I know of to do that is to deliver
        (production-ready) the most crucial features first, before starting
        work on the less important ones.

        The other suggestions are also all good ones; but if you want to
        minimize the changes you're making to your process mid-project, this
        is the one change I would go ahead with at the very least.

        Cheers,
        Ryan



        On Oct 30, 2007 11:07 AM, Banibrata Dutta <banibrata.dutta@...> wrote:
        >
        >
        > 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 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
        > >
        > >
        > >
        > >
        > >
        > >
        > >
        >
        >
      • Roy Morien
        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
        Message 3 of 8 , Nov 2, 2007
        • 0 Attachment
          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@yahoogroups.com
          From: banibrata.dutta@...
          Date: Tue, 30 Oct 2007 19:37:12 +0530
          Subject: 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 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










          Sell your car for just $30 at CarPoint.com.au. It's simple!
        • 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 4 of 8 , Nov 2, 2007
          • 0 Attachment
            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 5 of 8 , Nov 2, 2007
            • 0 Attachment
              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 6 of 8 , Nov 2, 2007
              • 0 Attachment
                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 7 of 8 , Nov 4, 2007
                • 0 Attachment
                  --- 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.