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

Helping enterprise software customers become more agile!

Expand Messages
  • Joe
    Background info - you can skip to the problem part if you only have a short attention span as I do :) 3+ years ago, a project was given to my team to put a new
    Message 1 of 7 , Oct 27, 2011
    • 0 Attachment
      Background info - you can skip to the problem part if you only have a short attention span as I do :)

      3+ years ago, a project was given to my team to put a new user interface on a legacy product. The team asked me to use an XP agile approach so we read James Shore's Art of Agile Development book and started on a journey. The effort has been a success and I was asked to lead development for the whole legacy product (6 cross-functional teams of 5 to 7 people). Through the efforts we've seen increased quality and increased value in terms of new features. The initial customers that we worked with were happy to take frequent upgrades. Initially we released every two weeks. Through pressure from others in my organization, we've moved to releasing every other iteration but that is much better than every 6 months. Until recently our more risk averse customers avoided the new approach and product like the plague. These customers would come to us every 3 to 4 years to target one of our 6 month releases for an upgrade and then would have to work with us for months after the release to get patches to fix issues before they could go to production. Recently, they've become very interested in upgrades because they've seen the flow of value in the product. The product is critical to them in that problems can cause legal issues and/or seriously effect revenue if there are problems. Each customer has thousands of users essentially world-wide.


      The problem:

      Thus the crux of the problem - customers are used to getting major software upgrades from vendors and having problems so they've built huge processes around the upgrades.

      I've done some research and found very old threads from Brad Appleton and Kent Beck

      Brad Appleton stated:
      This relates to a different thread on non-agile environments
      for deployment (installation/upgrade and administration).
      And this in turn can make it hard for some agile shops
      to be agile when they can't do "small releases" because
      their customer won't take frequent releases due to fear
      of interruption of business processes and related systems.

      http://tech.groups.yahoo.com/group/extremeprogramming/message/101060

      Also, Kent Beck started a similar thread:
      http://tech.groups.yahoo.com/group/extremeprogramming/message/103366


      Its been over 6 years since those threads. Are there companies that help large Fortune 500 companies become more agile in upgrades? I'd envision setting up automated deployment processes, automated testing around areas of use, etc. Many of our customers use 30+ person QE staffs to manually hammer through 20,000+ tests cases for each upgrade. I ask because I am pushing our organization to stop the patching/back-porting madness and instead work more closely with our customers on upgrades. I'm getting lots of push back because our customers don't want lots of upgrades. I'd love to go to the customers with a plan/approach that would help them simplify and speed up the upgrade process. I envision this as a continuous integration/automation approach.
    • Curtis Cooley
      I would think that if your releases are production ready, as an XP team should, with no bugs, then let your customers continue with their old upgrade process.
      Message 2 of 7 , Oct 27, 2011
      • 0 Attachment
        I would think that if your releases are production ready, as an XP team
        should, with no bugs, then let your customers continue with their old
        upgrade process. When they see that what they now get is production ready
        software, they'll want to cut the cost of long upgrade processes.

        When they come to you for an upgrade, give them the latest release. If they
        later want a "patch" then use a patch tool to create a patch between the
        release they have and the current release and give it to them.

        I don't think you can force a customer to trust that the quality has
        improved so much that they can change their deployment process. You have to
        prove it to them by providing bug free software and letting them lead the
        charge to reducing the high cost of high ceremony release processes.

        It's like the Adapter Pattern. The external customer doesn't see any process
        change except now the software is production ready. Internally you've
        completely changed the process to be Agile.

        On Thu, Oct 27, 2011 at 3:33 AM, Joe <joeutz@...> wrote:

        > **
        >
        >
        > Background info - you can skip to the problem part if you only have a short
        > attention span as I do :)
        >
        > 3+ years ago, a project was given to my team to put a new user interface on
        > a legacy product. The team asked me to use an XP agile approach so we read
        > James Shore's Art of Agile Development book and started on a journey. The
        > effort has been a success and I was asked to lead development for the whole
        > legacy product (6 cross-functional teams of 5 to 7 people). Through the
        > efforts we've seen increased quality and increased value in terms of new
        > features. The initial customers that we worked with were happy to take
        > frequent upgrades. Initially we released every two weeks. Through pressure
        > from others in my organization, we've moved to releasing every other
        > iteration but that is much better than every 6 months. Until recently our
        > more risk averse customers avoided the new approach and product like the
        > plague. These customers would come to us every 3 to 4 years to target one of
        > our 6 month releases for an upgrade and then would have to work with us for
        > months after the release to get patches to fix issues before they could go
        > to production. Recently, they've become very interested in upgrades because
        > they've seen the flow of value in the product. The product is critical to
        > them in that problems can cause legal issues and/or seriously effect revenue
        > if there are problems. Each customer has thousands of users essentially
        > world-wide.
        >
        > The problem:
        >
        > Thus the crux of the problem - customers are used to getting major software
        > upgrades from vendors and having problems so they've built huge processes
        > around the upgrades.
        >
        > I've done some research and found very old threads from Brad Appleton and
        > Kent Beck
        >
        > Brad Appleton stated:
        > This relates to a different thread on non-agile environments
        > for deployment (installation/upgrade and administration).
        > And this in turn can make it hard for some agile shops
        > to be agile when they can't do "small releases" because
        > their customer won't take frequent releases due to fear
        > of interruption of business processes and related systems.
        >
        > http://tech.groups.yahoo.com/group/extremeprogramming/message/101060
        >
        > Also, Kent Beck started a similar thread:
        > http://tech.groups.yahoo.com/group/extremeprogramming/message/103366
        >
        > Its been over 6 years since those threads. Are there companies that help
        > large Fortune 500 companies become more agile in upgrades? I'd envision
        > setting up automated deployment processes, automated testing around areas of
        > use, etc. Many of our customers use 30+ person QE staffs to manually hammer
        > through 20,000+ tests cases for each upgrade. I ask because I am pushing our
        > organization to stop the patching/back-porting madness and instead work more
        > closely with our customers on upgrades. I'm getting lots of push back
        > because our customers don't want lots of upgrades. I'd love to go to the
        > customers with a plan/approach that would help them simplify and speed up
        > the upgrade process. I envision this as a continuous integration/automation
        > approach.
        >
        >
        >



        --
        Curtis Cooley
        curtis.cooley@...
        blog:http://ponderingobjectorienteddesign.blogspot.com
        ===============
        Leadership is a potent combination of strategy and character. But if you
        must be without one, be without the strategy.
        -- H. Norman Schwarzkopf


        [Non-text portions of this message have been removed]
      • Joe
        I agree with that although I m not always patient enough for it to play out. The customers are starting to notice that upgrades are smoother and I ve even got
        Message 3 of 7 , Oct 27, 2011
        • 0 Attachment
          I agree with that although I'm not always patient enough for it to play out. The customers are starting to notice that upgrades are smoother and I've even got some customers starting to discuss and consider upgrades on a much more regular basis. As they want to cut costs, I'd like to be able to point them to examples (or articles) that have taken upgrades for large enterprise application to a close to continuous deploy model.

          I've thought about how we could help but I've got a team building a product and we're not really experienced at bringing change management to large enterprise IT shops.

          Lacking much experience in this, my plan was to partner with a customer to analyze their approach and determine requirements. In other words, I'd treat it just as I'd treat any other product requirement/story. I believe that this would work for the customers that are willing to cross the chasm. For the ones that are tied to their long processes, I'll probably just have to wait until they hear that a solution exists to their cost and nimbleness problem.

          In the long-term, much of this will hopefully be moot as companies become more willing to adopt cloud based solutions but we aren't there yet.


          --- In extremeprogramming@yahoogroups.com, Curtis Cooley <curtis.cooley@...> wrote:
          >
          > I would think that if your releases are production ready, as an XP team
          > should, with no bugs, then let your customers continue with their old
          > upgrade process. When they see that what they now get is production ready
          > software, they'll want to cut the cost of long upgrade processes.
          >
          > When they come to you for an upgrade, give them the latest release. If they
          > later want a "patch" then use a patch tool to create a patch between the
          > release they have and the current release and give it to them.
          >
          > I don't think you can force a customer to trust that the quality has
          > improved so much that they can change their deployment process. You have to
          > prove it to them by providing bug free software and letting them lead the
          > charge to reducing the high cost of high ceremony release processes.
          >
          > It's like the Adapter Pattern. The external customer doesn't see any process
          > change except now the software is production ready. Internally you've
          > completely changed the process to be Agile.
          >
          > On Thu, Oct 27, 2011 at 3:33 AM, Joe <joeutz@...> wrote:
          >
          > > **
          > >
          > >
          > > Background info - you can skip to the problem part if you only have a short
          > > attention span as I do :)
          > >
          > > 3+ years ago, a project was given to my team to put a new user interface on
          > > a legacy product. The team asked me to use an XP agile approach so we read
          > > James Shore's Art of Agile Development book and started on a journey. The
          > > effort has been a success and I was asked to lead development for the whole
          > > legacy product (6 cross-functional teams of 5 to 7 people). Through the
          > > efforts we've seen increased quality and increased value in terms of new
          > > features. The initial customers that we worked with were happy to take
          > > frequent upgrades. Initially we released every two weeks. Through pressure
          > > from others in my organization, we've moved to releasing every other
          > > iteration but that is much better than every 6 months. Until recently our
          > > more risk averse customers avoided the new approach and product like the
          > > plague. These customers would come to us every 3 to 4 years to target one of
          > > our 6 month releases for an upgrade and then would have to work with us for
          > > months after the release to get patches to fix issues before they could go
          > > to production. Recently, they've become very interested in upgrades because
          > > they've seen the flow of value in the product. The product is critical to
          > > them in that problems can cause legal issues and/or seriously effect revenue
          > > if there are problems. Each customer has thousands of users essentially
          > > world-wide.
          > >
          > > The problem:
          > >
          > > Thus the crux of the problem - customers are used to getting major software
          > > upgrades from vendors and having problems so they've built huge processes
          > > around the upgrades.
          > >
          > > I've done some research and found very old threads from Brad Appleton and
          > > Kent Beck
          > >
          > > Brad Appleton stated:
          > > This relates to a different thread on non-agile environments
          > > for deployment (installation/upgrade and administration).
          > > And this in turn can make it hard for some agile shops
          > > to be agile when they can't do "small releases" because
          > > their customer won't take frequent releases due to fear
          > > of interruption of business processes and related systems.
          > >
          > > http://tech.groups.yahoo.com/group/extremeprogramming/message/101060
          > >
          > > Also, Kent Beck started a similar thread:
          > > http://tech.groups.yahoo.com/group/extremeprogramming/message/103366
          > >
          > > Its been over 6 years since those threads. Are there companies that help
          > > large Fortune 500 companies become more agile in upgrades? I'd envision
          > > setting up automated deployment processes, automated testing around areas of
          > > use, etc. Many of our customers use 30+ person QE staffs to manually hammer
          > > through 20,000+ tests cases for each upgrade. I ask because I am pushing our
          > > organization to stop the patching/back-porting madness and instead work more
          > > closely with our customers on upgrades. I'm getting lots of push back
          > > because our customers don't want lots of upgrades. I'd love to go to the
          > > customers with a plan/approach that would help them simplify and speed up
          > > the upgrade process. I envision this as a continuous integration/automation
          > > approach.
          > >
          > >
          > >
          >
          >
          >
          > --
          > Curtis Cooley
          > curtis.cooley@...
          > blog:http://ponderingobjectorienteddesign.blogspot.com
          > ===============
          > Leadership is a potent combination of strategy and character. But if you
          > must be without one, be without the strategy.
          > -- H. Norman Schwarzkopf
          >
          >
          > [Non-text portions of this message have been removed]
          >
        • marty.nelson
          Hey Joe - It s not just a matter of development process and technical quality (though those are certainly required). You ve got to treat upgrading as a feature
          Message 4 of 7 , Oct 28, 2011
          • 0 Attachment
            Hey Joe -

            It's not just a matter of development process and technical quality (though those are certainly required). You've got to treat upgrading as a feature and figure out the right architectures and (usually IT) user facing artifacts to support more frequent upgrades.

            You've got to help them come up with a story around upgrading your software that allows them to appear rational and diligent to the rest of their company.

            Architectures might include being able to update in a modular fashion only updated components to help reduce re-validation surface area. It could mean providing web apps instead of desktop clients to reduce perception of changes to large numbers of machines.

            In short, work with customers to figure out why (on an emotional level) they are doing the re-validation, and figure out a way to provide the same levels of comfort.

            - Marty

            --- In extremeprogramming@yahoogroups.com, "Joe" <joeutz@...> wrote:
            >
            > I agree with that although I'm not always patient enough for it to play out. The customers are starting to notice that upgrades are smoother and I've even got some customers starting to discuss and consider upgrades on a much more regular basis. As they want to cut costs, I'd like to be able to point them to examples (or articles) that have taken upgrades for large enterprise application to a close to continuous deploy model.
            >
            > I've thought about how we could help but I've got a team building a product and we're not really experienced at bringing change management to large enterprise IT shops.
            >
            > Lacking much experience in this, my plan was to partner with a customer to analyze their approach and determine requirements. In other words, I'd treat it just as I'd treat any other product requirement/story. I believe that this would work for the customers that are willing to cross the chasm. For the ones that are tied to their long processes, I'll probably just have to wait until they hear that a solution exists to their cost and nimbleness problem.
            >
            > In the long-term, much of this will hopefully be moot as companies become more willing to adopt cloud based solutions but we aren't there yet.
            >
            >
            > --- In extremeprogramming@yahoogroups.com, Curtis Cooley <curtis.cooley@> wrote:
            > >
            > > I would think that if your releases are production ready, as an XP team
            > > should, with no bugs, then let your customers continue with their old
            > > upgrade process. When they see that what they now get is production ready
            > > software, they'll want to cut the cost of long upgrade processes.
            > >
            > > When they come to you for an upgrade, give them the latest release. If they
            > > later want a "patch" then use a patch tool to create a patch between the
            > > release they have and the current release and give it to them.
            > >
            > > I don't think you can force a customer to trust that the quality has
            > > improved so much that they can change their deployment process. You have to
            > > prove it to them by providing bug free software and letting them lead the
            > > charge to reducing the high cost of high ceremony release processes.
            > >
            > > It's like the Adapter Pattern. The external customer doesn't see any process
            > > change except now the software is production ready. Internally you've
            > > completely changed the process to be Agile.
            > >
            > > On Thu, Oct 27, 2011 at 3:33 AM, Joe <joeutz@> wrote:
            > >
            > > > **
            > > >
            > > >
            > > > Background info - you can skip to the problem part if you only have a short
            > > > attention span as I do :)
            > > >
            > > > 3+ years ago, a project was given to my team to put a new user interface on
            > > > a legacy product. The team asked me to use an XP agile approach so we read
            > > > James Shore's Art of Agile Development book and started on a journey. The
            > > > effort has been a success and I was asked to lead development for the whole
            > > > legacy product (6 cross-functional teams of 5 to 7 people). Through the
            > > > efforts we've seen increased quality and increased value in terms of new
            > > > features. The initial customers that we worked with were happy to take
            > > > frequent upgrades. Initially we released every two weeks. Through pressure
            > > > from others in my organization, we've moved to releasing every other
            > > > iteration but that is much better than every 6 months. Until recently our
            > > > more risk averse customers avoided the new approach and product like the
            > > > plague. These customers would come to us every 3 to 4 years to target one of
            > > > our 6 month releases for an upgrade and then would have to work with us for
            > > > months after the release to get patches to fix issues before they could go
            > > > to production. Recently, they've become very interested in upgrades because
            > > > they've seen the flow of value in the product. The product is critical to
            > > > them in that problems can cause legal issues and/or seriously effect revenue
            > > > if there are problems. Each customer has thousands of users essentially
            > > > world-wide.
            > > >
            > > > The problem:
            > > >
            > > > Thus the crux of the problem - customers are used to getting major software
            > > > upgrades from vendors and having problems so they've built huge processes
            > > > around the upgrades.
            > > >
            > > > I've done some research and found very old threads from Brad Appleton and
            > > > Kent Beck
            > > >
            > > > Brad Appleton stated:
            > > > This relates to a different thread on non-agile environments
            > > > for deployment (installation/upgrade and administration).
            > > > And this in turn can make it hard for some agile shops
            > > > to be agile when they can't do "small releases" because
            > > > their customer won't take frequent releases due to fear
            > > > of interruption of business processes and related systems.
            > > >
            > > > http://tech.groups.yahoo.com/group/extremeprogramming/message/101060
            > > >
            > > > Also, Kent Beck started a similar thread:
            > > > http://tech.groups.yahoo.com/group/extremeprogramming/message/103366
            > > >
            > > > Its been over 6 years since those threads. Are there companies that help
            > > > large Fortune 500 companies become more agile in upgrades? I'd envision
            > > > setting up automated deployment processes, automated testing around areas of
            > > > use, etc. Many of our customers use 30+ person QE staffs to manually hammer
            > > > through 20,000+ tests cases for each upgrade. I ask because I am pushing our
            > > > organization to stop the patching/back-porting madness and instead work more
            > > > closely with our customers on upgrades. I'm getting lots of push back
            > > > because our customers don't want lots of upgrades. I'd love to go to the
            > > > customers with a plan/approach that would help them simplify and speed up
            > > > the upgrade process. I envision this as a continuous integration/automation
            > > > approach.
            > > >
            > > >
            > > >
            > >
            > >
            > >
            > > --
            > > Curtis Cooley
            > > curtis.cooley@
            > > blog:http://ponderingobjectorienteddesign.blogspot.com
            > > ===============
            > > Leadership is a potent combination of strategy and character. But if you
            > > must be without one, be without the strategy.
            > > -- H. Norman Schwarzkopf
            > >
            > >
            > > [Non-text portions of this message have been removed]
            > >
            >
          • Kay A Pentecost
            Hey, Everybody, I ve been hearing vague things about ITIL.... does anyone know what it is and how it is used? Opinions gratefully accepted. Thanks, Kay
            Message 5 of 7 , Nov 5, 2011
            • 0 Attachment
              Hey, Everybody,

              I've been hearing vague things about ITIL.... does anyone know what it is
              and how it is used?

              Opinions gratefully accepted.

              Thanks,

              Kay
            • William Rutiser
              ... Never heard of it before. But see http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
              Message 6 of 7 , Nov 5, 2011
              • 0 Attachment
                On 2011-11-05 2:38 PM, Kay A Pentecost wrote:
                > Hey, Everybody,
                >
                > I've been hearing vague things about ITIL.... does anyone know what it is
                > and how it is used?
                >
                > Opinions gratefully accepted.
                >
                > Thanks,
                >
                > Kay
                Never heard of it before. But see
                http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
              • Andrew McDonagh
                It s used by most major corporations to run internal services like help desks. It s basically a Service Management tool kit. Theres various levels of
                Message 7 of 7 , Nov 5, 2011
                • 0 Attachment
                  It's used by most major corporations to run internal services like help desks. It's basically a Service Management tool kit. Theres various levels of certification for individuals. Most companies are moving to ITIL v3

                  I run a testing service for my company, we provide automation testers, tools and testing best practices to our project teams. Think of us as a one stop shop for testing.

                  Andrew

                  On 5 Nov 2011, at 14:56, William Rutiser <wruyahoo05@...> wrote:

                  > On 2011-11-05 2:38 PM, Kay A Pentecost wrote:
                  > > Hey, Everybody,
                  > >
                  > > I've been hearing vague things about ITIL.... does anyone know what it is
                  > > and how it is used?
                  > >
                  > > Opinions gratefully accepted.
                  > >
                  > > Thanks,
                  > >
                  > > Kay
                  > Never heard of it before. But see
                  > http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library
                  >
                  >


                  [Non-text portions of this message have been removed]
                Your message has been successfully submitted and would be delivered to recipients shortly.