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

Re: [agile-usability] Agile promote early and continuous delivery

Expand Messages
  • alanmehio
    Ron, Yes agreed . So we need to fragment the pieces into small bites and be more creative. So in reality , the project division and internal management is
    Message 1 of 10 , Aug 27, 2008
    • 0 Attachment
      Ron,
      Yes agreed . So we need to fragment the pieces into small bites and be more
      creative. So in reality , the project division and internal management is
      actually hidden from the top managers who see the coarse grain of the
      project tasks etc..


      The top managers will see a final product delivered before the deadline.


      Ron Jeffries wrote:
      >
      > Hello, alanmehio. On Tuesday, August 26, 2008, at 10:23:45 AM, you
      > wrote:
      >
      >> We all know from the Agile Manifesto which mentiond "Agile promote early
      >> and
      >> continuous delivery". I may sound repeating the same quesiontions which
      >> may
      >> be being discussed before; however, how canwe manage to make early
      >> delivery for a software product and at the same time it has to be a
      >> valuable
      >> software for the busniess and at the same time the software product
      >> consists
      >> of sub-modules which are interdependent; besides that each module require
      >> a
      >> time scale more then two months to deliver in a team of 5 developers.
      >
      > Incremental and iterative development. Your final assumption, by the
      > way, appears to me to be mistaken: it is always possible to break
      > down any desired feature or features set into small bites.
      >
      > Ron Jeffries
      > www.XProgramming.com
      > A man hears what he wants to hear, and disregards the rest. -- Paul Simon
      >
      >
      >

      --
      View this message in context: http://www.nabble.com/Agile-promote-early-and-continuous-delivery-tp19163079p19187535.html
      Sent from the Agile Usability mailing list archive at Nabble.com.
    • alanmehio
      George, You mentioned The way that seems best is to develop by feature rather than by module I see your point, however, in my last project when I try to
      Message 2 of 10 , Aug 27, 2008
      • 0 Attachment
        George,
        You mentioned "The way that seems best is to develop by feature rather
        than by module"

        I see your point, however, in my last project when I try to follow Agile
        approach, I was hindred by the module idea like logging module, transaction
        module and monitor module which works accross the application ( aspect). I
        was aware of the project features( business requirements), however, to
        implement one requirement I needed to build some generic module to help
        reuse the code.
        I think the tricky part is to always break things into smaller pieces and
        make a delivery for the small piece and at the same time the system works as
        in production status with a new pieces assembled piece by piece on a weekly
        basis.

        My question is always "How we can manage to develop generic classes and
        utilities which does not contribute directly to the features they delay
        the continous delivery".


        Alan



        George Dinwiddie wrote:
        >
        > alanmehio wrote:
        >> Dear All,
        >> We all know from the Agile Manifesto which mentiond "Agile promote early
        >> and
        >> continuous delivery". I may sound repeating the same quesiontions which
        >> may
        >> be being discussed before; however, how canwe manage to make early
        >> delivery for a software product and at the same time it has to be a
        >> valuable
        >> software for the busniess and at the same time the software product
        >> consists
        >> of sub-modules which are interdependent; besides that each module require
        >> a
        >> time scale more then two months to deliver in a team of 5 developers.
        >
        > Hi, Alan,
        >
        > Why does the software product consist of interdependent sub-modules?
        > Was that decision made prior to starting development?
        >
        > It sounds to me like that decision is what's at odds with early delivery
        > of valuable software. I would take another look at it for other
        > alternatives. The way that seems best is to develop by feature rather
        > than by module. Indeed, even the features can be started as something
        > rather rudimentary with additional value added over time.
        >
        > - George
        >
        > --
        > ----------------------------------------------------------------------
        > * George Dinwiddie * http://blog.gdinwiddie.com
        > Software Development http://www.idiacomputing.com
        > Consultant and Coach http://www.agilemaryland.org
        > ----------------------------------------------------------------------
        >
        >
        >

        --
        View this message in context: http://www.nabble.com/Agile-promote-early-and-continuous-delivery-tp19163079p19188734.html
        Sent from the Agile Usability mailing list archive at Nabble.com.
      • alanmehio
        Yes I see your point. So we should focus on delivering valued features iteratively and continuously; for example if I have a business requirement which has a
        Message 3 of 10 , Aug 27, 2008
        • 0 Attachment
          Yes I see your point. So we should focus on delivering valued features
          iteratively and continuously;
          for example if I have a business requirement which has a set of feature
          {A,B,C,D} then I take A
          and break it into small pieces like A= a,b,c,d,e
          Then I deliver sub-feature "a" into the system so that the system is a
          production system with only sub-feature "a" added in a periond of time=T
          where T can be one week or less.

          I will try to summarize all the ideas in on go later.

          Alan



          mhpries wrote:
          >
          > Agree with George.
          >
          > If you are working in agile fashion, then you are defining complete
          > functional paths through the application based on business priority.
          >
          > For example, take a vendor who sells and leases equipment. The full
          > application has to let them calculate payment streams, verify and
          > either automatically approve customer credit or kick it out for
          > credit manager review, then print legal documents for signing and
          > book the signed deal into the backend system.
          >
          > That's a lot of dependencies but suppose the most important thing the
          > user needs to start with is the ability to calculate payments for the
          > two most common types of sales or leases and generate related
          > documents. You develop that much and the users can immediately have
          > something of value.
          >
          >
          > --- In agile-usability@yahoogroups.com, George Dinwiddie <lists@...>
          > wrote:
          >>
          > stuff deleted
          >
          >> Hi, Alan,
          >>
          >> Why does the software product consist of interdependent sub-
          > modules?
          >> Was that decision made prior to starting development?
          >>
          >> It sounds to me like that decision is what's at odds with early
          > delivery
          >> of valuable software. I would take another look at it for other
          >> alternatives. The way that seems best is to develop by feature
          > rather
          >> than by module. Indeed, even the features can be started as
          > something
          >> rather rudimentary with additional value added over time.
          >>
          >> - George
          >>
          >> --
          >> ------------------------------------------------------------------
          > ----
          >> * George Dinwiddie *
          > http://blog.gdinwiddie.com
          >> Software Development
          > http://www.idiacomputing.com
          >> Consultant and Coach
          > http://www.agilemaryland.org
          >> ------------------------------------------------------------------
          > ----
          >>
          >
          >
          >
          >

          --
          View this message in context: http://www.nabble.com/Agile-promote-early-and-continuous-delivery-tp19163079p19188863.html
          Sent from the Agile Usability mailing list archive at Nabble.com.
        • dgery2000
          I d add http://alistair.cockburn.us/index.php/Knowledge_acquisition_v._business_value_creation Géry
          Message 4 of 10 , Aug 29, 2008
          • 0 Attachment
            I'd add
            http://alistair.cockburn.us/index.php/Knowledge_acquisition_v._business_value_creation

            Géry

            --- In agile-usability@yahoogroups.com, "aacockburn" <acockburn@...>
            wrote:
            >
            > --- In agile-usability@yahoogroups.com, alanmehio <alan_mehio@>
            > wrote:
            > >
            > >
            > > We all know from the Agile Manifesto which mentiond
            > > "Agile promote early and> continuous delivery". I may sound
            > > repeating the same quesiontions which may
            > > be being discussed before; however, how canwe manage to
            > > make early delivery for a software product and at the same
            > > time it has to be a valuable software for the busniess and
            > > at the same time the software product consists
            > > of sub-modules which are interdependent; besides
            > > that each module require a time scale more then two months to
            > > deliver in a team of 5 developers.
            > >
            >
            > I refer you to the article on walking skeleton
            > (watch out for line breaks in the URLs)
            >
            > http://alistair.cockburn.us/index.php/Walking_skeleton
            >
            > also
            >
            > http://alistair.cockburn.us/index.php/Extending_an_architecture_as_it_
            > earns_business_value
            >
            > also
            >
            > http://alistair.cockburn.us/images/Advancedpmstrategies1-180.ppt
            >
          • George Dinwiddie
            Alan, I rarely build generic pieces to put together, any more. Instead, I build a non-generic do-what-needs-to-be-done piece (perhaps with an eye to that
            Message 5 of 10 , Aug 29, 2008
            • 0 Attachment
              Alan,

              I rarely build generic pieces to put together, any more. Instead, I
              build a non-generic do-what-needs-to-be-done piece (perhaps with an eye
              to that generic piece I might have done). Then, when I need the second
              use, I extract the commonality out of the first into a more generic piece.

              Extracting frameworks seems to work a lot better than building them. I
              get earlier functionality, and the framework easily supports the needs
              of the client code.

              - George

              alanmehio wrote:
              > George,
              > You mentioned "The way that seems best is to develop by feature rather
              > than by module"
              >
              > I see your point, however, in my last project when I try to follow Agile
              > approach, I was hindred by the module idea like logging module, transaction
              > module and monitor module which works accross the application ( aspect). I
              > was aware of the project features( business requirements), however, to
              > implement one requirement I needed to build some generic module to help
              > reuse the code.
              > I think the tricky part is to always break things into smaller pieces and
              > make a delivery for the small piece and at the same time the system works as
              > in production status with a new pieces assembled piece by piece on a weekly
              > basis.
              >
              > My question is always "How we can manage to develop generic classes and
              > utilities which does not contribute directly to the features they delay
              > the continous delivery".
              >
              >
              > Alan
              >
              >
              >
              > George Dinwiddie wrote:
              >> alanmehio wrote:
              >>> Dear All,
              >>> We all know from the Agile Manifesto which mentiond "Agile promote early
              >>> and
              >>> continuous delivery". I may sound repeating the same quesiontions which
              >>> may
              >>> be being discussed before; however, how canwe manage to make early
              >>> delivery for a software product and at the same time it has to be a
              >>> valuable
              >>> software for the busniess and at the same time the software product
              >>> consists
              >>> of sub-modules which are interdependent; besides that each module require
              >>> a
              >>> time scale more then two months to deliver in a team of 5 developers.
              >> Hi, Alan,
              >>
              >> Why does the software product consist of interdependent sub-modules?
              >> Was that decision made prior to starting development?
              >>
              >> It sounds to me like that decision is what's at odds with early delivery
              >> of valuable software. I would take another look at it for other
              >> alternatives. The way that seems best is to develop by feature rather
              >> than by module. Indeed, even the features can be started as something
              >> rather rudimentary with additional value added over time.

              --
              ----------------------------------------------------------------------
              * George Dinwiddie * http://blog.gdinwiddie.com
              Software Development http://www.idiacomputing.com
              Consultant and Coach http://www.agilemaryland.org
              ----------------------------------------------------------------------
            Your message has been successfully submitted and would be delivered to recipients shortly.