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

Application Framework and database design

Expand Messages
  • wfc_85283
    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,
    Message 1 of 12 , Sep 30, 2008
    • 0 Attachment
      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
    • woynam
      Sorry to be the bearer of bad news, Bill, but I think you have bigger problems. Why on earth would an organization outsource their development to a group that
      Message 2 of 12 , Sep 30, 2008
      • 0 Attachment
        'Sorry to be the bearer of bad news, Bill, but I think you have bigger
        problems.

        Why on earth would an organization outsource their development to a
        group that does not understand your business or your organization???

        While this *may* work in some instances, you're asking for disaster. I
        had a similar experience with this a while back.

        On top of that, it sounds like you're trying a new development process
        for the first time. While an agile approach will certainly help you
        build a better product by delivering software sooner, it will never
        make up for the deficiency of an unqualified team.

        Does the team at least have a background using Scrum? If not, I'd
        suggest that you at least select an experienced Scrum team. Trying to
        incorporate a new process with an inexperienced team will rarely succeed.

        Now, to answer you question. As the Product Owner, you get to select
        the stories. If you feel that there is a particular risk, e.g.
        database not being "relational" enough, then you should select the
        stories such that they minimize the risk. For example, you could
        choose a story from each functional area, or you could select stories
        from a single area.

        In either case, you shouldn't be surprised that you'll need a bit of
        reworking. That's the nature of iterative development. The advantage,
        however, is that you'll redesign based on new data, rather than try to
        guess everything up front.

        Mark

        --- In scrumdevelopment@yahoogroups.com, "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
        >
      • wfc_85283
        ... succeed. ... 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
        Message 3 of 12 , Sep 30, 2008
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@...> wrote:
          >
          >
          > 'Sorry to be the bearer of bad news, Bill, but I think you have bigger
          > problems.
          >
          > Why on earth would an organization outsource their development to a
          > group that does not understand your business or your organization???
          >
          > While this *may* work in some instances, you're asking for disaster. I
          > had a similar experience with this a while back.
          >
          > On top of that, it sounds like you're trying a new development process
          > for the first time. While an agile approach will certainly help you
          > build a better product by delivering software sooner, it will never
          > make up for the deficiency of an unqualified team.
          >
          > Does the team at least have a background using Scrum? If not, I'd
          > suggest that you at least select an experienced Scrum team. Trying to
          > incorporate a new process with an inexperienced team will rarely
          succeed.
          >
          > Now, to answer you question. As the Product Owner, you get to select
          > the stories. If you feel that there is a particular risk, e.g.
          > database not being "relational" enough, then you should select the
          > stories such that they minimize the risk. For example, you could
          > choose a story from each functional area, or you could select stories
          > from a single area.
          >
          > In either case, you shouldn't be surprised that you'll need a bit of
          > reworking. That's the nature of iterative development. The advantage,
          > however, is that you'll redesign based on new data, rather than try to
          > guess everything up front.
          >
          > Mark
          >
          > --- In scrumdevelopment@yahoogroups.com, "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
          > >
          >
          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.
        • Cory Foy
          Hi Bill, ... We ve all been there. Literally. Well, maybe not Ken, since he would have been an old hat as soon as he designed it. But, for sure, the rest of
          Message 4 of 12 , Sep 30, 2008
          • 0 Attachment
            Hi Bill,

            wfc_85283 wrote:
            > I'm new to Scrum so please be patient.

            We've all been there. Literally. Well, maybe not Ken, since he would
            have been an old hat as soon as he designed it. But, for sure, the rest
            of us.

            > 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.

            One of the common misconceptions I see often is that a move from
            waterfallish practices to agilish practices also means going from Big
            Design Up Front (BDUF) to No Design Up Front (NDUF).

            The good thing is that it isn't true. Design up-front is encouraged -
            you don't throw away your thinking cap. What you are encouraged to do is
            do just enough architecture work. The balance can be tough to achieve
            sometimes. The easiest way to think of it comes from the Toyota System.

            Designing and cutting the dies that were used to make the cars was one
            of the most vital (and expensive) parts of the process. In the U.S., the
            manufacturers would freeze the design, and then send it to the die
            cutters. This meant that any changes after the fact would be quite
            expensive - possibly resulting in the die having to be recreated.

            However, in Toyota, the designers worked closely with the die cutters,
            who had the expertise to know which parts of the die were likely to
            change. As such, they could work somewhat in parallel so that the final
            die was completed very rapidly after the final design.

            In a similar way, you want to design the architecture so that it meets
            your needs, but stay agile enough to be able to have changes happen in
            both sides.

            > 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.

            This will be a large challenge for you. What this means is that the
            traditional communication fostered by an onsite team will be lost. There
            are a couple of things that I would highly recommend:

            - Frequent calls. They should be able to reach you any time they are
            working if they have a question - and should be encouraged to contact you.

            - Webcams - One of the best investments I've made with remote teams is
            each end having a webcam. They can call on the phone, and you all can
            stare at each other through it. It's amazing, and quite underrated, how
            much of an impact this can have

            - Daily Stand-Ups - The trick here is making sure that the team you are
            working with is highly encouraged to report failures and successes. The
            number one issue I run into with outsourced teams is a fear of reporting
            bad news, or things that are blocking them. This may be because they
            want the contract, or may be an aspect of their culture. Become very
            aware when they always say every thing is rosy.

            > 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.

            The goal of each Sprint is for the team to deliver Running, Tested
            Features (http://www.xprogramming.com/xpmag/jatRtsMetric.htm). The work
            they do is dictated by your prioritization based on the business value -
            the highest business value items should come first.

            > 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.

            It is possible that an aspect of a story in a Sprint will cause a change
            to an earlier completed feature. However, unless you were one of the
            rare success stories I've heard of with Waterfall, it's likely that you
            all still had rework that happened there.

            As far as the design and architecture - it's the responsibility of you
            and the team not to work in a silo, but be cognizant of the details of
            other stories around you. While stories should avoid being dependent on
            each other, you all should stay aware of stories that are related and
            should be completed together.

            I'd also recommend looking at the User Stories Applied book by Mike Cohn
            (http://www.mountaingoatsoftware.com/books), and the Agile Databases
            book by Scott Ambler
            (http://www.ambysoft.com/books/agileDatabaseTechniques.html)

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

            Yes. Get started. ;) You can always adjust as you go, and you can always
            ask us here for help, or advice.

            --
            Cory Foy
            http://www.cornetdesign.com
            http://www.agileflorida.com
          • 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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.