Re: [scrumdevelopment] Scrum Development with Multiple teams -
- Hello Kala_krish,
Thanks for your questions and wonderful that you are entering the Scrum domain. Let me try to give you my views on things.On 2/1/07, kala_krish <kalahariharan@...> wrote:
1.what are the issues I need to take care while planning and
defining the way of working for this team . ?
Initially nothing much more then what you have to learn about Sprint planning in Scrum. Later you may need to find a solution to resolve dependencies with the other teams. Initially do the simplest thing that could possibly work - focus on your own team and gain experience.
2.what are the issues do u forsee in this kind of projects?
Learning, and that is fun. Your tester is spread a bit thin, but then the architect and project manager can step in to do some work as well.
3. I there any mechanism where i can approx predict the end date ?
Yes, estimate the product backlog, divide it by a careful estimate of your velocity and you have an end date. After two sprints you'll have a better idea, after 3 sprints even better etc.
- Thanx a lot to Hubert and Dave for sharing ur experience .This will def. help me in proceeding ahead with my way of working .Just have one more query . while estmating we use wide band delphi. Will this be the right estimation technique for agile .. coz waht i feel is that if we have some scientific method of estimation like Function points , then calculating the team velocity would be more accurate .. any comments ?
On 2/1/07, dnicolet99 <dnicolet@...> wrote:
--- In email@example.com, "kala_krish"
> We are starting a new project with a team size of 5( 2 developers,
> 1test engineer, 1 architect & the PM). We have decided adopt Scrum
> Way of working . The team is familiar with this methodology even
> though one person has still has some apprehension in this
> methodology .
> This project has dependencies with 3 other teams ( 2 teams are based
> in US ) and one team within our company itself. The other three
> teams are not following SCRUM. We are currently in the process of
> defining the Way of working for the team . The other issue is the
> end of project is
> My question to the group is ..
> 1.what are the issues I need to take care while planning and
> defining the way of working for this team . ?
> 2.what are the issues do u forsee in this kind of projects?
> 3. I there any mechanism where i can approx predict the end date ?
Based on past experience in doing agile projects inside a larger
organization that was predominantly non-agile, I think these points
might be relevant to your situation:
1. defining the way of working ... to keep your team focused and to
maintain communication with non-agile partners, you may need to have a
person whose main job is to keep non-agile administrative tasks and
miscellaneous interruptions away from the Scrum team. The reason for
this is that the rest of the organization does not operate in an agile
way, and probably has various administrative requirements that don't
apply to agile work, but that you lack the power to eliminate entirely.
This person may also need to prepare project status reports in a form
that is digestible to non-agile management. Non-agile management may
not understand or trust the way we track progress on agile projects,
since it is very different from conventional methods. The Scrum team
members shouldn't be burdened with these activities. Otherwise, the
Scrum team can operate internally as it normally would do.
2. issues ... I've seen two basic issues in coordinating the work of
agile and non-agile teams: (a) mistrust between the teams due to
misunderstanding of the "other" team's way of working, sometimes going
as far as a fear that the "other" team will cause "our" team to fail
due to its different way of working, and (b) the different time scales
on which events occur during the project - non-agile groups are
accustomed to taking far more time to get things done than agile
groups, so if the Scrum team has dependencies on non-agile teams for
deliverables, you have to expect those deliverables to be delayed
unless you can work out a special plan between the two teams to
accommodate you team's normal working pace. This will be easier if you
build a good rapport with them.
You say you have three partner teams, one of which is within your
company and, I assume, local. To deal with (a), you can personally
visit the other team and invite them to visit your team's work area.
The goal is to help everyone understand the "other" team's way of
working, especially the reasons why they do certain things
differently, so that they can appreciate each other's needs and
challenges. It might be appropriate for you to make a presentation to
the other team to explain Scrum. The two teams can then work out a way
of working together that suits both of them. Both will probably have
to compromise on some aspects of their respective methodologies, and
that will mitigate issue (b). It works better when the two teams can
figure this out collaboratively than when management tells them what
Unfortunately, to coordinate work with remote non-agile teams we
usually have to fall back on some form of "service level agreement"
and there tends to be a greater need for "formal" processes.
Reciprocal personal visits at the start of the project can help by
introducing all the team members and letting them see the work
environments of their remote partners, but collaboration will never be
as smooth as it could be with collocated teams.
3. approx predict the end date ... Personally, I've had good results
using the techniques presented in the book Agile Estimating and
Planning by Mike Cohn. He offers very practical guidelines for agile
project planning and tracking at all levels. You might find it a
I hope this helps. Best of luck!