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

Help me improve the process

Expand Messages
  • Alex Kroman
    I am about to start working as a senior developer at a small consulting company with 10 other developers. We sell a web-based software-as-a-service
    Message 1 of 4 , Mar 8, 2007
    • 0 Attachment
      I am about to start working as a senior developer at a small
      consulting company with 10 other developers. We sell a web-based
      software-as-a-service application to large corporations. We have been
      rolling this out to about 20 customers a year and every project
      requires significant customization. All of our customers are running
      on a standard base software package and have additional bespoke modules.

      Here is an overview of the current process:

      - Sales "oversells" the application
      - All of the developers rush to upgrade the base package so that it
      has the functionality that sales has sold
      - Another group of developers create any 1-off modules that are
      specific to the corporation buying the product.
      - After 6 weeks or so our base application is upgraded and rolled out
      to ALL of our customers and we launch the new implementation for the
      client.

      What is the best way to implement Scrum in this environment? Are we
      asking for trouble by having a new release of our base software every
      time it is sold? Should "Development" and "Implementation" be
      separated so that implementation schedules don't drive development?
    • Greg Akins
      ... I am working in a very similar environment. It took me a long time to convince folks to try; but now that I finally have (about 2 weeks ago) we re already
      Message 2 of 4 , Mar 8, 2007
      • 0 Attachment
        On 3/8/07, Alex Kroman <alexkroman@...> wrote:
        >
        > What is the best way to implement Scrum in this environment?

        I am working in a very similar environment. It took me a long time to
        convince folks to try; but now that I finally have (about 2 weeks ago)
        we're already seeing benefits. It's interesting that the most
        skeptical are some developers. The folks that have seen the most
        benefit are manager's and internal customers.

        > Are we
        > asking for trouble by having a new release of our base software every
        > time it is sold?

        Maybe. Depends on how your managing your releases. Scrum has helped
        us to plan our releases better and reduce the uncertainty preceding
        releases.

        >Should "Development" and "Implementation" be
        > separated so that implementation schedules don't drive development?

        We're considering two consecutives Sprints because of some overhead in
        our QA process. It's not idea; but one Sprint will require full
        regression testing (no automated testing). Another Sprint will be
        setup to make less destructive changes so it can be moved through QA
        more quickly.

        Long term, I wouldn't do this, but I'm it will be tough to convince
        people to change what they're used to doing.

        Good Luck!

        --
        ==============
        Greg Akins
        http://www.pghcodingdojo.org
        http://www.insomnia-consulting.org/monologue
      • Alex Kroman
        ... So are you having the entire group use 1 big scrum process? I am wondering if it makes more sense to have an implementation and customization scrum
        Message 3 of 4 , Mar 8, 2007
        • 0 Attachment
          --- In scrumdevelopment@yahoogroups.com, "Greg Akins" <angrygreg@...>
          wrote:
          >
          > On 3/8/07, Alex Kroman <alexkroman@...> wrote:
          > >
          > > What is the best way to implement Scrum in this environment?
          >
          > I am working in a very similar environment. It took me a long time to
          > convince folks to try; but now that I finally have (about 2 weeks ago)
          > we're already seeing benefits.


          So are you having the entire group use 1 big scrum process? I am
          wondering if it makes more sense to have an "implementation and
          customization" scrum group and a "development" scrum group. The
          development group releases on new version of the application every
          month and the implementation group releases to the clients as needed.
        • Andreas Schliep
          ... Alex, it s hard to try to seperate software architecture considerations, marketing and sales requirements and the process... Scrum will definately be good
          Message 4 of 4 , Mar 9, 2007
          • 0 Attachment
            >
            > So are you having the entire group use 1 big scrum process? I am
            > wondering if it makes more sense to have an "implementation and
            > customization" scrum group and a "development" scrum group. The
            > development group releases on new version of the application every
            > month and the implementation group releases to the clients as needed.
            >

            Alex,

            it's hard to try to seperate software architecture considerations,
            marketing and sales requirements and the process...

            Scrum will definately be good for your company if you reach a common
            understanding and mutual respect. Sales have to stop overselling.
            Developers have to figure out the most suitable way to combine
            frequent releases with frequent deliveries.

            When I was in your situation, a couple of years before I ever heard
            about Scrum and Agile, we didn't release the software to all customers
            every time we just had to deliver a customization. Each time a
            customer received an update, he just got the latest version with his
            own special features.

            Whether you decide to handle the version tree with a sophisticated
            configuration management or a software refactoring that simplifies
            modular extensions, should be up to your developers.

            I don't think it'll do you good if you split up the team. The customer
            releases group would be alienated from the feature group. The
            developers in one group would feel disturbed or blocked by the others.

            While it's generally undesired to mix up different projects in one
            Sprint, you could give it a try. The customer implementation stories
            would have a higher priority than new features, of course. The whole
            team would be able to improve the software design to make
            customizations less expensive. Start with short iterations and
            frequent retrospectives and let the team find out.

            Regards
            Andreas
          Your message has been successfully submitted and would be delivered to recipients shortly.