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

Team organization

Expand Messages
  • Oksana Schwartz
    Hello Everyone, I am doing a little bit of investigating on organization structure, particularly team structures in software development. How are your teams
    Message 1 of 5 , Feb 23, 2012
    • 0 Attachment
      Hello Everyone,

      I am doing a little bit of investigating on organization structure, particularly team structures in software development.

      How are your teams organized?  Or how do you think development teams should be organized?
      Here are a few examples I have seen:

      • One team per product
        • Product A has a front end person, middle tier person, and a backend person/people
        • Product B as above
      • One team per tier
        • Team A is only backend people
        • Team B is only front end

      Where do you think DBA's fit into the scheme of things? Should DBA's be their own team, or imbedded in teams?

      I would appreciate your input.

      Thanks

      Oksana
      Scrum Master
    • Bret Wortman
      The general idea is to keep teams as cross-functional as possible, so you would want back-end and front-end developers and DBAs on the same team. You ll be
      Message 2 of 5 , Mar 1, 2012
      • 0 Attachment
        The general idea is to keep teams as cross-functional as possible, so you would want back-end and front-end developers and DBAs on the same team. You'll be integrating throughout development instead of waiting until both front-end and back-end are done to put the pieces together.

        Good luck!


        Bret Wortman



        On Thu, Feb 23, 2012 at 2:04 PM, Oksana Schwartz <omaeva@...> wrote:
         

        Hello Everyone,

        I am doing a little bit of investigating on organization structure, particularly team structures in software development.

        How are your teams organized?  Or how do you think development teams should be organized?
        Here are a few examples I have seen:

        • One team per product
          • Product A has a front end person, middle tier person, and a backend person/people
          • Product B as above
        • One team per tier
          • Team A is only backend people
          • Team B is only front end

        Where do you think DBA's fit into the scheme of things? Should DBA's be their own team, or imbedded in teams?

        I would appreciate your input.

        Thanks

        Oksana
        Scrum Master


      • Michael James
        Generally we re trying to reduce silos specialized on particular skills, functions, roles, or components. Most places with front end teams distinct from back
        Message 3 of 5 , Mar 1, 2012
        • 0 Attachment
          Generally we're trying to reduce silos specialized on particular skills, functions, roles, or components.  Most places with front end teams distinct from back end teams (e.g. teams building only the services layer of a Service Oriented Architecture) have bottlenecks, quality problems, and can't reprioritize user-centric requirements.

          So (speaking generally again) it's less frustrating to be on a team that doesn't depend on others to deliver customer value.  Regarding specialists such as your DBAs, one place I worked with had a department of "software architects" they basically dissolved to put them on individual Scrum teams.  Of course the architects kept talking to each other as well, as they should.

          I think it would be irresponsible to accept a recommendation from people who don't know anything about your particular situation without understanding the underlying principles.  The most thorough treatment of these issues I've seen (perhaps too thorough) is in _Scaling Lean and Agile Development_ by Craig Larman and Bas Vodde. 

          --mj
          (Michael)


          On Feb 23, 2012, at 11:04 AM, Oksana Schwartz wrote:

           

          Hello Everyone,

          I am doing a little bit of investigating on organization structure, particularly team structures in software development.

          How are your teams organized?  Or how do you think development teams should be organized?
          Here are a few examples I have seen:

          • One team per product
            • Product A has a front end person, middle tier person, and a backend person/people
            • Product B as above
          • One team per tier
            • Team A is only backend people
            • Team B is only front end

          Where do you think DBA's fit into the scheme of things? Should DBA's be their own team, or imbedded in teams?

          I would appreciate your input.

          Thanks

          Oksana
          Scrum Master


        • Bret Wortman
          Excellent point, and it applies directly to the advice I shot off earlier. Which I should have said applies in general, but there may well be reasons for *not*
          Message 4 of 5 , Mar 1, 2012
          • 0 Attachment
            Excellent point, and it applies directly to the advice I shot off earlier. Which I should have said applies in general, but there may well be reasons for not doing those things, which only a deeper discussion would have revealed.


            Bret Wortman



            On Thu, Mar 1, 2012 at 1:36 PM, Michael James <mj4scrum@...> wrote:
             

            Generally we're trying to reduce silos specialized on particular skills, functions, roles, or components.  Most places with front end teams distinct from back end teams (e.g. teams building only the services layer of a Service Oriented Architecture) have bottlenecks, quality problems, and can't reprioritize user-centric requirements.

            So (speaking generally again) it's less frustrating to be on a team that doesn't depend on others to deliver customer value.  Regarding specialists such as your DBAs, one place I worked with had a department of "software architects" they basically dissolved to put them on individual Scrum teams.  Of course the architects kept talking to each other as well, as they should.

            I think it would be irresponsible to accept a recommendation from people who don't know anything about your particular situation without understanding the underlying principles.  The most thorough treatment of these issues I've seen (perhaps too thorough) is in _Scaling Lean and Agile Development_ by Craig Larman and Bas Vodde. 

            --mj
            (Michael)


            On Feb 23, 2012, at 11:04 AM, Oksana Schwartz wrote:

             

            Hello Everyone,

            I am doing a little bit of investigating on organization structure, particularly team structures in software development.

            How are your teams organized?  Or how do you think development teams should be organized?
            Here are a few examples I have seen:

            • One team per product
              • Product A has a front end person, middle tier person, and a backend person/people
              • Product B as above
            • One team per tier
              • Team A is only backend people
              • Team B is only front end

            Where do you think DBA's fit into the scheme of things? Should DBA's be their own team, or imbedded in teams?

            I would appreciate your input.

            Thanks

            Oksana
            Scrum Master



          • Charles Bradley - Scrum Coach CSM PSM I
            Mike Cohn has good material on this as well in his _Succeeding With Agile_ book.   ... Charles Bradley http://www.ScrumCrazy.com ... Mike Cohn has good
            Message 5 of 5 , Mar 1, 2012
            • 0 Attachment
              Mike Cohn has good material on this as well in his _Succeeding With Agile_ book.
               
              -------
              Charles Bradley
              http://www.ScrumCrazy.com




              From: Michael James <mj4scrum@...>
              To: scrumdevelopment@yahoogroups.com
              Sent: Thursday, March 1, 2012 11:36 AM
              Subject: Re: [scrumdevelopment] Team organization



              Generally we're trying to reduce silos specialized on particular skills, functions, roles, or components.  Most places with front end teams distinct from back end teams (e.g. teams building only the services layer of a Service Oriented Architecture) have bottlenecks, quality problems, and can't reprioritize user-centric requirements.

              So (speaking generally again) it's less frustrating to be on a team that doesn't depend on others to deliver customer value.  Regarding specialists such as your DBAs, one place I worked with had a department of "software architects" they basically dissolved to put them on individual Scrum teams.  Of course the architects kept talking to each other as well, as they should.

              I think it would be irresponsible to accept a recommendation from people who don't know anything about your particular situation without understanding the underlying principles.  The most thorough treatment of these issues I've seen (perhaps too thorough) is in _Scaling Lean and Agile Development_ by Craig Larman and Bas Vodde. 

              --mj
              (Michael)


              On Feb 23, 2012, at 11:04 AM, Oksana Schwartz wrote:

               
              Hello Everyone,

              I am doing a little bit of investigating on organization structure, particularly team structures in software development.

              How are your teams organized?  Or how do you think development teams should be organized?
              Here are a few examples I have seen:

              • One team per product
                • Product A has a front end person, middle tier person, and a backend person/people
                • Product B as above
              • One team per tier
                • Team A is only backend people
                • Team B is only front end

              Where do you think DBA's fit into the scheme of things? Should DBA's be their own team, or imbedded in teams?

              I would appreciate your input.

              Thanks

              Oksana
              Scrum Master






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