My group has recently grown in size with the addition of several teams from different projects. We work using an Agile programming methodology: 2 week sprints, deliverable every sprint, 2-3 pushes to production every sprint for each team.

How do I "convert" the newly added teams to this methodology and way of thinking with as little trauma and resistance from the members of these teams?

Note: I'm not asking if they want to change their methodology, they will have to operate this way to be in sync with the rest of the group. This is a different question than this one as all other teams already work using Agile programming.

closed as too broad by GlenH7, psr, user22815, Ixrec, durron597 Jun 27 '15 at 21:49

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


How do I "convert" the newly added teams to this methodology and way of thinking with as little trauma and resistance from the members of these teams?


Actually start -- right now -- with backlog definition, prioritization and sprint planning.

They won't "get it" right away. That doesn't matter -- explanations don't really help as much as simply doing it.

Get them started with daily standups today. Immediately. No waiting around. No "conversion". Just start.

Agree to just one sprint to get started with a reasonable scope of work. They'll completely mess it up, but that's okay.

Redefining the sprint's objectives -- rearranging the backlog -- is easiest done hands-on with real deliverables in a real project with real sprint deadlines approaching.

Moving from long, long coding followed by a burst of insane testing to shorter sprints isn't really all that hard. Most folks prefer it. We mostly do waterfall to placate managers and accountants.

Do a retrospective and continue the cycle allowing them to make their own improvements.

The best way to learn Agile methods is to just start doing Agile methods.

As questions come up ("How can we prioritize if we don't know every single possible requirement in advance?") address those specific questions with advice based on the specific backlog and sprint you have to tackle right now.

Avoid hypothetical answers. Just get started.

Ideally, part way through the second sprint, folks will say that this "Agile thing" isn't all that interesting. They always did this. They just didn't call it Agile.

  • 1
    +1 Agreed - the biggest hurdle in most IT organizations is USUALLY management. But, since you are already successfully implementing it for other teams, then you are fine there. Possibly, you could have the new team leads observe your other teams and their meetings (prioritization, Stand-ups, iteration planning) so they can know what to expect. Get 'em in the fire!! – Catchops Jun 23 '11 at 13:38

If you can afford the time, and you are (or have access to) an experienced Scrum Master (or XP coach), then prepare a one-day workshop where you use the first half of the day to go through the theory, and the second half to run a demonstration mini sprint (30 minutes planning, 2 hours sprint, 30 minutes demo and review) on something that can be done in such a short period. I have done this several times in the past, and it has helped these teams a lot to get going. Then follow S.Lott's advice.

  • Thanks @wolfgangsz, that's a great idea. I think a combination of both @S.Lott and your answer will probably work. – Asaf Jun 26 '11 at 7:15

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