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

Suggestions for release-intensive project

Expand Messages
  • Andreas Axelsson
    Hi all, I ve got a project which is under constant development, and my problem is that we have a lot of small releases. We have a product which is customized
    Message 1 of 5 , Aug 21 6:47 AM
    • 0 Attachment
      Hi all,

      I've got a project which is under constant development, and my problem
      is that we have a lot of small releases. We have a product which is
      customized with data and features for each client. Usually we need to
      add some new features, like specific hardware support or local legal
      complicances. The product increments for one client at a time and when
      one client's features have been added they are available for all
      others to pick from.

      So, in short, we get a number of stories for the next client, put
      those together and then deploy. This can happen more than once a week,
      thus several times per iteration. And sometimes we need the same
      features for more than one client, making it hard to track which
      features are really needed for each deployment.

      Tracking each deployment as a release has become rather messy, and I'm
      beginning to think we should collect all clients in batches and make
      each iteration target a number of clients' needs. As the iteration is
      then over we know that we can deploy to A, B and C. The next iteration
      can deploy a new build to A and the first for D and E.

      What do you think? Does anyone have any experiences with similar setups?

      Cheers,
      Andreas
    • Keith Sader
      That sounds reasonable, have you also tried going to shorter sprint lengths? That might focus the product owners on what s essential for a particular release.
      Message 2 of 5 , Aug 21 7:03 AM
      • 0 Attachment
        That sounds reasonable, have you also tried going to shorter sprint lengths?  That might focus the product owners on what's essential for a particular release.


        On 8/21/07, Andreas Axelsson <andreas.axelsson@...> wrote:

        Hi all,

        I've got a project which is under constant development, and my problem
        is that we have a lot of small releases. We have a product which is
        customized with data and features for each client. Usually we need to
        add some new features, like specific hardware support or local legal
        complicances. The product increments for one client at a time and when
        one client's features have been added they are available for all
        others to pick from.

        So, in short, we get a number of stories for the next client, put
        those together and then deploy. This can happen more than once a week,
        thus several times per iteration. And sometimes we need the same
        features for more than one client, making it hard to track which
        features are really needed for each deployment.

        Tracking each deployment as a release has become rather messy, and I'm
        beginning to think we should collect all clients in batches and make
        each iteration target a number of clients' needs. As the iteration is
        then over we know that we can deploy to A, B and C. The next iteration
        can deploy a new build to A and the first for D and E.

        What do you think? Does anyone have any experiences with similar setups?

        Cheers,
        Andreas




        --
        Keith Sader
        ksader@...
        http://www.sader-family.org/roller/page/ksader
      • Alexey Krivitsky
        Hi Andreas. I don t have real experience with such a setup. You might refer to Jeff Sutherland s description of his process at PatientKeeper. They seem to be
        Message 3 of 5 , Aug 21 7:20 AM
        • 0 Attachment
          Hi Andreas.

          I don't have real experience with such a setup.
          You might refer to Jeff Sutherland's description of his process at PatientKeeper.
          They seem to be leaders in solving such complex stuff.

          Below are my thoughts to your problem.

          Your strategy will depend on your goal. A reasonable (ultimate) goal would be probably to deliver
          each sprint's result to all clients in order to shorten the return of investments cycle.

          In reality though this can be hard to achieve, especially if your team is new to agile practices.
          Refactoring, unit-testing, automation acceptance testing most likely should be put in place
          before this would be possible.

          But your idea sounds like a good start!

          An important point here would be to maintain a single product backlog (PB) listing all clients' features,
          sprint breakdown and sprint goals. Keep all the plans and progress visible to the team so they can adjust.

          And don't forget the golden Scrum rule to leave the final decisions on how to achieve the goals to the team.

          // Alexey

          On 8/21/07, Andreas Axelsson <andreas.axelsson@...> wrote:

          Hi all,

          I've got a project which is under constant development, and my problem
          is that we have a lot of small releases. We have a product which is
          customized with data and features for each client. Usually we need to
          add some new features, like specific hardware support or local legal
          complicances. The product increments for one client at a time and when
          one client's features have been added they are available for all
          others to pick from.

          So, in short, we get a number of stories for the next client, put
          those together and then deploy. This can happen more than once a week,
          thus several times per iteration. And sometimes we need the same
          features for more than one client, making it hard to track which
          features are really needed for each deployment.

          Tracking each deployment as a release has become rather messy, and I'm
          beginning to think we should collect all clients in batches and make
          each iteration target a number of clients' needs. As the iteration is
          then over we know that we can deploy to A, B and C. The next iteration
          can deploy a new build to A and the first for D and E.

          What do you think? Does anyone have any experiences with similar setups?

          Cheers,
          Andreas


        • Wolfgang Schulze Zachau
          Hi Andreas, we have an ongoing project for internal software, that covers 11 desktop applications and 2 services, all from the same codebase. We release a
          Message 4 of 5 , Aug 21 8:01 AM
          • 0 Attachment
            Hi Andreas,
             
            we have an ongoing project for internal software, that covers 11 desktop applications and 2 services, all from the same codebase. We release a subset of applications and/or services every 2 weeks (to internal customers). So in essence we are not to different from your situation.
            Our PO always tries to combine features that make sense together and we then target a small number of apps for each sprint. Our sprints are 2 weeks long. I would think that customers that can't wait for two weeks probably have some other problem, but I would definitely argue against releases during the sprint (unless you are a very experienced agilist and the team also has lots of experience). Releases on the fly require complete coverage of all code with unit tests and fully automated tests. If you don't have that, you can get yourself very quickly into a serious mess.
            Situations like this require a fully dedicated Product Owner, who needs to spend most of his time figuring out which things must go on top of the list and how they can be combined for maximum efficiency.
            I presume you have all your code and tests in a version control system. That should aid the tracking of releases.
             
             

            Regards,

            Wolfgang

             


            From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of Andreas Axelsson
            Sent: 21 August 2007 14:48
            To: scrumdevelopment@yahoogroups.com
            Subject: [scrumdevelopment] Suggestions for release-intensive project

            Hi all,

            I've got a project which is under constant development, and my problem
            is that we have a lot of small releases. We have a product which is
            customized with data and features for each client. Usually we need to
            add some new features, like specific hardware support or local legal
            complicances. The product increments for one client at a time and when
            one client's features have been added they are available for all
            others to pick from.

            So, in short, we get a number of stories for the next client, put
            those together and then deploy. This can happen more than once a week,
            thus several times per iteration. And sometimes we need the same
            features for more than one client, making it hard to track which
            features are really needed for each deployment.

            Tracking each deployment as a release has become rather messy, and I'm
            beginning to think we should collect all clients in batches and make
            each iteration target a number of clients' needs. As the iteration is
            then over we know that we can deploy to A, B and C. The next iteration
            can deploy a new build to A and the first for D and E.

            What do you think? Does anyone have any experiences with similar setups?

            Cheers,
            Andreas

          • Andreas Axelsson
            Thanks for your suggestions! It looks like we re on the right track and I ve suggested to the team and management the approach of only releasing properly
            Message 5 of 5 , Aug 22 11:48 PM
            • 0 Attachment
              Thanks for your suggestions! It looks like we're on the right track
              and I've suggested to the team and management the approach of only
              releasing properly assembled builds by the end of the iteration,
              regardless of when each deployment may be feature complete. We're
              running on two weeks and shorter would probably bee too short. We'll
              inform the PO of our thinkings next week when he visits as well.

              (And in two weeks I'm off to attend Mike Cohn's Agile Estimating and
              Planning course in Stockholm. That'll be interesting for sure!)

              Cheers,
              /Andreas
            Your message has been successfully submitted and would be delivered to recipients shortly.