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

Re: [scrumdevelopment] Application Framework and database design

Expand Messages
  • George Dinwiddie
    Bill, you ve already gotten some good advice, so I ll just concentrate on this item: ... I m not completely sure I understand your meaning, but this sounds
    Message 1 of 12 , Oct 1, 2008
    • 0 Attachment
      Bill, you've already gotten some good advice, so I'll just concentrate
      on this item:

      wfc_85283 wrote:
      > Our application incorporates 24 functional areas. It is my
      > understanding that each Sprint within the Scrum addresses a functional
      > area or a subset of the stories within a functional area.

      I'm not completely sure I understand your meaning, but this sounds
      suspiciously like a phased waterfall approach, to me. It sounds as if
      you're thinking of working module by module, working to finish each
      before proceeding to the next.

      I would suggest that you take a more holistic view, generating an entire
      application, even though it initially does little more than show that
      it's there. Having all the functional areas represented in the
      fledgling app will help the developers drive a reasonable first approach
      to the schema and architecture.

      Then start to flesh out the functions, in business priority order,
      switching between functional areas as appropriate. These will add
      elaborations to the schema and architecture, but the need to "rip out
      and redesign" should be gone.

      There's an art to seeing how your application can grow in this way.
      It's a very different point of view than envisioning building it,
      starting at one end and proceeding to the other. But working in this
      way provides a lot of benefits. One of the important ones is that you,
      the Product Owner, can see at the end of first iteration whether it
      appears that the "walking skeleton" of the application is likely to have
      the right shape to carry the full weight by the end.

      good luck,
      George

      --
      ----------------------------------------------------------------------
      * George Dinwiddie * http://blog.gdinwiddie.com
      Software Development http://www.idiacomputing.com
      Consultant and Coach http://www.agilemaryland.org
      ----------------------------------------------------------------------
    • woynam
      Yes, I understand. :-) The 2 key aspects of agility are 1) prioritize features based on business value, and 2) inspect and adapt. As Product Owner, you get to
      Message 2 of 12 , Oct 1, 2008
      • 0 Attachment
        Yes, I understand. :-)

        The 2 key aspects of agility are 1) prioritize features based on
        business value, and 2) inspect and adapt.

        As Product Owner, you get to choose the priority of the features. When
        we consider business value, we typically assume functional
        requirements. However, in many cases there may be non-functional
        requirements, e.g. maintainability, that have the highest business
        value. You certainly don't want to build a system that can't be
        maintained. It might give you some immediate value, but it will cost
        you long term.

        Thus, you should select a small set of features that really stress the
        architecture of the system. In RUP, one builds an architectural
        prototype to prove that the selected architecture will work. With
        Scrum, we don't typically build throw-away prototypes, but we can
        certainly build a small part of the actual system that highlights the
        architecture.

        By focusing on this initially, you'll get to see a portion of the
        relational schema early, and determine if it suits your long-term
        needs. If not, you can adjust, or can the project and start over.

        Of course, building only a part of the system may require that you
        leave out important business functionality initially. While one should
        always strive to build deploy-able software, it may take a few Sprints
        to build enough functionality to be useful, i.e. a release.

        Mark

        --- In scrumdevelopment@yahoogroups.com, "wfc_85283" <garvinpromo@...>
        wrote:
        >
        > > >
        > >
        > Thanks Mark. I definitely know that there are issues with the
        > outsourcing firm. It's a situation that I inherited.
        >
        > I'm just trying to refine my understanding of Scrum.
        >
      • chuckspublicprofile
        Bill, I concur with all of the previous advice. Let s hope your ScrumMaster is well trained and it would behoove you to build a strong relationship with
        Message 3 of 12 , Oct 1, 2008
        • 0 Attachment
          Bill,

          I concur with all of the previous advice.

          Let's hope your ScrumMaster is well trained and it would behoove you
          to build a strong relationship with him/her ASAP, letting them know of
          your non functional requirements (DB scheme
          flexibility/denormalization, etc -- whatever you want to call it) as
          others suggest.

          In the early object days they sometimes said "Design for Reuse" --
          many of us have realized that was way overrated and ended up creating
          a lot of wasted or never(or under) used code. I prefer the term "Mine
          for Reuse" instead, which is probably just another way of saying
          refactoring. As some of the above authors have mentioned, it might
          appear that you'll(your developers) do some refactoring (and it might
          smell like re-work) along the way -- don't let that bother you -- you
          would have to do rework in a waterfall project too, just LOTS more of
          it (esp when you consider that rework in waterfall also means re-test,
          re-acceptance, re-everything!).

          In waterfall projects, to be successful with the big design up front,
          you had to be a crystal ball expert, and we all know if you were, you
          wouldn't be in the software industry! You'd be in Vegas or on late
          night TV!

          Charles Bradley

          --- In scrumdevelopment@yahoogroups.com, George Dinwiddie <lists@...>
          wrote:
          >
          > Bill, you've already gotten some good advice, so I'll just concentrate
          > on this item:
          >
          > wfc_85283 wrote:
          > > Our application incorporates 24 functional areas. It is my
          > > understanding that each Sprint within the Scrum addresses a functional
          > > area or a subset of the stories within a functional area.
          >
          > I'm not completely sure I understand your meaning, but this sounds
          > suspiciously like a phased waterfall approach, to me. It sounds as if
          > you're thinking of working module by module, working to finish each
          > before proceeding to the next.
          >
          > I would suggest that you take a more holistic view, generating an
          entire
          > application, even though it initially does little more than show that
          > it's there. Having all the functional areas represented in the
          > fledgling app will help the developers drive a reasonable first
          approach
          > to the schema and architecture.
          >
          > Then start to flesh out the functions, in business priority order,
          > switching between functional areas as appropriate. These will add
          > elaborations to the schema and architecture, but the need to "rip out
          > and redesign" should be gone.
          >
          > There's an art to seeing how your application can grow in this way.
          > It's a very different point of view than envisioning building it,
          > starting at one end and proceeding to the other. But working in this
          > way provides a lot of benefits. One of the important ones is that you,
          > the Product Owner, can see at the end of first iteration whether it
          > appears that the "walking skeleton" of the application is likely to
          have
          > the right shape to carry the full weight by the end.
          >
          > good luck,
          > George
          >
          > --
          > ----------------------------------------------------------------------
          > * George Dinwiddie * http://blog.gdinwiddie.com
          > Software Development http://www.idiacomputing.com
          > Consultant and Coach http://www.agilemaryland.org
          > ----------------------------------------------------------------------
          >
        • Eric Deslauriers
          One of the best resources for learning Scrum IMHO, is this book:
          Message 4 of 12 , Oct 1, 2008
          • 0 Attachment
            One of the best resources for learning Scrum IMHO, is this book:


            Man, it's getting expensive. Hope they do another printing, I'm running out of copies to give out at work.

            It's got a great, cookbook approach and it's my bible for a lot of things. Yes, even better than the new MS Press book.

            Regards,
            Eric D

            On Tue, Sep 30, 2008 at 10:30 AM, wfc_85283 <garvinpromo@...> wrote:

            I'm new to Scrum so please be patient.

            Being an old waterfall guy, I'm accustomed to planning the application
            framework (common objects, inheritance structure, error processing,
            ect.) and designing the database up front.

            To add to the complexity, we are outsourcing the development. I am
            the Product Owner. The Scrum Master and the Team are outsourced and
            do not have strong industry knowledge or a good understanding of our
            day to day operations.

            Our application incorporates 24 functional areas. It is my
            understanding that each Sprint within the Scrum addresses a functional
            area or a subset of the stories within a functional area.

            It sounds to me like we are going to end up with a bunch of objects
            pieced together and a database that is not all that relational. Or as
            each new Sprint is implemented, we will need to rework other functions
            and redesign the database.

            I've got the User Stories for the first Sprint complete and the Team
            wants to get started. Are we missing a step?

            Thanks in advance for your help.

            Bill




            --
            Eric D
            08 K1200S Tricolor (phreowww)
            06 Husqvarna TE610
          • wfc_85283
            ... http://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1222923075&sr=8-2 ... running out ... things. ...
            Message 5 of 12 , Oct 2, 2008
            • 0 Attachment
              --- In scrumdevelopment@yahoogroups.com, "Eric Deslauriers"
              <eric.deslauriers@...> wrote:
              >
              > One of the best resources for learning Scrum IMHO, is this book:
              >
              http://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1222923075&sr=8-2
              >
              > http://tinyurl.com/scrumbook
              >
              > Man, it's getting expensive. Hope they do another printing, I'm
              running out
              > of copies to give out at work.
              >
              > It's got a great, cookbook approach and it's my bible for a lot of
              things.
              > Yes, even better than the new MS Press book.
              >
              > Regards,
              > Eric D
              >
              > On Tue, Sep 30, 2008 at 10:30 AM, wfc_85283 <garvinpromo@...> wrote:
              >
              > > I'm new to Scrum so please be patient.
              > >
              > > Being an old waterfall guy, I'm accustomed to planning the application
              > > framework (common objects, inheritance structure, error processing,
              > > ect.) and designing the database up front.
              > >
              > > To add to the complexity, we are outsourcing the development. I am
              > > the Product Owner. The Scrum Master and the Team are outsourced and
              > > do not have strong industry knowledge or a good understanding of our
              > > day to day operations.
              > >
              > > Our application incorporates 24 functional areas. It is my
              > > understanding that each Sprint within the Scrum addresses a functional
              > > area or a subset of the stories within a functional area.
              > >
              > > It sounds to me like we are going to end up with a bunch of objects
              > > pieced together and a database that is not all that relational. Or as
              > > each new Sprint is implemented, we will need to rework other functions
              > > and redesign the database.
              > >
              > > I've got the User Stories for the first Sprint complete and the Team
              > > wants to get started. Are we missing a step?
              > >
              > > Thanks in advance for your help.
              > >
              > > Bill
              > >
              > >
              > >
              >
              >
              >
              > --
              > Eric D
              > 08 K1200S Tricolor (phreowww)
              > 06 Husqvarna TE610
              >
              Eric. I'll get the book. Thanks.
            • chuckspublicprofile
              I ve also found this short book very useful and practical... more of a scrum implementation tips book than a learn scrum book.
              Message 6 of 12 , Oct 2, 2008
              • 0 Attachment
                I've also found this short book very useful and practical... more of a
                "scrum implementation tips" book than a "learn scrum" book.

                http://www.amazon.com/Scrum-Trenches-Enterprise-Software-Development/dp/1430322640

                Charles

                --- In scrumdevelopment@yahoogroups.com, "wfc_85283" <garvinpromo@...> > >
                > > One of the best resources for learning Scrum IMHO, is this book:
                > >
                >
                http://www.amazon.com/Agile-Software-Development-Scrum/dp/0130676349/ref=pd_bbs_sr_2?ie=UTF8&s=books&qid=1222923075&sr=8-2
                > >
                > > http://tinyurl.com/scrumbook
                > >
              • mike.dwyer1@comcast.net
                I m sure that Ken is overjoyed to hear his work referred to as a cookbook. Sent via BlackBerry by AT&T ... From: chuckspublicprofile
                Message 7 of 12 , Oct 3, 2008
                • 0 Attachment
                  I'm sure that Ken is overjoyed to hear his work referred to as a cookbook.

                  Sent via BlackBerry by AT&T


                  From: "chuckspublicprofile" <chuck-lists2@...>
                  Date: Thu, 02 Oct 2008 17:23:46 -0000
                  To: <scrumdevelopment@yahoogroups.com>
                  Subject: [scrumdevelopment] Re: Application Framework and database design

                  I've also found this short book very useful and practical... more of a
                  "scrum implementation tips" book than a "learn scrum" book.

                  http://www.amazon. com/Scrum- Trenches- Enterprise- Software- Development/ dp/1430322640

                  Charles

                  --- In scrumdevelopment@ yahoogroups. com, "wfc_85283" <garvinpromo@ ...> > >

                  > > One of the best resources for learning Scrum IMHO, is this book:
                  > >
                  >
                  http://www.amazon. com/Agile- Software- Development- Scrum/dp/ 0130676349/ ref=pd_bbs_ sr_2?ie=UTF8& s=books&qid= 1222923075& sr=8-2
                  > >
                  > > http://tinyurl. com/scrumbook
                  > >

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