views:

573

answers:

3

Post edited for clarification (original post at the bottom).

I wish to reorganize the R&D staff from horizontal (i.e. specialty or component based) teams to vertical (i.e. feature, self sufficient) teams. I'm likely to end up with 3-4 teams, with developers and QA engineers who collaboratively can work with most aspects of the product. I have, however, only one qualified DBA, and one technical writer. I can have DBA on one team, and give his team features that require the most complicated DB work, and give tasks with more trivial DB-related aspects to the teams without the DBA.

Almost every feature, though, requires the documentation to be updated, and documentation is a task that must be completed in almost every feature, for it to be Done. I have only one technical writer. The rest of the developers do not have (nor can learn) the skills required to write the documentation, as it is not in their native language.

How do I deal with such resources in a vertical team?

  1. Do I have the writer not be part of any team? That would make it impossible for the team to be "Done" on his own.
  2. Do I have the writer be part of all teams? If so, how can he attend all of the teams' meetings (daily, planning, retrospectives)?
  3. Do I make him a member of just one team? Which one? All teams need him equally. How do the other teams get "Done" without him?

Thanks, Assaf.


Original:

Our company want to adopt the Scrum way of life, and be able to assign a feature to a team, and have that feature "Done" (i.e. according to the Definition of Done), within the team.

Some skills, though, require skills not owned by enough people in the team, to assign one to each team (e.g. technical writer, DBA, integration specialist, etc.)

How would you deal with such limited-resource-specialists with mostly vertical teams?

+1  A: 

first, I would not confuse scrum teams and organizational structure. Organization -wise,your tech. writer can belong to any team. From Scrum perspective, i would dedicate time of the tech writer to the teams (the distribution depends on your sprint size) e.g. one day a week to each team or AM/PM (for 2 teams). That way, each scrum team knows how much and when the tech writer is assigned to them and can plan accordingly. I would also have the tech writer attend all the daily meetings if possible (with 2 teams, it should be doable). This way, the tech writer (or any scarce resource) would be a part of all the teams (scrum-wise). I think the only problem may be discipline to only work for the assigned team ad assigned times, but I am sure you will sort that our in a sprint or two. I am not sure about the planning meetings, but I am sure the person should take part in retrospectives Matej

Harnod
This doesn't answer the question - What do I do when I've got multiple teams, but only person qualified to write the technical documentation, or only one DBA?
Assaf Stone
I am afraid that the current version of the question does not match the question I was answering :-(, please see the original
Harnod
Yeah, well, I guess I wasn't sufficiently clear in my intent at first. First question. MY bad.
Assaf Stone
+2  A: 

Scrum is focused around projects & deliverables, not teams. That is, there's a "team" that is making the project, but that may or may not overlap with an organizational (functional) definition of a team. Or another way, there's no stipulation that everybody on a sprint needs to report to the same manager.

You should organize your sprints, deliverables, etc so that everybody in the room has skin in the game (is a pig, in Scrum parlance) and that everybody who has skin in the game is in the room. Don't let the BAs, etc (chickens) in except during planning.

There's a bit of use-your-judgment on this. Depending on the size of your organization and/or project, you may actually have several sprints working on different areas (if each area is big) or even have several areas on one sprint (if you have many small areas that aren't worth generating lots of meetings for).

Matt
This much I know. You're not answering the question, though, which is: How can I build multiple (say 3-4) vertical teams, if I've got only one technical writer, and one DBA? All teams need their expertise some of the time, for most user-stories.
Assaf Stone
That falls into the "use-your-judgement" clause. Not being snide, but it depends how much your people (dis)like meetings and how well they keep to the "5-minute-meeting" rule.There is no real answer for you. Some'll say it's a mistake to have 1 person on 4 projects, period (2's a good limit). You may not have a choice, though.I'd suggest somehow collapsing 4 sprints into 2. If that's not possible, do 3 or 4 but don't meet daily. I've found violating the "meet daily" rule is better than violating the "everybody's present every meeting" rule.
Matt
I see what you're saying, but I don't really like any of the options. I want the daily meeting to be, well, daily. It's my project's heartbeat. And there's really never going to be a case for an additional technical writer. And I want my sprints to be synchronized, to have common releases, and a point in time where I can reorganize teams, without interrupting a team in mid-sprint.Still stuck.
Assaf Stone
+1  A: 

After doing some research (a lot of sites, and a book named "Cross-functional teams" By Glenn M. Parker), I came to the following conclusions:

  1. A team should be comprised of people who are collectively qualified to get the team's features "Done". This means, that each member is not expected to be able to perform every task required , but that every task required can be performed, in sufficient quality, by at least one member of the team.
  2. While the team(s) should be cross-functional, when there is more than one team, there should be also some form of functional department, whether official or otherwise, led by an expert in the field. The expert may be a member of one team, or not, but in any case all members who perform tasks of a certain function, should communicate and collaborate frequently enough with the expert, as a professional authority on how to do their job.

In my example, this would mean that the DBA and Technical-Writer would both lead their respective professional forum or department (depending on the level of formality), they may each be a member of one team. Database and documentation work would be done by team members capable of doing the work, and doing so under the experts' supervision (professional authority).

In this way specialists may exist in the organization, alongside with generalists, and what people who ride the middle between the two.

And of course, in this method, the team is capable of completing all of the business-level tasks (features, user-stories) assigned to it, in a self-sufficient manner, which is what we wanted.

Assaf Stone