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

Advice wanted regarding deciding between one or several teams.

Expand Messages
  • Kurt Häusler
    Hi, we have a larger autonomous team delivering software development services to third parties. Do distinguish it from the normal use of the word team I will
    Message 1 of 2 , Jun 27, 2013
    • 0 Attachment
      Hi,

      we have a larger autonomous team delivering software development
      services to third parties. Do distinguish it from the normal use of
      the word team I will call it a company. It has about 15 people, about
      10 of which are developers.

      Now it is difficult for us from a risk management perspective to have
      1 customer at a time, as should that customer wish to stop
      development, or reduce the rate at which they need changes, we are
      suddenly underutilized to the extent that we are losing money until we
      can find a replacement customer.

      So we tend to try and have at least 2 customers / active products at a
      time. Sometimes 3.

      Usually we have 2 or 3 Scrum subteams each with their own Product, PO,
      SM, Backlog etc. This means when one Product stops development, or
      slows down development, we still have money coming in while we find a
      new Product.

      However we are having a lot of trouble allowing really good high
      performance teams to develop, as people are getting moved between
      teams a lot, to adjust for changing capacity across products. And also
      to transfer knowledge across teams.

      Our current experiment is to have 1 large Scrum team, only a little
      bit larger than typically suggested, to take on multiple products.
      Usually 2 at once, sometimes 3.

      Oh some of these products are fairly mature, and have a hard to
      predict mix of larger features, operations, bug fixes, small changes
      etc. Each product has its own backlog and PO, and we will allow the
      POs to negotiate to see how much of the velocity will be allocated to
      each project during planning, according to current demand etc.

      Has anyone got tips for such an issue? Is there a better way to allow
      solid stable teams to grow, and still avoid the risks of only having 1
      product in development at a time?

      Thanks
    • Markus Gärtner
      Hi Kurt, Sounds like a challenge for your prodct portfolio. You might want to try Portolio Kanban to achieve a constant flow for your Scrum team(s). Mobile.de
      Message 2 of 2 , Jun 27, 2013
      • 0 Attachment
        Hi Kurt,

        Sounds like a challenge for your prodct portfolio. You might want to try Portolio Kanban to achieve a constant flow for your Scrum team(s). Mobile.de does something like that.

        In addition take closer look at the Boston Consting Matrix. You should think about which products are your rising stars, and your poor dogs.

        Best Markus
        --
        Dipl.-Inform. Markus Gärtner
        Author of ATDD by Example - A Practical Guide to Acceptance
        Test-Driven Development

        On 27.06.2013, at 10:52, Kurt Häusler <kurt.haeusler@...> wrote:

        Hi,

        we have a larger autonomous team delivering software development
        services to third parties. Do distinguish it from the normal use of
        the word team I will call it a company. It has about 15 people, about
        10 of which are developers.

        Now it is difficult for us from a risk management perspective to have
        1 customer at a time, as should that customer wish to stop
        development, or reduce the rate at which they need changes, we are
        suddenly underutilized to the extent that we are losing money until we
        can find a replacement customer.

        So we tend to try and have at least 2 customers / active products at a
        time. Sometimes 3.

        Usually we have 2 or 3 Scrum subteams each with their own Product, PO,
        SM, Backlog etc. This means when one Product stops development, or
        slows down development, we still have money coming in while we find a
        new Product.

        However we are having a lot of trouble allowing really good high
        performance teams to develop, as people are getting moved between
        teams a lot, to adjust for changing capacity across products. And also
        to transfer knowledge across teams.

        Our current experiment is to have 1 large Scrum team, only a little
        bit larger than typically suggested, to take on multiple products.
        Usually 2 at once, sometimes 3.

        Oh some of these products are fairly mature, and have a hard to
        predict mix of larger features, operations, bug fixes, small changes
        etc. Each product has its own backlog and PO, and we will allow the
        POs to negotiate to see how much of the velocity will be allocated to
        each project during planning, according to current demand etc.

        Has anyone got tips for such an issue? Is there a better way to allow
        solid stable teams to grow, and still avoid the risks of only having 1
        product in development at a time?

        Thanks


        ------------------------------------

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

        <*> To visit your group on the web, go to:
           http://groups.yahoo.com/group/scrumdevelopment/

        <*> Your email settings:
           Individual Email | Traditional

        <*> To change settings online go to:
           http://groups.yahoo.com/group/scrumdevelopment/join
           (Yahoo! ID required)

        <*> To change settings via email:
           scrumdevelopment-digest@yahoogroups.com
           scrumdevelopment-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
           scrumdevelopment-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
           http://docs.yahoo.com/info/terms/

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