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

RE: [scrumdevelopment] design practices

Expand Messages
  • Mike Dwyer
    Let me try to catch up with this. We are asking, I think, how to take an existing system (aka ugly old un-maintainable) and make it neat, new, and manageable.
    Message 1 of 25 , Jan 3, 2005
      Let me try to catch up with this.

      We are asking, I think, how to take an existing system (aka ugly old
      un-maintainable) and make it neat, new, and manageable.

      Since we do not have any usable documentation, just a bunch of stuff the
      users of the system rely on, there is no BDUF just a pile of stuff.

      Stories, cards, can all capture what users actually 'use' the system for. A
      cool thought comes to mind in having every user story also contain a
      demonstration of what the system currently does for them.
      This way you get a discriminator between what the system does and what the
      users want it to do.

      First pass make the new neat system do what it does but in the new, neat,
      maintainable and manageable way you want to build it.

      Then add in the stuff the users want it to do.

      Why go through all of this? First you begin the life of the new neat
      version with a solid combination of FDD TDD information. And a very simple
      unforgiving test process. Since you are building a system that delivers
      exactly what the old system does, you simply need to print off all of the
      output from the old system then use the same data to print off all of the
      output from the new system and then match them up on a light table. If all
      you see is a single output then you know the system produces exactly what
      the old one did. If not then you know it does not.

      Now using that you add stuff to the new system. Once you add the stuff then
      the once new system is now the old system and so on and so on.

      Just a thought.

      Michael F. Dwyer

      Mike.Dwyer1@...



      -----Original Message-----
      From: Ron Jeffries [mailto:ronjeffries@...]
      Sent: Thursday, December 23, 2004 1:15 PM
      To: scrumdevelopment@yahoogroups.com
      Subject: Re: [scrumdevelopment] design practices


      On Thursday, December 23, 2004, at 12:38:02 PM, Steven Mak wrote:

      > hmm.... I am not sure if I can get your meaning
      > clearly (sorry for my limited English). I am not sure
      > if anything prevents us from completing an iteration.
      > But I am rather new in scrum and wondering if how
      > 'design' is dealt with, or any practices that I
      > overlooked to prevent spending the whole iteration on
      > 'design' but not delivering anything 'valuable'.

      I'm supposing that the program is made up of features, is it not?

      Then why not do what Scrum prescribes, and deliver one or more
      features /in the very first month/, and every month thereafter?

      And why not deploy those features, incrementally, one by one by one?

      What would prevent you from doing that?

      Ron Jeffries
      www.XProgramming.com
      Here is Edward Bear, coming downstairs now, bump, bump, bump, on the back
      of his head. It is, as far as he knows, the only way of coming downstairs,
      but sometimes he feels that there really is another way, if only he could
      stop bumping for a moment and think of it. And then he feels that perhaps
      there isn't. -- A. A. Milne





      To Post a message, send it to: scrumdevelopment@...
      To Unsubscribe, send a blank message to:
      scrumdevelopment-unsubscribe@...
      Yahoo! Groups Links
    • Joel
      I have never managed a re-write project before, so perhaps my answer is naive, but here goes anyway. I disagree with some other respondents. I think that you
      Message 2 of 25 , Jan 4, 2005
        I have never managed a re-write project before, so perhaps my answer
        is naive, but here goes anyway.
        I disagree with some other respondents. I think that you need to
        modify some Scrum/Agile practices because some assumptions are not
        valid in this type of project. For example, one assumption of Agile
        is that you should prioritize the functionality because lower
        priority functionality 1)might never be needed or 2)might not make
        economic sense by the time we get to it or 3) the user might just
        change their mind, (or other variations of this theme). One drawback
        of waterfall is that it treats all functionality with equal
        priority. But, in this case, all functionality may be required. The
        user may not want a replacement system unless it has ALL previous
        functionality, hence the need for prioritization assumption is no
        longer valid.
        Another assumption we frequently make is that design should be
        emergent. Writing code only for the current function is a good thing
        because re-writing isn't expensive compared to adding complexity and
        functionality that is never needed. But in the case where all
        functionality has equal priority, and the system cannot be released
        until all of the functionality is included, isn't this an inefficient
        approach?
        My guess is that this project would benefit from more up-front design
        than a new development project. And I think that I would be asking
        the team where else they can find efficiencies given the somewhat
        unique situation.

        --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...>
        wrote:
        >
        > Hi all,
        >
        > I am going to have a new project soon and I am the project manager
        of
        > the project. I want to apply scrum practices with this project. My
        > knowledge in scrum is limited to this group, some online materials,
        > and a book. Thus, hope this gives me practical experiences in how my
        > development team more 'agile'.
        >
        > The project is about re-writing a system that has been using for
        > serveral years. It's so badly written that it has to be re-written
        so
        > as to have a easier life to maintain it.
        >
        > The first query is not about 'design'. Is traditional software
        > development works better when we have deep understanding about the
        > system? (eg. re-writing a system that we have been using for
        serveral
        > years) or I would like to know how agile methologies work better in
        a
        > not-so-emergent system development.
        >
        > The scope of the system is rather board, thus I believe it would
        take
        > quite a number of iterations before its functionalities can compare
        > with the existing system.
        >
        > I am wondering, with such a large system. How infrastruture and
        > software design is done in Scrum, while not falling into the BDUF
        > problem? Suppose it's a 4-week iteration. Would 'design' and
        > 'architecutral' work takes up more time in the first few iterations
        > than the later iterations, as it gets sufficiently-built for most
        > services on top of it?
        >
        > Is there any references on recommended design practices in Scrum?
        > Thank you.
        >
        > Happy Holiday
        > Steven
      • Ron Jeffries
        ... I d wager a week s pay that for any proposed ALL previous functionality project, I can find at least one chunk of functionality that they don t really
        Message 3 of 25 , Jan 4, 2005
          On Tuesday, January 4, 2005, at 10:30:01 PM, Joel wrote:

          > The
          > user may not want a replacement system unless it has ALL previous
          > functionality, hence the need for prioritization assumption is no
          > longer valid.

          I'd wager a week's pay that for any proposed "ALL previous
          functionality" project, I can find at least one chunk of
          functionality that they don't really want. Without mentioning price.
          If I can mention price, more.

          Ron Jeffries
          www.XProgramming.com
          What is your dream? And knowing this, what have you
          done to work towards realizing it today? -- Les Brown
        • Kristan Vingrys
          I think you missed one important point about the assumption of Agile and priority, The user might want the system before it is finished . In this case it
          Message 4 of 25 , Jan 4, 2005
            I think you missed one important point about the assumption of Agile and priority, "The user might want the system before it is finished". In this case it would still be worthwhile prioritising the features to be implemented and working to that priority so if the user does come back before the system is finished they can make up there mind taking it as is knowing that the highest priority features have been implemented.
             
            With emergent design my understanding is that you should not make assumptions about features that maybe needed and design to those. In the case you are describing you know what features are required, therefore they should be considered in your design. In my opinion Agile practices do not discourage upfront design, they discourage making up features (but in the future they may want to ....).
             
            Regards,
             
            Kristan
            -----Original Message-----
            From: Joel [mailto:jadams@...]
            Sent: Wednesday, 5 January 2005 2:30 PM
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Re: design practices


            I have never managed a re-write project before, so perhaps my answer
            is naive, but here goes anyway.
            I disagree with some other respondents.  I think that you need to
            modify some Scrum/Agile practices because some assumptions are not
            valid in this type of project.  For example, one assumption of Agile
            is that you should prioritize the functionality because lower
            priority functionality 1)might never be needed or 2)might not make
            economic sense by the time we get to it or 3) the user might just
            change their mind, (or other variations of this theme).  One drawback
            of waterfall is that it treats all functionality with equal
            priority.  But, in this case, all functionality may be required.  The
            user may not want a replacement system unless it has ALL previous
            functionality, hence the need for prioritization assumption is no
            longer valid. 
            Another assumption we frequently make is that design should be
            emergent.  Writing code only for the current function is a good thing
            because re-writing isn't expensive compared to adding complexity and
            functionality that is never needed.  But in the case where all
            functionality has equal priority, and the system cannot be released
            until all of the functionality is included, isn't this an inefficient
            approach?
            My guess is that this project would benefit from more up-front design
            than a new development project.  And I think that I would be asking
            the team where else they can find efficiencies given the somewhat
            unique situation.

            --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...>
            wrote:
            >
            > Hi all,
            >
            > I am going to have a new project soon and I am the project manager
            of
            > the project. I want to apply scrum practices with this project. My
            > knowledge in scrum is limited to this group, some online materials,
            > and a book. Thus, hope this gives me practical experiences in how my
            > development team more 'agile'.
            >
            > The project is about re-writing a system that has been using for
            > serveral years. It's so badly written that it has to be re-written
            so
            > as to have a easier life to maintain it.
            >
            > The first query is not about 'design'. Is traditional software
            > development works better when we have deep understanding about the
            > system? (eg. re-writing a system that we have been using for
            serveral
            > years) or I would like to know how agile methologies work better in
            a
            > not-so-emergent system development.
            >
            > The scope of the system is rather board, thus I believe it would
            take
            > quite a number of iterations before its functionalities can compare
            > with the existing system.
            >
            > I am wondering, with such a large system. How infrastruture and
            > software design is done in Scrum, while not falling into the BDUF
            > problem? Suppose it's a 4-week iteration. Would 'design' and
            > 'architecutral' work takes up more time in the first few iterations
            > than the later iterations, as it gets sufficiently-built for most
            > services on top of it?
            >
            > Is there any references on recommended design practices in Scrum?
            > Thank you.
            >
            > Happy Holiday
            > Steven





            To Post a message, send it to:   scrumdevelopment@...
            To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...


          • woynam
            The key sentence is that all the functionality *may* be needed. I ve seen plenty of features that were never used, but they simply *had* to be there. Often,
            Message 5 of 25 , Jan 5, 2005
              The key sentence is that all the functionality *may* be needed. I've
              seen plenty of features that were never used, but they simply *had* to
              be there. Often, there's no one who can tell you why a feature is
              needed, or why it was put there in the first place.

              I would start with the highest priority features first. At some point,
              the customer may decide that there's enough functionality to deploy
              into production. Worst case scenario, you rebuild all the features,
              which is basically were you might end up if you used a waterfall
              approach.

              Good case scenario, your customer decides that they can live with a
              subset of the features, and the system gets deployed into production
              eariler. You gain important feedback as you continue developing the
              remaining requested features.

              Best case scenario, the customer decides they *don't* need the
              remaining feqatures, but would rather you work on some *new* feature
              that will benefit the business. If you had taken the waterfall
              approach, your answer may be, "Sorry, we can't do that. We're 12
              months into a 18 month rewrite, and all we have is a bunch of design
              documents. We have to code and test the system first before we can
              begin to worry about changes." :-)

              Mark

              --- In scrumdevelopment@yahoogroups.com, "Joel" <jadams@d...> wrote:
              >
              > I have never managed a re-write project before, so perhaps my
              answer
              > is naive, but here goes anyway.
              > I disagree with some other respondents. I think that you need to
              > modify some Scrum/Agile practices because some assumptions are not
              > valid in this type of project. For example, one assumption of
              Agile
              > is that you should prioritize the functionality because lower
              > priority functionality 1)might never be needed or 2)might not make
              > economic sense by the time we get to it or 3) the user might just
              > change their mind, (or other variations of this theme). One
              drawback
              > of waterfall is that it treats all functionality with equal
              > priority. But, in this case, all functionality may be required.
              The
              > user may not want a replacement system unless it has ALL previous
              > functionality, hence the need for prioritization assumption is no
              > longer valid.
              > Another assumption we frequently make is that design should be
              > emergent. Writing code only for the current function is a good
              thing
              > because re-writing isn't expensive compared to adding complexity
              and
              > functionality that is never needed. But in the case where all
              > functionality has equal priority, and the system cannot be released
              > until all of the functionality is included, isn't this an
              inefficient
              > approach?
              > My guess is that this project would benefit from more up-front
              design
              > than a new development project. And I think that I would be asking
              > the team where else they can find efficiencies given the somewhat
              > unique situation.
              >
              > --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...>
              > wrote:
              > >
              > > Hi all,
              > >
              > > I am going to have a new project soon and I am the project
              manager
              > of
              > > the project. I want to apply scrum practices with this project. My
              > > knowledge in scrum is limited to this group, some online
              materials,
              > > and a book. Thus, hope this gives me practical experiences in how
              my
              > > development team more 'agile'.
              > >
              > > The project is about re-writing a system that has been using for
              > > serveral years. It's so badly written that it has to be
              re-written
              > so
              > > as to have a easier life to maintain it.
              > >
              > > The first query is not about 'design'. Is traditional software
              > > development works better when we have deep understanding about the
              > > system? (eg. re-writing a system that we have been using for
              > serveral
              > > years) or I would like to know how agile methologies work better
              in
              > a
              > > not-so-emergent system development.
              > >
              > > The scope of the system is rather board, thus I believe it would
              > take
              > > quite a number of iterations before its functionalities can
              compare
              > > with the existing system.
              > >
              > > I am wondering, with such a large system. How infrastruture and
              > > software design is done in Scrum, while not falling into the BDUF
              > > problem? Suppose it's a 4-week iteration. Would 'design' and
              > > 'architecutral' work takes up more time in the first few
              iterations
              > > than the later iterations, as it gets sufficiently-built for most
              > > services on top of it?
              > >
              > > Is there any references on recommended design practices in Scrum?
              > > Thank you.
              > >
              > > Happy Holiday
              > > Steven
            • woynam
              Just a little background on my experience with rewrites. I ve been at my current position for 7+ years, and joined the company to work on a rewrite of our
              Message 6 of 25 , Jan 5, 2005
                'Just a little background on my experience with rewrites.

                I've been at my current position for 7+ years, and joined the company
                to work on a rewrite of our mainframe-based trading system that
                supported our open-outcry trading model.

                Less than a year into the project, the threat of fully electronic,
                screen-based trading became a reality with the announcement of the
                first new options exchange in 25 years, the ISE. We were soon directed
                to change gears and build a screen-based system.

                Shortly after completing and deploying version 1.0 of the system, the
                trading of single stock futures was authorized, and the fear was that
                a futures exchange could steal a lot of our business. Thus, we began
                developing a screen-based futures trading engine as part of a joint
                venture with 2 other exchanges. This new system was built using 90% of
                the major components of the new system.

                Shortly after completing and deploying the 2nd version of the system,
                the business decided that a hybrid trading model, combining the best
                of open-outcry and screen-based trading, would allow us to better
                compete with the fully electronic markets. Thus, we began working on a
                hybrid trading system that utilizes elements of the mainframe system,
                and well as our new trading platform. We deployed this version over a
                year ago.

                In a nutshell, the mainframe system is still there, and is used for a
                number of products that continue to trade open-outcry, as well as
                being part of the hybrid trading system. Had we focused exclusively on
                replicating the functionality of the original system, we would have
                built the wrong system, as the business did not stand still in the
                face of tough competition. Not only we some features not needed, they
                were completely eliminated with the new business model.

                By iteratively developing and deploying the system, we were able to
                deal with the unexpected course corrections that came our way.

                This is the ultimate value of agility.

                Mark


                --- In scrumdevelopment@yahoogroups.com, "woynam" <woyna@c...> wrote:
                >
                > The key sentence is that all the functionality *may* be needed. I've
                > seen plenty of features that were never used, but they simply *had* to
                > be there. Often, there's no one who can tell you why a feature is
                > needed, or why it was put there in the first place.
                >
                > I would start with the highest priority features first. At some point,
                > the customer may decide that there's enough functionality to deploy
                > into production. Worst case scenario, you rebuild all the features,
                > which is basically were you might end up if you used a waterfall
                > approach.
                >
                > Good case scenario, your customer decides that they can live with a
                > subset of the features, and the system gets deployed into production
                > eariler. You gain important feedback as you continue developing the
                > remaining requested features.
                >
                > Best case scenario, the customer decides they *don't* need the
                > remaining feqatures, but would rather you work on some *new* feature
                > that will benefit the business. If you had taken the waterfall
                > approach, your answer may be, "Sorry, we can't do that. We're 12
                > months into a 18 month rewrite, and all we have is a bunch of design
                > documents. We have to code and test the system first before we can
                > begin to worry about changes." :-)
                >
                > Mark
                >
                > --- In scrumdevelopment@yahoogroups.com, "Joel" <jadams@d...> wrote:
                > >
                > > I have never managed a re-write project before, so perhaps my
                > answer
                > > is naive, but here goes anyway.
                > > I disagree with some other respondents. I think that you need to
                > > modify some Scrum/Agile practices because some assumptions are not
                > > valid in this type of project. For example, one assumption of
                > Agile
                > > is that you should prioritize the functionality because lower
                > > priority functionality 1)might never be needed or 2)might not make
                > > economic sense by the time we get to it or 3) the user might just
                > > change their mind, (or other variations of this theme). One
                > drawback
                > > of waterfall is that it treats all functionality with equal
                > > priority. But, in this case, all functionality may be required.
                > The
                > > user may not want a replacement system unless it has ALL previous
                > > functionality, hence the need for prioritization assumption is no
                > > longer valid.
                > > Another assumption we frequently make is that design should be
                > > emergent. Writing code only for the current function is a good
                > thing
                > > because re-writing isn't expensive compared to adding complexity
                > and
                > > functionality that is never needed. But in the case where all
                > > functionality has equal priority, and the system cannot be released
                > > until all of the functionality is included, isn't this an
                > inefficient
                > > approach?
                > > My guess is that this project would benefit from more up-front
                > design
                > > than a new development project. And I think that I would be asking
                > > the team where else they can find efficiencies given the somewhat
                > > unique situation.
                > >
                > > --- In scrumdevelopment@yahoogroups.com, "Steven Mak" <tcmak@y...>
                > > wrote:
                > > >
                > > > Hi all,
                > > >
                > > > I am going to have a new project soon and I am the project
                > manager
                > > of
                > > > the project. I want to apply scrum practices with this project. My
                > > > knowledge in scrum is limited to this group, some online
                > materials,
                > > > and a book. Thus, hope this gives me practical experiences in how
                > my
                > > > development team more 'agile'.
                > > >
                > > > The project is about re-writing a system that has been using for
                > > > serveral years. It's so badly written that it has to be
                > re-written
                > > so
                > > > as to have a easier life to maintain it.
                > > >
                > > > The first query is not about 'design'. Is traditional software
                > > > development works better when we have deep understanding about the
                > > > system? (eg. re-writing a system that we have been using for
                > > serveral
                > > > years) or I would like to know how agile methologies work better
                > in
                > > a
                > > > not-so-emergent system development.
                > > >
                > > > The scope of the system is rather board, thus I believe it would
                > > take
                > > > quite a number of iterations before its functionalities can
                > compare
                > > > with the existing system.
                > > >
                > > > I am wondering, with such a large system. How infrastruture and
                > > > software design is done in Scrum, while not falling into the BDUF
                > > > problem? Suppose it's a 4-week iteration. Would 'design' and
                > > > 'architecutral' work takes up more time in the first few
                > iterations
                > > > than the later iterations, as it gets sufficiently-built for most
                > > > services on top of it?
                > > >
                > > > Is there any references on recommended design practices in Scrum?
                > > > Thank you.
                > > >
                > > > Happy Holiday
                > > > Steven
              • Steven Gordon
                Emergent design has other benefits over up-front design besides being able to handle changing/uncertain/emergent requirements: 1. Emergent designs force the
                Message 7 of 25 , Jan 5, 2005
                  Emergent design has other benefits over up-front design besides being able to handle changing/uncertain/emergent requirements:

                  1. Emergent designs force the code to be easily changable, whereas top-down holistic design can easily create code that is monolithically dependent on the current design. Even if requirements never changed, implementing the system a few requirements at a time results in a system that will be battle tested at being able to accommodate additional requirements after deployment.

                  2. Developers can learn something from the design and implementation of a few requirements that will improve the design and implementation of the remaining requirements, whereas if we design the whole thing before implementing any of it, we get no feedback on whether the overall design strategy is a good one.

                  3. We can better estimate how long it will take to complete the project from the first month of design and implementation of a few requirements from beginning to end than from just a month of pure design.

                  Steven Gordon

                  http://sf.asu.edu/




                  --- In scrumdevelopment@yahoogroups.com, "Joel" <jadams@d...> wrote:
                  > Another assumption we frequently make is that design should be
                  > emergent. Writing code only for the current function is a good
                  thing
                  > because re-writing isn't expensive compared to adding complexity
                  and
                  > functionality that is never needed. But in the case where all
                  > functionality has equal priority, and the system cannot be released
                  > until all of the functionality is included, isn't this an
                  inefficient
                  > approach?
                  > My guess is that this project would benefit from more up-front
                  design
                  > than a new development project. And I think that I would be asking
                  > the team where else they can find efficiencies given the somewhat
                  > unique situation.
                • todd
                  ... This is a bit of FUD. There s nothing in top down design that makes it any more monolithic or dependent or less changeable than any other design approach.
                  Message 8 of 25 , Jan 5, 2005
                    Steven Gordon wrote:

                    > Emergent design has other benefits over up-front design besides being
                    > able to handle changing/uncertain/emergent requirements:
                    >
                    > 1. Emergent designs force the code to be easily changable, whereas
                    > top-down holistic design can easily create code that is monolithically
                    > dependent on the current design. Even if requirements never changed,
                    > implementing the system a few requirements at a time results in a
                    > system that will be battle tested at being able to accommodate
                    > additional requirements after deployment.


                    This is a bit of FUD. There's nothing in top down design that makes it
                    any more monolithic or dependent or less changeable than any other
                    design approach. If you know how to design your code to be testable and
                    changeable then it will be. And it can be far easier to add in new
                    requirements, depending on the nature of the new requirements. If people
                    add useless over complicated code that doesn't work then that's there
                    own issue, it's not required by any design methodology that i know of.
                    Nor will any design methodology prevent someone from doing stupid stuff.
                  • Steven Gordon
                    The argument that if you know what you are doing, you can create a perfectly good software using any methodology (or even no methodology) defeats anything we
                    Message 9 of 25 , Jan 5, 2005
                      The argument that if you know what you are doing, you can create a perfectly good software using any methodology (or even no methodology) defeats anything we say here. Given the current state of software today, this is not a very realistic or productive argument.

                      It is common sense that a design that has had new requirements added to it dozens of times in a principled way can be more trusted to be able to accommodate new requirements of similar kinds than a design that has never had any new requirements added to it.

                      -----Original Message-----
                      From: todd [mailto:todd@...]
                      Sent: Wed 1/5/2005 10:53 AM
                      To: scrumdevelopment@yahoogroups.com
                      Cc:
                      Subject: Re: [scrumdevelopment] Re: design practices




                      Steven Gordon wrote:

                      > Emergent design has other benefits over up-front design besides being
                      > able to handle changing/uncertain/emergent requirements:
                      >
                      > 1. Emergent designs force the code to be easily changable, whereas
                      > top-down holistic design can easily create code that is monolithically
                      > dependent on the current design. Even if requirements never changed,
                      > implementing the system a few requirements at a time results in a
                      > system that will be battle tested at being able to accommodate
                      > additional requirements after deployment.


                      This is a bit of FUD. There's nothing in top down design that makes it
                      any more monolithic or dependent or less changeable than any other
                      design approach. If you know how to design your code to be testable and
                      changeable then it will be. And it can be far easier to add in new
                      requirements, depending on the nature of the new requirements. If people
                      add useless over complicated code that doesn't work then that's there
                      own issue, it's not required by any design methodology that i know of.
                      Nor will any design methodology prevent someone from doing stupid stuff.
                    • todd
                      ... It s productive and realistic because you can t overcome this lack by adding a methodology. So dinging one methodology in favor another isn t fair, imho.
                      Message 10 of 25 , Jan 5, 2005
                        Steven Gordon wrote:

                        > The argument that if you know what you are doing, you can create a
                        > perfectly good software using any methodology (or even no methodology)
                        > defeats anything we say here.

                        It's productive and realistic because you can't overcome this lack by
                        adding a methodology. So dinging one methodology in favor another isn't
                        fair, imho.

                        >
                        > It is common sense that a design that has had new requirements added
                        > to it dozens of times in a principled way can be more trusted to be
                        > able to accommodate new requirements of similar kinds than a design
                        > that has never had any new requirements added to it.

                        The use of the word "principled" defeats anything we say here. Given
                        the current state of software today, this is not a very realistic or
                        productive argument. :-)
                      Your message has been successfully submitted and would be delivered to recipients shortly.