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

RE: [scrumdevelopment] Application Framework and database design

Expand Messages
  • Roy Morien
    Well, my view is that, if you have some User Stories already, you can immediately get going on development (including stipulating appropriate relational
    Message 1 of 12 , Sep 30, 2008
    • 0 Attachment
      Well, my view is that, if you have some User Stories already, you can immediately get going on development (including stipulating appropriate 'relational' structures), and at the same time you can start planning future iterations and releases.
       
      I am always interested especially in why people felt (and still find) it necessary and desirable to develop the database schema fully up-front. I woild also be interested in knowing why you have changed your position on this. As long ago as 1992 I published  
      an approach that I called Focal Entity Prototyping. Focal as in focusing on one entity (or relationship) and moving that through a development cycle of Entity Definition -> Table Definition -> Table Construction -> Data Form Construction (& reports and queries) and deliver that system component immediately. I have found this approach simple, effective and fast (and apparently rather puzzling to many practitioners and students alike).
       
      It is interesting, from my experience in teaching at university level, that students are always so keen to rush ahead with defining the database schema on paper, and usually without the benefit of an entity modelling activity first. They seem so loath to do this vertical slicing and actually develop some working software. I find students to be great 'lab rats' who seem to find any and every way to defy good practice ... a bit like a slightly extreme example of development in industry :)
       
      So ... grasp the nettle, as they say, and start delivering ... or insist on the outsourced developers to start delivering NOW!!
       
      Regards,
      Roy Morien





      To: scrumdevelopment@yahoogroups.com
      From: garvinpromo@...
      Date: Tue, 30 Sep 2008 17:30:02 +0000
      Subject: [scrumdevelopment] Application Framework and database design


      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




    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.