Loading ...
Sorry, an error occurred while loading the content.

Scrum Development with Multiple teams -

Expand Messages
  • kala_krish
    Hi 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
    Message 1 of 4 , Feb 1, 2007
    • 0 Attachment
      Hi

      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 ?



      Thanx
    • dnicolet99
      ... Hi Kala, Based on past experience in doing agile projects inside a larger organization that was predominantly non-agile, I think these points might be
      Message 2 of 4 , Feb 1, 2007
      • 0 Attachment
        --- In scrumdevelopment@yahoogroups.com, "kala_krish"
        <kalahariharan@...> wrote:
        >
        > Hi
        >
        > 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 ?
        >
        >
        >
        > Thanx
        >

        Hi Kala,

        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
        to do.

        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
        useful resource.

        I hope this helps. Best of luck!
        Dave
      • Hubert Smits
        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. ... Initially
        Message 3 of 4 , Feb 1, 2007
        • 0 Attachment
          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

          Success!

          Hubert


        • Kala Hari
          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
          Message 4 of 4 , Feb 1, 2007
          • 0 Attachment
            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 scrumdevelopment@yahoogroups.com, "kala_krish"
            <kalahariharan@...> wrote:
            >
            > Hi
            >
            > 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 ?
            >
            >
            >
            > Thanx
            >

            Hi Kala,

            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
            to do.

            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
            useful resource.

            I hope this helps. Best of luck!
            Dave


          Your message has been successfully submitted and would be delivered to recipients shortly.