Re: [scrumdevelopment] Team organization
- 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.
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:
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.