4

My company has grown seriously over the last years. Until a few years ago we could work with 1 agile team and everything went quite smooth. Now we have multiple teams, all working agile and things go less smoothly as we would hoped.

One of the main [psychological] problems is how to organize the working methods in the teams.

  • If every team has its own way of working (its own type of Excel sheets where the progress is kept, its own way of calculating capacity, ...) the teams seem to drift apart and seem to compete rather than cooperate on things (developing similar code in parallel)
  • If all teams use the same methodologies and work flow procedures, then again we have two alternatives:
    • 'Forcing' the methodologies by management seems incorrect since management does not clearly know how agile/scrum methodologies should work (only the actual teams know this)
    • Letting teams making suggestions for improvements and them 'forcing' this onto other teams might improve the competition rather than the cooperation (teams will refuse to use the methodology because it comes from another team).

Does anyone have any experience with multiple teams working together in an agile/scrum way? How do promote the teams working together without making them 'blaming eachother' for things that don't work?

6
  • Mainly it's a management problem - someone needs to be prodding consistently..
    – Caffeinated
    Commented Jul 18, 2011 at 13:58
  • What's the actual problem? "seem to drift apart"? That doesn't sound like an actual problem. Best practices arise because of experimentation (i.e., drifting apart, innovating, challenging accepted wisdom). It would help if you could explain what's broken; what problem you have; how this is actually preventing things from getting done on time.
    – S.Lott
    Commented Jul 18, 2011 at 14:18
  • With 'drifting apart' I mean two things: First, moving people between teams becomes harder because they have to learn new methodologies. Second, it's harder to line-up management-reporting, especially if the management wants to go into more details (e.g. why do the people of your team only work at 80%, and the people of the other team have only an overhead of 1 days per 10 days?)
    – Patrick
    Commented Jul 18, 2011 at 14:24
  • How often do resources actually change teams? I always hear this argument but its really not something that happens all that often in all the places I've worked. What you really have here are a couple of "management concerns" related to staffing and reporting. Those are a lot better problems to have than having problems with actually building software.
    – Jeremy
    Commented Jul 18, 2011 at 15:03
  • @Patrick: Please update the question to make this perfectly clear. Provide details on "moving people between teams becomes harder". Moving people between teams is always hard. What's "harder" about your situation? Provide details on "harder to line-up management-reporting". Management concepts like "overhead" and "work at 80%" are sometimes little more than random numbers collected inconsistently. Please explain what "harder" means in this case. Please update the question to contain all the information.
    – S.Lott
    Commented Jul 18, 2011 at 15:05

2 Answers 2

Reset to default
2

From your description it is not clear whether the teams are actually working on separate projects - I assume they are.

In the ideal case, I think this should be mainly decided by the teams themselves, but they would come to more or less the same conclusion (i.e. using Agile). Especially if prominent members of the teams used to work together in the single Agile team before, they tend to naturally bring with them the practices they tried and proven to work.

However, each new team is bound to encounter its own, more or less different situation and challenges, so over time they will develop their own process a little bit differently from the others. And that is fine, within certain limits. In order to make management's life easier, it is advisable to agree upon and stick to some common way of reporting towards management. But since Agile is not reporting-heavy, I don't think this imposes huge restrictions on any team.

Now, if one team comes up with a process improvement, it is indeed useful for other teams to learn about it - as long as it actually solves some problem of theirs too. So IMO the best approach would be to keep up communication between teams regarding retrospectives and process improvement solutions, by way of some designated team members (one from each team would be enough - e.g. the Scrum Masters) to regularly meet after each sprint and discuss the problems they encountered, the solutions they tried, and the results.

So if Team A tells about a problem, it is possible that Team B has already got a working solution for it, which can be applied right away. Or if Team A has an idea to solve same problem, it is possible that Team C has already experimented with a similar idea and they have gained useful experience which they can share with Team A. Etc. The point is that any team is most interested in solutions to their concrete problems, so it is best to approach knowledge sharing from this perspective: adapting solutions to concrete problems, rather than trying to adapt processes to imaginary "solutions". Development teams would be pretty normal to resist the latter approach, but not the former.

0

its own type of Excel sheets where the progress is kept

That should set off some alarms right there. It's probably worth investing in some project management software. The Atlassian suite is pretty good and probably the most popular. FogCreek (creator of stack exchange) have some nice tools as well. It's natural for different projects to be run differently. Frequently it's for the best. Centralizing your tasks and properly tracking your progress is essential, however.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.