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

Re: [scrumdevelopment] Re: Are BA's included in the Sprint Team

Expand Messages
  • Dion Stewart
    ... No, the Product Owner still drives the product. The Product Owner is responsible for bringing a prioritized Product Backlog to the Sprint planning meeting.
    Message 1 of 22 , Sep 3, 2004
    • 0 Attachment
      On Friday, September 3, 2004, at 01:22 AM, Kurt Heiz wrote:
      >
      > Would you not be going against the "Product Owner driving the
      > Product" principle by basing the Sprint on what the team can
      > accomplish and not the priorities of the Product Owner?
      >

      No, the Product Owner still drives the product. The Product Owner is
      responsible for bringing a prioritized Product Backlog to the Sprint
      planning meeting. The team decides how much of the Product Backlog it
      can complete within the Sprint. This is based on the priority defined
      by the Product Owner. It's not arbitrary. There may be give and take
      during this meeting - the Product Owner may re-prioritize items on the
      Backlog once she has an understanding of what the team can commit to
      for the Sprint.

      > As about 60% of the product is complete, most of the requirements
      > have been defined and documented. When I said the BAs would feed the
      > Product Backlog, I meant that while the team is focusing on current
      > requirements in the Sprint, the BAs would be outside of the Sprint
      > and gathering possible new requirements or detailing high-level
      > requirements.
      >
      > If you suggest that BAs should definately be part of the team, would
      > that imply that activities such as "Gather new requirements re: XYZ
      > business fucntion" be listed on the Product Backlog and moved to the
      > Sprint Backlog for the BAs to do during the Sprint? Would you not
      > only have construction activities on the Product Backlog?

      I would not put "gather new requirements..." on the Product Backlog as
      a specific item. I would not have the BA work "ahead" of the team
      members doing the construction and testing. If the BAs are not working
      on the work being completed within a Sprint they're really not part of
      the team. I would have them working on the same functionality. This
      might require that some of the coders, technical writers, and testers
      sit in on analysis meetings during the first few days of the Sprint.
      However, coding can begin before the requirements are completely
      finished. Having a tester involved in requirements definition helps to
      build in quality from the very beginning.

      If you define the requirements for XYZ business function in Sprint 1,
      write the code for XYZ business function in Sprint 2, and then test XYZ
      business function in Sprint 3 you're not really doing Scrum. You're
      still doing waterfall - you're just doing a bunch of small waterfall
      processes. I've been on projects like this in the past and it's clearly
      better than one large waterfall process but you're not going to get the
      benefits of Scrum using this approach.

      If you define requirements during a Sprint but do not implement those
      requirements you're building up an inventory of work that has not been
      completed. This is wasteful. You may define requirements for things
      that never get implemented and/or by the time you get around to
      implementing the requirements the requirements may change.

      In Scrum the goal is to produce potentially shippable software in each
      and every Sprint. As Steven Gordon said in his reply to your question,
      it's up to the team to self-organize to meet this goal. Towards the end
      of a Sprint, BAs may be helping to test or write end user documentation
      - whatever is necessary to meet the goals of the Sprint.

      Obviously, you'll have to adapt your Sprints to reflect the fact that
      you've got an inventory of requirements already built up. How the BAs
      (and other resources) are used during a Sprint should be left up to the
      team.

      Dion
    • Kurt Heiz
      You are right, to follow the waterfall approach during sprints is definately not Scrum. That was not really what I meant. What I was driving it is, while the
      Message 2 of 22 , Sep 3, 2004
      • 0 Attachment
        You are right, to follow the waterfall approach during sprints is
        definately not Scrum. That was not really what I meant. What I was
        driving it is, while the team is busy working on the construction
        part of the product, should the BAs be included to, as you say
        assist the testers (we thought this to be a good option), or should
        they exist out of the team environemnt and just be called on as
        required, as there might not be enough tasks on the Sprint Backlog
        to keep them busy. But, I think we will include them in the team,
        and they can evolve with the rest of the team members. More than
        likely they will be kept busy detailing the requirements to the
        developers, as this is quite a complex system in terms of algorithms
        and business rules.

        Thanks for the input, much appreciated guys !

        Regards

        --- In scrumdevelopment@yahoogroups.com, Dion Stewart
        <dion.stewart@v...> wrote:
        >
        > On Friday, September 3, 2004, at 01:22 AM, Kurt Heiz wrote:
        > >
        > > Would you not be going against the "Product Owner driving the
        > > Product" principle by basing the Sprint on what the team can
        > > accomplish and not the priorities of the Product Owner?
        > >
        >
        > No, the Product Owner still drives the product. The Product Owner
        is
        > responsible for bringing a prioritized Product Backlog to the
        Sprint
        > planning meeting. The team decides how much of the Product Backlog
        it
        > can complete within the Sprint. This is based on the priority
        defined
        > by the Product Owner. It's not arbitrary. There may be give and
        take
        > during this meeting - the Product Owner may re-prioritize items on
        the
        > Backlog once she has an understanding of what the team can commit
        to
        > for the Sprint.
        >
        > > As about 60% of the product is complete, most of the requirements
        > > have been defined and documented. When I said the BAs would feed
        the
        > > Product Backlog, I meant that while the team is focusing on
        current
        > > requirements in the Sprint, the BAs would be outside of the
        Sprint
        > > and gathering possible new requirements or detailing high-level
        > > requirements.
        > >
        > > If you suggest that BAs should definately be part of the team,
        would
        > > that imply that activities such as "Gather new requirements re:
        XYZ
        > > business fucntion" be listed on the Product Backlog and moved to
        the
        > > Sprint Backlog for the BAs to do during the Sprint? Would you not
        > > only have construction activities on the Product Backlog?
        >
        > I would not put "gather new requirements..." on the Product
        Backlog as
        > a specific item. I would not have the BA work "ahead" of the team
        > members doing the construction and testing. If the BAs are not
        working
        > on the work being completed within a Sprint they're really not
        part of
        > the team. I would have them working on the same functionality.
        This
        > might require that some of the coders, technical writers, and
        testers
        > sit in on analysis meetings during the first few days of the
        Sprint.
        > However, coding can begin before the requirements are completely
        > finished. Having a tester involved in requirements definition
        helps to
        > build in quality from the very beginning.
        >
        > If you define the requirements for XYZ business function in Sprint
        1,
        > write the code for XYZ business function in Sprint 2, and then
        test XYZ
        > business function in Sprint 3 you're not really doing Scrum.
        You're
        > still doing waterfall - you're just doing a bunch of small
        waterfall
        > processes. I've been on projects like this in the past and it's
        clearly
        > better than one large waterfall process but you're not going to
        get the
        > benefits of Scrum using this approach.
        >
        > If you define requirements during a Sprint but do not implement
        those
        > requirements you're building up an inventory of work that has not
        been
        > completed. This is wasteful. You may define requirements for
        things
        > that never get implemented and/or by the time you get around to
        > implementing the requirements the requirements may change.
        >
        > In Scrum the goal is to produce potentially shippable software in
        each
        > and every Sprint. As Steven Gordon said in his reply to your
        question,
        > it's up to the team to self-organize to meet this goal. Towards
        the end
        > of a Sprint, BAs may be helping to test or write end user
        documentation
        > - whatever is necessary to meet the goals of the Sprint.
        >
        > Obviously, you'll have to adapt your Sprints to reflect the fact
        that
        > you've got an inventory of requirements already built up. How the
        BAs
        > (and other resources) are used during a Sprint should be left up
        to the
        > team.
        >
        > Dion
      • David A Barrett
        Kurt, As always, the best way really understand this is to just do it and then examine your mistakes. ... Personally, I think this is the wrong approach. The
        Message 3 of 22 , Sep 3, 2004
        • 0 Attachment
          Kurt,

          As always, the best way really understand this is to just do it and then
          examine your mistakes.

          >We have
          >decided that the makeup of the teams would be dependent on what the
          >requirements on the Sprint Backlog are.

          Personally, I think this is the wrong approach. The self-organizing team
          aspect of Scrum is every bit as important as all the other parts. Teams
          take longer than one sprint to move towards that goal, so re-organizing
          your teams is going prevent a lot of good things from happening. You need
          to remember that the teams achieve things not because the tasks are
          necessarily well suited to them, but because they are motivated and work
          well together.

          >As about 60% of the product is complete, most of the requirements
          >have been defined and documented.

          Are you sure? At most you could say that most of the requirements AS THEY
          WERE UNDERSTOOD SOME TIME IN PAST were once defined and documented. In
          order for Scrum to work in your project you need to come to some point
          where you can demonstrate everything that has already been completed. If
          you can't do this now, this should be your priority for your first sprint;
          to wrap up all WIP to some (limited, maybe) deliverable functionality.
          Then the users look at what you've done and they decide if they like it,
          what they would like changed and how this might change the way the envision
          the 40% of the project that hasn't been done yet. Maybe 50% of that 40%
          isn't needed any more, and there's a whole new slate of features that they
          would rather have done.

          >If you suggest that BAs should definately be part of the team, would
          >that imply that activities such as "Gather new requirements re: XYZ
          >business fucntion" be listed on the Product Backlog and moved to the
          >Sprint Backlog for the BAs to do during the Sprint?

          Don't forget that requirments are subject to change after every single
          sprint. This is because the sprint adds knowledge to the project.
          Developers learn more and change time estimates for tasks, users see how
          the product works and get new ideas, some aspects of a project become less
          important. Because of that we usually limit our requirement gathering and
          analysis work on any PB item to the bare minimum required to get an "order
          of magnitude" estimate of how much work it will take. This OOM estimate is
          usually enough to allow the users to prioritize the PB items during the
          Sprint Review meeting.

          So when does the detailed requirements gathering/documenting take place?
          During the sprint. Remember that a particular sprint backlog item
          shouldn't exceed a man-week by too much. If we have PB items that are
          bigger than that, we split them into smaller chunks when it looks like they
          are going to be included in a sprint. For us, that 1 man-week includes,
          requirements/analysis, programming and system testing.

          Here's an important point: You shouldn't have a PB or SB item called
          "Gather Requirements for XYZ Business Function". The deliverable of every
          single PB/SB item should always be a piece of working, potentially
          implementable functionality. Requirements don't qualify as working
          functionality.

          The other thing you should find is that the BA will stop working in some
          isolated fashion and start to become part of the team. Our BA does a whole
          pantload of things other than req's. She's got the programmers thinking
          about testing from the start of development, and the process seems to be
          that she sits down with the programmer and the user and organizes
          everything.

          Dave Barrett,
          Lawyers' Professional Indemnity Company
        • Mike Beedle
          Yes, definitely, as the cross-functional team jells productivity typically increases, mb ... From: Steven Gordon [mailto:sagordon@asu.edu] Sent: Friday,
          Message 4 of 22 , Sep 3, 2004
          • 0 Attachment
            Yes, definitely, as the cross-functional team "jells" productivity typically
            increases,

            mb



            -----Original Message-----
            From: Steven Gordon [mailto:sagordon@...]
            Sent: Friday, September 03, 2004 1:36 AM
            To: scrumdevelopment@yahoogroups.com
            Subject: RE: [scrumdevelopment] Re: Are BA's included in the Sprint Team


            In scrum, a team is self-organizing. A self-organizing team will become
            more effective over
            time (perhaps asymptotally). Changing the participants in each team every
            month would be
            likely to have a detrimental effect on productivity as well as morale. I
            would think the core
            of a team should be kept together for at least 6 months, ideally replacing
            at most 1 or 2
            people per month.

            Furthermore, making each team more or less an equal mix of all the
            applicable skills in the
            organization will facilitate more people learning skills from other
            disciplines, increasing the
            total skill level of the organization and reducing the impact of losing
            people with unique skills.

            -----Original Message-----
            From: Kurt Heiz [mailto:kurtheiz@...]
            Sent: Thu 9/2/2004 11:22 PM
            To: scrumdevelopment@yahoogroups.com
            Cc:
            Subject: [scrumdevelopment] Re: Are BA's included in the Sprint Team


            As we have about 16 people made up of testers, systems analysts and
            dvelopers, we will be dividing them up into 2 teams at least. We have
            decided that the makeup of the teams would be dependent on what the
            requirements on the Sprint Backlog are.

            Would you not be going against the "Product Owner driving the
            Product" principle by basing the Sprint on what the team can
            accomplish and not the priorities of the Product Owner?

            As about 60% of the product is complete, most of the requirements
            have been defined and documented. When I said the BAs would feed the
            Product Backlog, I meant that while the team is focusing on current
            requirements in the Sprint, the BAs would be outside of the Sprint
            and gathering possible new requirements or detailing high-level
            requirements.

            If you suggest that BAs should definately be part of the team, would
            that imply that activities such as "Gather new requirements re: XYZ
            business fucntion" be listed on the Product Backlog and moved to the
            Sprint Backlog for the BAs to do during the Sprint? Would you not
            only have construction activities on the Product Backlog?

            --- In scrumdevelopment@yahoogroups.com, Dion Stewart
            <dion.stewart@v...> wrote:
            > Are you planning on having the same team for each sprint or are you
            > planning on changing the makeup of the team every time a new sprint
            > begins? A better approach might be to put together a team for the
            > duration of the project and define each Sprint based on what that
            > specific team is able to accomplish.
            >
            > What do you mean when you say the BA's are going to "feed the
            Product
            > Backlog"? Does that mean they are going to gather requirements for
            a
            > specific sprint prior to the sprint where the development of those
            > requirements is completed? If the answer to this question is "yes",
            why
            > are the BAs working on requirements prior to the start of a sprint?
            How
            > do they know which requirements to work on when the sprint has not
            been
            > defined?
            >
            > BAs should definitely be part of the sprint team. In addition,
            > technical writers, testers, and people in any other roles required
            to
            > create production quality software should be part of the sprint
            team.
            >
            > Dion
            >
            >
          • Deb
            I ve not followed this thread from the beginning, but one thing ... It s not one or the other but *both*: - The Product Owner decides the priorities - The team
            Message 5 of 22 , Sep 3, 2004
            • 0 Attachment
              I've not followed this thread from the beginning, but one thing
              struck me here:
              --- In scrumdevelopment@yahoogroups.com, "Kurt Heiz" <kurtheiz@a...>
              wrote:
              > ...
              > Would you not be going against the "Product Owner driving the
              > Product" principle by basing the Sprint on what the team can
              > accomplish and not the priorities of the Product Owner?
              > ...

              It's not one or the other but *both*:
              - The Product Owner decides the priorities
              - The team churns them out as fast as they can accomplish them.

              The team is not allowed to tell the Product Owner what their
              priorities should be (although hopefully the Product Owner is open to
              questions or input from developers).

              Likewise, the Owner is not allowed to tell the team how long it
              should take to develop them. Again, discussion is encouraged.

              As an example, I offer an imaginary conversation with give-and-take
              in which the parties still respect these roles. Time is telescoped in
              this example - this could actually take much longer because
              estimation is involved:

              Owner: I need the Capture Widget and Edit Widget functionality right
              away, it's my first priority

              Team: It looks like that will take us 4 Sprints to complete

              Owner: But I need it all right away! What can we do?

              Team: These are pretty big features, let's break them down and see if
              we can find some less important sub-features to defer.

              Owner: Now that we break it down, I see that I can actually wait for
              [subfeature x] until Sprint 3...

              Team: And are you sure you really need [subfeature y] in Sprint 1?
              Can you explain to us why it is so important?

              Owner: (explains why this is so high priority, and after some
              questions the Team accepts that this is non-negotiable).

              Team: Ok then, what about if we approached it this way (some
              strategy), then we could deliver (something) in Sprint 1 and add the
              improvements in Sprint 2. Or, we could do it all in Sprint 1, but
              that other feature will have to move to Sprint 2...

              In this way, the Team and Owner encourage each other to think
              creatively about how to deliver the *really* most important
              functionality. If they recognise each other's authority, the
              conversation is more constructive, because they don't play power
              games. Instead, they collaborate and try to influence each other.

              In the end, the Owner can simply say: no negotiating - the list of
              priorities stays as it is. In that case, the Team says: ok, then it
              will take 4 Sprints. This is the worst-case scenario, and the least
              constructive approach.

              I hope this accurately captures the spirit of Release and Sprint
              Planning, comments welcome.
              deb
            • Mike Dwyer
              Interesting. Are you assigning roles to the teams and then looking for role specialists to fill those roles? Or are you identifying roles and making sure the
              Message 6 of 22 , Sep 3, 2004
              • 0 Attachment
                Interesting.
                Are you assigning roles to the teams and then looking for role specialists
                to fill those roles? Or are you identifying roles and making sure the people
                on the teams fulfill those roles? Either way, it would seem, you are have
                command of the situation and control of the plan.

                IS that what we are about?
                Michael F. Dwyer

                Mike.Dwyer1@...


                -----Original Message-----
                From: Kurt Heiz [mailto:kurtheiz@...]
                Sent: Friday, September 03, 2004 12:53 AM
                To: scrumdevelopment@yahoogroups.com
                Subject: [scrumdevelopment] Are BA's included in the Sprint Team


                Hi

                We are busy reviewing how we are going to buid the teams for our
                sprints, and we decided to create the teams after the Sprint Backlog
                (SB) has been identified, so that we can create teams to tackle
                specific requirements on the SB. We are currently debating as to
                whether or not it is a good idea to include BA's in these teams, or
                should they sit outside the Sprint and just feed the Product Backlog
                as well as be available to the teams for clarification of issues on
                the SB. Anybody got thoughts on this ?

                Thanks

                Kurt




                To Post a message, send it to: scrumdevelopment@...
                To Unsubscribe, send a blank message to:
                scrumdevelopment-unsubscribe@...
                Yahoo! Groups Links
              • Kurt Heiz
                Even though you have self-organizing teams, surely you should still take the individual skills of the team members into account? If certain work on the Sprint
                Message 7 of 22 , Sep 5, 2004
                • 0 Attachment
                  Even though you have self-organizing teams, surely you should still
                  take the individual skills of the team members into account?
                  If certain work on the Sprint Backlog deals with gathering and
                  clarification of requirements, would it not be feasible to create a
                  team with multiple BAs (as well as other "role" members) in to
                  address those issues?

                  The number of resources dictate that we will have a minimum of two
                  teams in each Sprint.

                  I assume that the people in the teams would naturally take on the
                  tasks that they are experienced and skilled in. Sure, everybody will
                  be involved in the majority of the tasks, but testers will naturally
                  do testing, developers do developing etc.?

                  ">Either way, it would seem, you are have command of the situation
                  and control of the plan."

                  Not control of the plan as such, but guidelines within which to
                  operate. The reason for this is that the client is coming from a
                  fairly autocratic waterfall approach, and I have just not been able
                  to convince the client to let the team do it completely alone.

                  --- In scrumdevelopment@yahoogroups.com, "Mike Dwyer"
                  <mike.dwyer1@c...> wrote:
                  > Interesting.
                  > Are you assigning roles to the teams and then looking for role
                  specialists
                  > to fill those roles? Or are you identifying roles and making sure
                  the people
                  > on the teams fulfill those roles? Either way, it would seem, you
                  are have
                  > command of the situation and control of the plan.
                  >
                  > IS that what we are about?
                  > Michael F. Dwyer
                  >
                  > Mike.Dwyer1@c...
                  >
                  >
                  > -----Original Message-----
                  > From: Kurt Heiz [mailto:kurtheiz@a...]
                  > Sent: Friday, September 03, 2004 12:53 AM
                  > To: scrumdevelopment@yahoogroups.com
                  > Subject: [scrumdevelopment] Are BA's included in the Sprint Team
                  >
                  >
                  > Hi
                  >
                  > We are busy reviewing how we are going to buid the teams for our
                  > sprints, and we decided to create the teams after the Sprint Backlog
                  > (SB) has been identified, so that we can create teams to tackle
                  > specific requirements on the SB. We are currently debating as to
                  > whether or not it is a good idea to include BA's in these teams, or
                  > should they sit outside the Sprint and just feed the Product Backlog
                  > as well as be available to the teams for clarification of issues on
                  > the SB. Anybody got thoughts on this ?
                  >
                  > Thanks
                  >
                  > Kurt
                  >
                  >
                  >
                  >
                  > To Post a message, send it to: scrumdevelopment@e...
                  > To Unsubscribe, send a blank message to:
                  > scrumdevelopment-unsubscribe@e...
                  > Yahoo! Groups Links
                • Victor Szalvay
                  ... I would not recommend this approach. First, you re interfering in the team s self-organization effort by re-shuffling the team to steer them to a
                  Message 8 of 22 , Sep 5, 2004
                  • 0 Attachment
                    --- In scrumdevelopment@yahoogroups.com, "Kurt Heiz" <kurtheiz@a...>
                    wrote:
                    > Even though you have self-organizing teams, surely you should still
                    > take the individual skills of the team members into account?
                    > If certain work on the Sprint Backlog deals with gathering and
                    > clarification of requirements, would it not be feasible to create a
                    > team with multiple BAs (as well as other "role" members) in to
                    > address those issues?

                    I would not recommend this approach. First, you're interfering in
                    the team's self-organization effort by re-shuffling the team
                    to "steer" them to a particular coruse. Second, you're missing the
                    point of cross-functionality. By having developers and testers work
                    through requirements analysis along side the BAs, the teams as a
                    whole will have a better understanding of the requirements.
                    Ultimately, the coders need to build this thing. Do you prefer they
                    hear about the requirements second hand from a BA, or experience them
                    directly from the customer? By segregating people according
                    to "roles" you are encouraging an "over the fence" mentality: "I'm
                    not a BA so if this requirement is wrong (and it sounds wrong to me!)
                    I don't care, it's not my problem!" With Scrum, you make everything
                    everyone's problem.

                    > I assume that the people in the teams would naturally take on the
                    > tasks that they are experienced and skilled in. Sure, everybody
                    will
                    > be involved in the majority of the tasks, but testers will
                    naturally
                    > do testing, developers do developing etc.?
                    >

                    To some extent maybe this will happen. But let the team figure this
                    out. Don't worry about it and don't try to intentionally craft a
                    team that is weighted to do certain things better. If they need
                    help, they will ask for it. I assume you mean manual "testing" in
                    your example, since the coders should be writing automated tests.
                    Even then I don't see why coders don't manually test their own stuff.


                    >> ">Either way, it would seem, you are have command of the situation
                    >> and control of the plan."
                    >
                    > Not control of the plan as such, but guidelines within which to
                    > operate. The reason for this is that the client is coming from a
                    > fairly autocratic waterfall approach, and I have just not been able
                    > to convince the client to let the team do it completely alone.
                    >
                    All I can say is that if you don't give the team total control they
                    won't take real ownership and you might as well scrap this Scrum
                    thing. I know it's very difficult to do, but if you let go they will
                    know what to do. They've had the training wheels on for long enough.
                    If you take them off you'll find that they can ride their bikes
                    better than you or the client can.

                    -- Victor Szalvay
                    http://www.danube.com/
                  • Kurt Heiz
                    So, in terms of not weighting the teams, do you suggest we split the BAs, Systems Analysts, Developers and testers into two even teams as possible? ... What
                    Message 9 of 22 , Sep 5, 2004
                    • 0 Attachment
                      So, in terms of not weighting the teams, do you suggest we split the
                      BAs, Systems Analysts, Developers and testers into two even teams as
                      possible?

                      >All I can say is that if you don't give the team total control they
                      >won't take real ownership and you might as well scrap this Scrum
                      >thing.

                      What about guidelines/standards for the teams to operate within? Do
                      you enforce UML use cases for the BA's, Class diagrams for the
                      developers etc.? Or leave it up to the team?

                      I know these questions seem like we are trying to cater for every
                      eventuality when we should stay Agile.....there is just enormous
                      pressure on this project to succeed in the next 9 months, and we want
                      to be sure we get it right the first time.

                      Kurt
                      --- In scrumdevelopment@yahoogroups.com, "Victor Szalvay"
                      <victor@d...> wrote:
                      > --- In scrumdevelopment@yahoogroups.com, "Kurt Heiz"
                      <kurtheiz@a...>
                      > wrote:
                      > > Even though you have self-organizing teams, surely you should
                      still
                      > > take the individual skills of the team members into account?
                      > > If certain work on the Sprint Backlog deals with gathering and
                      > > clarification of requirements, would it not be feasible to create
                      a
                      > > team with multiple BAs (as well as other "role" members) in to
                      > > address those issues?
                      >
                      > I would not recommend this approach. First, you're interfering in
                      > the team's self-organization effort by re-shuffling the team
                      > to "steer" them to a particular coruse. Second, you're missing the
                      > point of cross-functionality. By having developers and testers
                      work
                      > through requirements analysis along side the BAs, the teams as a
                      > whole will have a better understanding of the requirements.
                      > Ultimately, the coders need to build this thing. Do you prefer
                      they
                      > hear about the requirements second hand from a BA, or experience
                      them
                      > directly from the customer? By segregating people according
                      > to "roles" you are encouraging an "over the fence" mentality: "I'm
                      > not a BA so if this requirement is wrong (and it sounds wrong to
                      me!)
                      > I don't care, it's not my problem!" With Scrum, you make
                      everything
                      > everyone's problem.
                      >
                      > > I assume that the people in the teams would naturally take on the
                      > > tasks that they are experienced and skilled in. Sure, everybody
                      > will
                      > > be involved in the majority of the tasks, but testers will
                      > naturally
                      > > do testing, developers do developing etc.?
                      > >
                      >
                      > To some extent maybe this will happen. But let the team figure
                      this
                      > out. Don't worry about it and don't try to intentionally craft a
                      > team that is weighted to do certain things better. If they need
                      > help, they will ask for it. I assume you mean manual "testing" in
                      > your example, since the coders should be writing automated tests.
                      > Even then I don't see why coders don't manually test their own
                      stuff.
                      >
                      >
                      > >> ">Either way, it would seem, you are have command of the
                      situation
                      > >> and control of the plan."
                      > >
                      > > Not control of the plan as such, but guidelines within which to
                      > > operate. The reason for this is that the client is coming from a
                      > > fairly autocratic waterfall approach, and I have just not been
                      able
                      > > to convince the client to let the team do it completely alone.
                      > >
                      > All I can say is that if you don't give the team total control they
                      > won't take real ownership and you might as well scrap this Scrum
                      > thing. I know it's very difficult to do, but if you let go they
                      will
                      > know what to do. They've had the training wheels on for long
                      enough.
                      > If you take them off you'll find that they can ride their bikes
                      > better than you or the client can.
                      >
                      > -- Victor Szalvay
                      > http://www.danube.com/
                    • Ron Jeffries
                      ... Remind me again why you need two teams? ... The Agile answer is to leave it up to the team. I m interested in your thoughts though. Will use cases make the
                      Message 10 of 22 , Sep 5, 2004
                      • 0 Attachment
                        On Sunday, September 5, 2004, at 8:46:57 PM, Kurt Heiz wrote:

                        > So, in terms of not weighting the teams, do you suggest we split the
                        > BAs, Systems Analysts, Developers and testers into two even teams as
                        > possible?

                        Remind me again why you need two teams?

                        >>All I can say is that if you don't give the team total control they
                        >>won't take real ownership and you might as well scrap this Scrum
                        >>thing.

                        > What about guidelines/standards for the teams to operate within? Do
                        > you enforce UML use cases for the BA's, Class diagrams for the
                        > developers etc.? Or leave it up to the team?

                        The Agile answer is to leave it up to the team.

                        I'm interested in your thoughts though. Will use cases make the product go
                        faster or be better than having the BAs talk with the developers? Will
                        class diagrams help the developers? When and how?

                        > I know these questions seem like we are trying to cater for every
                        > eventuality when we should stay Agile.....there is just enormous
                        > pressure on this project to succeed in the next 9 months, and we want
                        > to be sure we get it right the first time.

                        If you're doing Scrum, you'll be shipping running tested software every
                        single month. If something isn't working, you should be able to see it very
                        clearly.

                        Some people even do two-week Sprints, for faster feedback.

                        Ron Jeffries
                        www.XProgramming.com
                        Changing your problem-solving style is about as painless as changing your
                        shoes, socks, and spleen. -- Don't Feed the Hog
                      • Kurt Heiz
                        ... We have a group of 18 people and we aiming for the SCRUM recomendation of 6-9 people per team, hence the two teams. ... product go ... Will ... The use
                        Message 11 of 22 , Sep 5, 2004
                        • 0 Attachment
                          > Remind me again why you need two teams?

                          We have a group of 18 people and we aiming for the SCRUM
                          recomendation of 6-9 people per team, hence the two teams.


                          > I'm interested in your thoughts though. Will use cases make the
                          product go
                          > faster or be better than having the BAs talk with the developers?
                          Will
                          > class diagrams help the developers? When and how?

                          The use cases will used be to capture and keep a record of
                          requirements coming in. The idea is for the BAs to spend the time
                          with the developers working through and clarifying an issued with
                          regars to the use cases and not for the developers to work strictly
                          from the use cases.
                          With regards to the class diagrams (or any other UML diagrams we
                          might choose to use), the idea again is to record the work being
                          done, albeit with lightweight documentation. You still need to
                          capture what exists within the system for reference, training new
                          developers and understanding the big picture.
                          We have decided that we do want documentation, but only documentation
                          that adds value, that can be used in the future, and not just end up
                          gathering dust on the shelves. We are currently working through just
                          exactly WHAT documentation we feel we wouldneed. I think as we
                          progress with SCRUM we will find that we might need less and less
                          documentation, but for now there are certain guidelines that we feel
                          should be followed.

                          Kurt

                          --- In scrumdevelopment@yahoogroups.com, Ron Jeffries <jeffries@d...>
                          wrote:
                          > On Sunday, September 5, 2004, at 8:46:57 PM, Kurt Heiz wrote:
                          >
                          > > So, in terms of not weighting the teams, do you suggest we split
                          the
                          > > BAs, Systems Analysts, Developers and testers into two even teams
                          as
                          > > possible?
                          >
                          > Remind me again why you need two teams?
                          >
                          > >>All I can say is that if you don't give the team total control
                          they
                          > >>won't take real ownership and you might as well scrap this Scrum
                          > >>thing.
                          >
                          > > What about guidelines/standards for the teams to operate within?
                          Do
                          > > you enforce UML use cases for the BA's, Class diagrams for the
                          > > developers etc.? Or leave it up to the team?
                          >
                          > The Agile answer is to leave it up to the team.
                          >
                          > I'm interested in your thoughts though. Will use cases make the
                          product go
                          > faster or be better than having the BAs talk with the developers?
                          Will
                          > class diagrams help the developers? When and how?
                          >
                          > > I know these questions seem like we are trying to cater for every
                          > > eventuality when we should stay Agile.....there is just enormous
                          > > pressure on this project to succeed in the next 9 months, and we
                          want
                          > > to be sure we get it right the first time.
                          >
                          > If you're doing Scrum, you'll be shipping running tested software
                          every
                          > single month. If something isn't working, you should be able to see
                          it very
                          > clearly.
                          >
                          > Some people even do two-week Sprints, for faster feedback.
                          >
                          > Ron Jeffries
                          > www.XProgramming.com
                          > Changing your problem-solving style is about as painless as
                          changing your
                          > shoes, socks, and spleen. -- Don't Feed the Hog
                        • Victor Szalvay
                          ... the ... as ... I m just saying I wouldn t split the teams by role, all BAs on one team, all coders on another, etc. This is called pipelining and
                          Message 12 of 22 , Sep 5, 2004
                          • 0 Attachment
                            > "Kurt Heiz" <kurtheiz@a...> wrote:
                            > So, in terms of not weighting the teams, do you suggest we split
                            the
                            > BAs, Systems Analysts, Developers and testers into two even teams
                            as
                            > possible?

                            I'm just saying I wouldn't split the teams by role, all BAs on one
                            team, all coders on another, etc. This is called "pipelining" and
                            sometimes leads to poor results. It's probably not the way to scale
                            your teams if this is "mission critical" from the start since it's
                            known to cause problems sometimes.

                            In fact, I wonder if you're entire group of 18 people should start all
                            at once. Take a look at the team scaling anecdote in Schwaber's gey
                            book. He recommends that you start with 1 team for the first
                            iteration or two, then split the original team members as seeds to
                            start subsequent groups (expertise of the first team goes to all of
                            the others). It's more efficient to get your bearings first with one
                            team and then add the rest of the people.

                            >
                            > What about guidelines/standards for the teams to operate within? Do
                            > you enforce UML use cases for the BA's, Class diagrams for the
                            > developers etc.? Or leave it up to the team?
                            >
                            > I know these questions seem like we are trying to cater for every
                            > eventuality when we should stay Agile.....there is just enormous
                            > pressure on this project to succeed in the next 9 months, and we
                            want
                            > to be sure we get it right the first time.
                            >

                            I know you're worried about failure and everyone feels the same way
                            about their own projects. But Scrum is often brought in when things
                            have gone terribly wrong to resurrect dying projects (see the
                            Primavera case study, for example).

                            Your team presumably knows about UCs, UML, etc., right? If they feel
                            it might add value they will give it a shot. But don't be alarmed if
                            they punt UCs for something more lightweight like User Stories, or if
                            they don't robustly document their design decisions. Agile teams move
                            fast and refactoring is furiously applied, so keeping UML diagrams up
                            to date may be an inefficient means to document the project. For
                            example, some of our customers require us to document our code using
                            UML, but since our design evolves each day we use a simple CASE tool
                            like EA to back-generate UML diagrams from the code when they ask for
                            the documentation. That snapshot we take is irrelevant the next day,
                            but we can generate it for anyone, anytime with minimum effort.

                            What we're trying to say is that Scrum is intentionally and completely
                            silent on requirements and engineering practices. That's how
                            important team self-organization is to success.

                            -- Victor Szalvay
                            http://www.danube.com/
                          • Ken Schwaber
                            People have been taken from cubicles and offices, where the interaction is minimal and all problems belong to the project manager. They are now asked to work
                            Message 13 of 22 , Sep 6, 2004
                            • 0 Attachment
                              People have been taken from cubicles and offices, where the interaction is
                              minimal and all problems belong to the project manager. They are now asked
                              to work together. The benefits are the productivity, the quality, and the
                              joy of socializing again. Except, many aren't used to dealing with the
                              problems of socialization (dealing with the superstar and visa versa). I've
                              found that the soft skills found in facilitation are helpful, and in larger
                              companies these are sometimes provided through HR, either from within HR or
                              acquired from outside. People have to learn to work together. Sometimes they
                              can do this themselves, sometimes someone else has to help them learn how
                              to.
                              Ken

                              -----Original Message-----
                              From: Victor Szalvay [mailto:victor@...]
                              Sent: Sunday, September 05, 2004 7:38 PM
                              To: scrumdevelopment@yahoogroups.com
                              Subject: [scrumdevelopment] Re: Are BA's included in the Sprint Team


                              --- In scrumdevelopment@yahoogroups.com, "Kurt Heiz" <kurtheiz@a...>
                              wrote:
                              > Even though you have self-organizing teams, surely you should still
                              > take the individual skills of the team members into account?
                              > If certain work on the Sprint Backlog deals with gathering and
                              > clarification of requirements, would it not be feasible to create a
                              > team with multiple BAs (as well as other "role" members) in to
                              > address those issues?

                              I would not recommend this approach. First, you're interfering in
                              the team's self-organization effort by re-shuffling the team
                              to "steer" them to a particular coruse. Second, you're missing the
                              point of cross-functionality. By having developers and testers work
                              through requirements analysis along side the BAs, the teams as a
                              whole will have a better understanding of the requirements.
                              Ultimately, the coders need to build this thing. Do you prefer they
                              hear about the requirements second hand from a BA, or experience them
                              directly from the customer? By segregating people according
                              to "roles" you are encouraging an "over the fence" mentality: "I'm
                              not a BA so if this requirement is wrong (and it sounds wrong to me!)
                              I don't care, it's not my problem!" With Scrum, you make everything
                              everyone's problem.

                              > I assume that the people in the teams would naturally take on the
                              > tasks that they are experienced and skilled in. Sure, everybody
                              will
                              > be involved in the majority of the tasks, but testers will
                              naturally
                              > do testing, developers do developing etc.?
                              >

                              To some extent maybe this will happen. But let the team figure this
                              out. Don't worry about it and don't try to intentionally craft a
                              team that is weighted to do certain things better. If they need
                              help, they will ask for it. I assume you mean manual "testing" in
                              your example, since the coders should be writing automated tests.
                              Even then I don't see why coders don't manually test their own stuff.


                              >> ">Either way, it would seem, you are have command of the situation
                              >> and control of the plan."
                              >
                              > Not control of the plan as such, but guidelines within which to
                              > operate. The reason for this is that the client is coming from a
                              > fairly autocratic waterfall approach, and I have just not been able
                              > to convince the client to let the team do it completely alone.
                              >
                              All I can say is that if you don't give the team total control they
                              won't take real ownership and you might as well scrap this Scrum
                              thing. I know it's very difficult to do, but if you let go they will
                              know what to do. They've had the training wheels on for long enough.
                              If you take them off you'll find that they can ride their bikes
                              better than you or the client can.

                              -- Victor Szalvay
                              http://www.danube.com/






                              To Post a message, send it to: scrumdevelopment@...
                              To Unsubscribe, send a blank message to:
                              scrumdevelopment-unsubscribe@...
                              Yahoo! Groups Links
                            • Mike Dwyer
                              Doing a 30 day sprint on a product backlog for just the BA with only BA s involved creates a waterfall model that could look like this: Sprint1 BA s collect
                              Message 14 of 22 , Sep 6, 2004
                              • 0 Attachment
                                Doing a 30 day sprint on a product backlog for just the BA with only BA's
                                involved creates a waterfall model that could look like this:
                                Sprint1 BA's collect data
                                Sprint 2 BA's write stories, use cases, novelettes.
                                Sprint 3 Customers, change mind after 2 months
                                Sprint 4 BA's rewrite Specs
                                Sprint 5 Customers kill project
                                Sprint6 BA's train H1-B's
                                Sprint 7 BA's write
                                resumes.
                                Michael F. Dwyer

                                Mike.Dwyer1@...
                                978 683 3439


                                -----Original Message-----
                                From: Victor Szalvay [mailto:victor@...]
                                Sent: Monday, September 06, 2004 2:09 AM
                                To: scrumdevelopment@yahoogroups.com
                                Subject: [scrumdevelopment] Re: Are BA's included in the Sprint Team

                                > "Kurt Heiz" <kurtheiz@a...> wrote:
                                > So, in terms of not weighting the teams, do you suggest we split
                                the
                                > BAs, Systems Analysts, Developers and testers into two even teams
                                as
                                > possible?

                                I'm just saying I wouldn't split the teams by role, all BAs on one
                                team, all coders on another, etc. This is called "pipelining" and
                                sometimes leads to poor results. It's probably not the way to scale
                                your teams if this is "mission critical" from the start since it's
                                known to cause problems sometimes.

                                In fact, I wonder if you're entire group of 18 people should start all
                                at once. Take a look at the team scaling anecdote in Schwaber's gey
                                book. He recommends that you start with 1 team for the first
                                iteration or two, then split the original team members as seeds to
                                start subsequent groups (expertise of the first team goes to all of
                                the others). It's more efficient to get your bearings first with one
                                team and then add the rest of the people.

                                >
                                > What about guidelines/standards for the teams to operate within? Do
                                > you enforce UML use cases for the BA's, Class diagrams for the
                                > developers etc.? Or leave it up to the team?
                                >
                                > I know these questions seem like we are trying to cater for every
                                > eventuality when we should stay Agile.....there is just enormous
                                > pressure on this project to succeed in the next 9 months, and we
                                want
                                > to be sure we get it right the first time.
                                >

                                I know you're worried about failure and everyone feels the same way
                                about their own projects. But Scrum is often brought in when things
                                have gone terribly wrong to resurrect dying projects (see the
                                Primavera case study, for example).

                                Your team presumably knows about UCs, UML, etc., right? If they feel
                                it might add value they will give it a shot. But don't be alarmed if
                                they punt UCs for something more lightweight like User Stories, or if
                                they don't robustly document their design decisions. Agile teams move
                                fast and refactoring is furiously applied, so keeping UML diagrams up
                                to date may be an inefficient means to document the project. For
                                example, some of our customers require us to document our code using
                                UML, but since our design evolves each day we use a simple CASE tool
                                like EA to back-generate UML diagrams from the code when they ask for
                                the documentation. That snapshot we take is irrelevant the next day,
                                but we can generate it for anyone, anytime with minimum effort.

                                What we're trying to say is that Scrum is intentionally and completely
                                silent on requirements and engineering practices. That's how
                                important team self-organization is to success.

                                -- Victor Szalvay
                                http://www.danube.com/




                                To Post a message, send it to: scrumdevelopment@...
                                To Unsubscribe, send a blank message to:
                                scrumdevelopment-unsubscribe@...
                                Yahoo! Groups Links
                              • Hubert Smits
                                Hi Mike, I know that you kno, but this model doesn t meet the Scrum criteria: every sprint hs to deliver working software, other artefacts are irrelevant.
                                Message 15 of 22 , Sep 6, 2004
                                • 0 Attachment
                                  Hi Mike,

                                  I know that you kno, but this model doesn't meet the Scrum criteria:
                                  every sprint hs to deliver working software, other artefacts are
                                  irrelevant. Hense they're not Scrumming.

                                  --Hubert


                                  On Mon, 6 Sep 2004 09:59:01 -0400, Mike Dwyer <mike.dwyer1@...> wrote:
                                  > Doing a 30 day sprint on a product backlog for just the BA with only BA's
                                  > involved creates a waterfall model that could look like this:
                                  > Sprint1 BA's collect data
                                  > Sprint 2 BA's write stories, use cases, novelettes.
                                  > Sprint 3 Customers, change mind after 2 months
                                  > Sprint 4 BA's rewrite Specs
                                  > Sprint 5 Customers kill project
                                  > Sprint6 BA's train H1-B's
                                  > Sprint 7 BA's write
                                  > resumes.
                                  > Michael F. Dwyer
                                  >
                                  > Mike.Dwyer1@...
                                  > 978 683 3439
                                  >
                                  >
                                  >
                                  >
                                  > -----Original Message-----
                                  > From: Victor Szalvay [mailto:victor@...]
                                  > Sent: Monday, September 06, 2004 2:09 AM
                                  > To: scrumdevelopment@yahoogroups.com
                                  > Subject: [scrumdevelopment] Re: Are BA's included in the Sprint Team
                                  >
                                  > > "Kurt Heiz" <kurtheiz@a...> wrote:
                                  > > So, in terms of not weighting the teams, do you suggest we split
                                  > the
                                  > > BAs, Systems Analysts, Developers and testers into two even teams
                                  > as
                                  > > possible?
                                  >
                                  > I'm just saying I wouldn't split the teams by role, all BAs on one
                                  > team, all coders on another, etc. This is called "pipelining" and
                                  > sometimes leads to poor results. It's probably not the way to scale
                                  > your teams if this is "mission critical" from the start since it's
                                  > known to cause problems sometimes.
                                  >
                                  > In fact, I wonder if you're entire group of 18 people should start all
                                  > at once. Take a look at the team scaling anecdote in Schwaber's gey
                                  > book. He recommends that you start with 1 team for the first
                                  > iteration or two, then split the original team members as seeds to
                                  > start subsequent groups (expertise of the first team goes to all of
                                  > the others). It's more efficient to get your bearings first with one
                                  > team and then add the rest of the people.
                                  >
                                  > >
                                  > > What about guidelines/standards for the teams to operate within? Do
                                  > > you enforce UML use cases for the BA's, Class diagrams for the
                                  > > developers etc.? Or leave it up to the team?
                                  > >
                                  > > I know these questions seem like we are trying to cater for every
                                  > > eventuality when we should stay Agile.....there is just enormous
                                  > > pressure on this project to succeed in the next 9 months, and we
                                  > want
                                  > > to be sure we get it right the first time.
                                  > >
                                  >
                                  > I know you're worried about failure and everyone feels the same way
                                  > about their own projects. But Scrum is often brought in when things
                                  > have gone terribly wrong to resurrect dying projects (see the
                                  > Primavera case study, for example).
                                  >
                                  > Your team presumably knows about UCs, UML, etc., right? If they feel
                                  > it might add value they will give it a shot. But don't be alarmed if
                                  > they punt UCs for something more lightweight like User Stories, or if
                                  > they don't robustly document their design decisions. Agile teams move
                                  > fast and refactoring is furiously applied, so keeping UML diagrams up
                                  > to date may be an inefficient means to document the project. For
                                  > example, some of our customers require us to document our code using
                                  > UML, but since our design evolves each day we use a simple CASE tool
                                  > like EA to back-generate UML diagrams from the code when they ask for
                                  > the documentation. That snapshot we take is irrelevant the next day,
                                  > but we can generate it for anyone, anytime with minimum effort.
                                  >
                                  > What we're trying to say is that Scrum is intentionally and completely
                                  > silent on requirements and engineering practices. That's how
                                  > important team self-organization is to success.
                                  >
                                  > -- Victor Szalvay
                                  > http://www.danube.com/
                                  >
                                  > To Post a message, send it to: scrumdevelopment@...
                                  > To Unsubscribe, send a blank message to:
                                  > scrumdevelopment-unsubscribe@...
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  > To Post a message, send it to: scrumdevelopment@...
                                  > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                                  > Yahoo! Groups Links
                                  >
                                  >
                                  >
                                  >
                                  >
                                • Mike Dwyer
                                  Agreed. But if you choose to move a customer through one specialty after another specialty, such as a BA to Design then what other choice do you have other
                                  Message 16 of 22 , Sep 6, 2004
                                  • 0 Attachment
                                    Agreed. But if you choose to move a customer through one specialty after
                                    another specialty, such as a BA to Design then what other choice do you have
                                    other than a waterfall?

                                    Ergo, can this be Scrum.

                                    Michael F. Dwyer

                                    Mike.Dwyer1@...
                                    978 683 3439


                                    -----Original Message-----
                                    From: Hubert Smits [mailto:hubert.smits@...]
                                    Sent: Monday, September 06, 2004 11:28 AM
                                    To: scrumdevelopment@yahoogroups.com
                                    Subject: Re: [scrumdevelopment] Re: Are BA's included in the Sprint Team

                                    Hi Mike,

                                    I know that you kno, but this model doesn't meet the Scrum criteria:
                                    every sprint hs to deliver working software, other artefacts are
                                    irrelevant. Hense they're not Scrumming.

                                    --Hubert


                                    On Mon, 6 Sep 2004 09:59:01 -0400, Mike Dwyer <mike.dwyer1@...>
                                    wrote:
                                    > Doing a 30 day sprint on a product backlog for just the BA with only BA's
                                    > involved creates a waterfall model that could look like this:
                                    > Sprint1 BA's collect data
                                    > Sprint 2 BA's write stories, use cases, novelettes.
                                    > Sprint 3 Customers, change mind after 2 months
                                    > Sprint 4 BA's rewrite Specs
                                    > Sprint 5 Customers kill project
                                    > Sprint6 BA's train H1-B's
                                    > Sprint 7 BA's write
                                    > resumes.
                                    > Michael F. Dwyer
                                    >
                                    > Mike.Dwyer1@...
                                    > 978 683 3439
                                    >
                                    >
                                    >
                                    >
                                    > -----Original Message-----
                                    > From: Victor Szalvay [mailto:victor@...]
                                    > Sent: Monday, September 06, 2004 2:09 AM
                                    > To: scrumdevelopment@yahoogroups.com
                                    > Subject: [scrumdevelopment] Re: Are BA's included in the Sprint Team
                                    >
                                    > > "Kurt Heiz" <kurtheiz@a...> wrote:
                                    > > So, in terms of not weighting the teams, do you suggest we split
                                    > the
                                    > > BAs, Systems Analysts, Developers and testers into two even teams
                                    > as
                                    > > possible?
                                    >
                                    > I'm just saying I wouldn't split the teams by role, all BAs on one
                                    > team, all coders on another, etc. This is called "pipelining" and
                                    > sometimes leads to poor results. It's probably not the way to scale
                                    > your teams if this is "mission critical" from the start since it's
                                    > known to cause problems sometimes.
                                    >
                                    > In fact, I wonder if you're entire group of 18 people should start all
                                    > at once. Take a look at the team scaling anecdote in Schwaber's gey
                                    > book. He recommends that you start with 1 team for the first
                                    > iteration or two, then split the original team members as seeds to
                                    > start subsequent groups (expertise of the first team goes to all of
                                    > the others). It's more efficient to get your bearings first with one
                                    > team and then add the rest of the people.
                                    >
                                    > >
                                    > > What about guidelines/standards for the teams to operate within? Do
                                    > > you enforce UML use cases for the BA's, Class diagrams for the
                                    > > developers etc.? Or leave it up to the team?
                                    > >
                                    > > I know these questions seem like we are trying to cater for every
                                    > > eventuality when we should stay Agile.....there is just enormous
                                    > > pressure on this project to succeed in the next 9 months, and we
                                    > want
                                    > > to be sure we get it right the first time.
                                    > >
                                    >
                                    > I know you're worried about failure and everyone feels the same way
                                    > about their own projects. But Scrum is often brought in when things
                                    > have gone terribly wrong to resurrect dying projects (see the
                                    > Primavera case study, for example).
                                    >
                                    > Your team presumably knows about UCs, UML, etc., right? If they feel
                                    > it might add value they will give it a shot. But don't be alarmed if
                                    > they punt UCs for something more lightweight like User Stories, or if
                                    > they don't robustly document their design decisions. Agile teams move
                                    > fast and refactoring is furiously applied, so keeping UML diagrams up
                                    > to date may be an inefficient means to document the project. For
                                    > example, some of our customers require us to document our code using
                                    > UML, but since our design evolves each day we use a simple CASE tool
                                    > like EA to back-generate UML diagrams from the code when they ask for
                                    > the documentation. That snapshot we take is irrelevant the next day,
                                    > but we can generate it for anyone, anytime with minimum effort.
                                    >
                                    > What we're trying to say is that Scrum is intentionally and completely
                                    > silent on requirements and engineering practices. That's how
                                    > important team self-organization is to success.
                                    >
                                    > -- Victor Szalvay
                                    > http://www.danube.com/
                                    >
                                    > To Post a message, send it to: scrumdevelopment@...
                                    > To Unsubscribe, send a blank message to:
                                    > scrumdevelopment-unsubscribe@...
                                    > Yahoo! Groups Links
                                    >
                                    >
                                    > To Post a message, send it to: scrumdevelopment@...
                                    > To Unsubscribe, send a blank message to:
                                    scrumdevelopment-unsubscribe@...
                                    > Yahoo! Groups Links
                                    >
                                    >
                                    >
                                    >
                                    >



                                    To Post a message, send it to: scrumdevelopment@...
                                    To Unsubscribe, send a blank message to:
                                    scrumdevelopment-unsubscribe@...
                                    Yahoo! Groups Links
                                  • Steven Gordon
                                    There is a very close relationship between the concept of specialization and the concept of phases. As long as we think of (and teach) software development as
                                    Message 17 of 22 , Sep 6, 2004
                                    • 0 Attachment
                                      There is a very close relationship between the concept of specialization and the concept of phases. As long as we think of (and teach) software development as a set of specialized skills, we will have a very difficult time convincing many people to build software holistically instead of phastically.

                                      The best answer is for the BAs to be willing to work together with other software developers, in the process learning other skills and teaching their skills to others. If the BAs' attitude is that they have to work separately and everyone else has to wait for them to do their jobs before they can proceed, you will never be doing agile software development.

                                      -----Original Message-----
                                      From: Mike Dwyer [mailto:mike.dwyer1@...]
                                      Sent: Mon 9/6/2004 8:32 AM
                                      To: scrumdevelopment@yahoogroups.com
                                      Cc:
                                      Subject: RE: [scrumdevelopment] Re: Are BA's included in the Sprint Team


                                      Agreed. But if you choose to move a customer through one specialty after
                                      another specialty, such as a BA to Design then what other choice do you have
                                      other than a waterfall?

                                      Ergo, can this be Scrum.

                                      Michael F. Dwyer

                                      Mike.Dwyer1@...
                                      978 683 3439


                                      -----Original Message-----
                                      From: Hubert Smits [mailto:hubert.smits@...]
                                      Sent: Monday, September 06, 2004 11:28 AM
                                      To: scrumdevelopment@yahoogroups.com
                                      Subject: Re: [scrumdevelopment] Re: Are BA's included in the Sprint Team

                                      Hi Mike,

                                      I know that you kno, but this model doesn't meet the Scrum criteria:
                                      every sprint hs to deliver working software, other artefacts are
                                      irrelevant. Hense they're not Scrumming.

                                      --Hubert


                                      On Mon, 6 Sep 2004 09:59:01 -0400, Mike Dwyer <mike.dwyer1@...>
                                      wrote:
                                      > Doing a 30 day sprint on a product backlog for just the BA with only BA's
                                      > involved creates a waterfall model that could look like this:
                                      > Sprint1 BA's collect data
                                      > Sprint 2 BA's write stories, use cases, novelettes.
                                      > Sprint 3 Customers, change mind after 2 months
                                      > Sprint 4 BA's rewrite Specs
                                      > Sprint 5 Customers kill project
                                      > Sprint6 BA's train H1-B's
                                      > Sprint 7 BA's write
                                      > resumes.
                                      > Michael F. Dwyer
                                      >
                                      > Mike.Dwyer1@...
                                      > 978 683 3439
                                      >
                                      >
                                      >
                                      >
                                      > -----Original Message-----
                                      > From: Victor Szalvay [mailto:victor@...]
                                      > Sent: Monday, September 06, 2004 2:09 AM
                                      > To: scrumdevelopment@yahoogroups.com
                                      > Subject: [scrumdevelopment] Re: Are BA's included in the Sprint Team
                                      >
                                      > > "Kurt Heiz" <kurtheiz@a...> wrote:
                                      > > So, in terms of not weighting the teams, do you suggest we split
                                      > the
                                      > > BAs, Systems Analysts, Developers and testers into two even teams
                                      > as
                                      > > possible?
                                      >
                                      > I'm just saying I wouldn't split the teams by role, all BAs on one
                                      > team, all coders on another, etc. This is called "pipelining" and
                                      > sometimes leads to poor results. It's probably not the way to scale
                                      > your teams if this is "mission critical" from the start since it's
                                      > known to cause problems sometimes.
                                      >
                                      > In fact, I wonder if you're entire group of 18 people should start all
                                      > at once. Take a look at the team scaling anecdote in Schwaber's gey
                                      > book. He recommends that you start with 1 team for the first
                                      > iteration or two, then split the original team members as seeds to
                                      > start subsequent groups (expertise of the first team goes to all of
                                      > the others). It's more efficient to get your bearings first with one
                                      > team and then add the rest of the people.
                                      >
                                      > >
                                      > > What about guidelines/standards for the teams to operate within? Do
                                      > > you enforce UML use cases for the BA's, Class diagrams for the
                                      > > developers etc.? Or leave it up to the team?
                                      > >
                                      > > I know these questions seem like we are trying to cater for every
                                      > > eventuality when we should stay Agile.....there is just enormous
                                      > > pressure on this project to succeed in the next 9 months, and we
                                      > want
                                      > > to be sure we get it right the first time.
                                      > >
                                      >
                                      > I know you're worried about failure and everyone feels the same way
                                      > about their own projects. But Scrum is often brought in when things
                                      > have gone terribly wrong to resurrect dying projects (see the
                                      > Primavera case study, for example).
                                      >
                                      > Your team presumably knows about UCs, UML, etc., right? If they feel
                                      > it might add value they will give it a shot. But don't be alarmed if
                                      > they punt UCs for something more lightweight like User Stories, or if
                                      > they don't robustly document their design decisions. Agile teams move
                                      > fast and refactoring is furiously applied, so keeping UML diagrams up
                                      > to date may be an inefficient means to document the project. For
                                      > example, some of our customers require us to document our code using
                                      > UML, but since our design evolves each day we use a simple CASE tool
                                      > like EA to back-generate UML diagrams from the code when they ask for
                                      > the documentation. That snapshot we take is irrelevant the next day,
                                      > but we can generate it for anyone, anytime with minimum effort.
                                      >
                                      > What we're trying to say is that Scrum is intentionally and completely
                                      > silent on requirements and engineering practices. That's how
                                      > important team self-organization is to success.
                                      >
                                      > -- Victor Szalvay
                                      > http://www.danube.com/
                                      >
                                      > To Post a message, send it to: scrumdevelopment@...
                                      > To Unsubscribe, send a blank message to:
                                      > scrumdevelopment-unsubscribe@...
                                      > Yahoo! Groups Links
                                      >
                                      >
                                      > To Post a message, send it to: scrumdevelopment@...
                                      > To Unsubscribe, send a blank message to:
                                      scrumdevelopment-unsubscribe@...
                                      > Yahoo! Groups Links
                                      >
                                      >
                                      >
                                      >
                                      >



                                      To Post a message, send it to: scrumdevelopment@...
                                      To Unsubscribe, send a blank message to:
                                      scrumdevelopment-unsubscribe@...
                                      Yahoo! Groups Links









                                      To Post a message, send it to: scrumdevelopment@...
                                      To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...



                                      Yahoo! Groups Sponsor
                                      <http://us.ard.yahoo.com/SIG=129mv0r1u/M=296572.5305651.6444487.3001176/D=groups/S=1707209021:HM/EXP=1094571202/A=2343726/R=0/SIG=12ip0focf/*http://clk.atdmt.com/VON/go/yhxxxvon01900091von/direct/01/&time=1094484802596300> <http://us.ard.yahoo.com/SIG=129mv0r1u/M=296572.5305651.6444487.3001176/D=groups/S=1707209021:HM/EXP=1094571202/A=2343726/R=1/SIG=12ip0focf/*http://clk.atdmt.com/VON/go/yhxxxvon01900091von/direct/01/&time=1094484802596300>

                                      Get unlimited calls to

                                      U.S./Canada

                                      <http://view.atdmt.com/VON/view/yhxxxvon01900091von/direct/01/&time=1094484802596300>
                                      <http://us.adserver.yahoo.com/l?M=296572.5305651.6444487.3001176/D=groups/S=:HM/A=2343726/rand=867041653>


                                      _____

                                      Yahoo! Groups Links


                                      * To visit your group on the web, go to:
                                      http://groups.yahoo.com/group/scrumdevelopment/

                                      * To unsubscribe from this group, send an email to:
                                      scrumdevelopment-unsubscribe@yahoogroups.com <mailto:scrumdevelopment-unsubscribe@yahoogroups.com?subject=Unsubscribe>

                                      * Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> .
                                    • Hubert Smits
                                      Hi Mike, No, to me this is not Scrum, but you may want to call me a purist. The core of Scrum is delivering working software every 30 days. Working software is
                                      Message 18 of 22 , Sep 6, 2004
                                      • 0 Attachment
                                        Hi Mike,

                                        No, to me this is not Scrum, but you may want to call me a purist. The
                                        core of Scrum is delivering working software every 30 days. Working
                                        software is what adds value to the bottom line for the customer, the
                                        other artefacts don't.

                                        You may want to argue that a waterfall of scrums is better then a
                                        waterfall of SSDM (or any other plan driven method), but it does not
                                        give the customer the option to change his mind during the development
                                        process. As Boehm argues in his latest book: only a few projects
                                        satisfy the requirement to decide on a plan driven method, no changes
                                        after analysis.

                                        --Hubert


                                        On Mon, 6 Sep 2004 11:32:42 -0400, Mike Dwyer <mike.dwyer1@...> wrote:
                                        > Agreed. But if you choose to move a customer through one specialty after
                                        > another specialty, such as a BA to Design then what other choice do you have
                                        > other than a waterfall?
                                        >
                                        > Ergo, can this be Scrum.
                                        >
                                        > Michael F. Dwyer
                                        >
                                        > Mike.Dwyer1@...
                                        > 978 683 3439
                                        >
                                        >
                                        >
                                        >
                                        > -----Original Message-----
                                        > From: Hubert Smits [mailto:hubert.smits@...]
                                        > Sent: Monday, September 06, 2004 11:28 AM
                                        > To: scrumdevelopment@yahoogroups.com
                                        > Subject: Re: [scrumdevelopment] Re: Are BA's included in the Sprint Team
                                        >
                                        > Hi Mike,
                                        >
                                        > I know that you kno, but this model doesn't meet the Scrum criteria:
                                        > every sprint hs to deliver working software, other artefacts are
                                        > irrelevant. Hense they're not Scrumming.
                                        >
                                        > --Hubert
                                        >
                                        > On Mon, 6 Sep 2004 09:59:01 -0400, Mike Dwyer <mike.dwyer1@...>
                                        > wrote:
                                        > > Doing a 30 day sprint on a product backlog for just the BA with only BA's
                                        > > involved creates a waterfall model that could look like this:
                                        > > Sprint1 BA's collect data
                                        > > Sprint 2 BA's write stories, use cases, novelettes.
                                        > > Sprint 3 Customers, change mind after 2 months
                                        > > Sprint 4 BA's rewrite Specs
                                        > > Sprint 5 Customers kill project
                                        > > Sprint6 BA's train H1-B's
                                        > > Sprint 7 BA's write
                                        > > resumes.
                                        > > Michael F. Dwyer
                                        > >
                                        > > Mike.Dwyer1@...
                                        > > 978 683 3439
                                        > >
                                        > >
                                        > >
                                        > >
                                        > > -----Original Message-----
                                        > > From: Victor Szalvay [mailto:victor@...]
                                        > > Sent: Monday, September 06, 2004 2:09 AM
                                        > > To: scrumdevelopment@yahoogroups.com
                                        > > Subject: [scrumdevelopment] Re: Are BA's included in the Sprint Team
                                        > >
                                        > > > "Kurt Heiz" <kurtheiz@a...> wrote:
                                        > > > So, in terms of not weighting the teams, do you suggest we split
                                        > > the
                                        > > > BAs, Systems Analysts, Developers and testers into two even teams
                                        > > as
                                        > > > possible?
                                        > >
                                        > > I'm just saying I wouldn't split the teams by role, all BAs on one
                                        > > team, all coders on another, etc. This is called "pipelining" and
                                        > > sometimes leads to poor results. It's probably not the way to scale
                                        > > your teams if this is "mission critical" from the start since it's
                                        > > known to cause problems sometimes.
                                        > >
                                        > > In fact, I wonder if you're entire group of 18 people should start all
                                        > > at once. Take a look at the team scaling anecdote in Schwaber's gey
                                        > > book. He recommends that you start with 1 team for the first
                                        > > iteration or two, then split the original team members as seeds to
                                        > > start subsequent groups (expertise of the first team goes to all of
                                        > > the others). It's more efficient to get your bearings first with one
                                        > > team and then add the rest of the people.
                                        > >
                                        > > >
                                        > > > What about guidelines/standards for the teams to operate within? Do
                                        > > > you enforce UML use cases for the BA's, Class diagrams for the
                                        > > > developers etc.? Or leave it up to the team?
                                        > > >
                                        > > > I know these questions seem like we are trying to cater for every
                                        > > > eventuality when we should stay Agile.....there is just enormous
                                        > > > pressure on this project to succeed in the next 9 months, and we
                                        > > want
                                        > > > to be sure we get it right the first time.
                                        > > >
                                        > >
                                        > > I know you're worried about failure and everyone feels the same way
                                        > > about their own projects. But Scrum is often brought in when things
                                        > > have gone terribly wrong to resurrect dying projects (see the
                                        > > Primavera case study, for example).
                                        > >
                                        > > Your team presumably knows about UCs, UML, etc., right? If they feel
                                        > > it might add value they will give it a shot. But don't be alarmed if
                                        > > they punt UCs for something more lightweight like User Stories, or if
                                        > > they don't robustly document their design decisions. Agile teams move
                                        > > fast and refactoring is furiously applied, so keeping UML diagrams up
                                        > > to date may be an inefficient means to document the project. For
                                        > > example, some of our customers require us to document our code using
                                        > > UML, but since our design evolves each day we use a simple CASE tool
                                        > > like EA to back-generate UML diagrams from the code when they ask for
                                        > > the documentation. That snapshot we take is irrelevant the next day,
                                        > > but we can generate it for anyone, anytime with minimum effort.
                                        > >
                                        > > What we're trying to say is that Scrum is intentionally and completely
                                        > > silent on requirements and engineering practices. That's how
                                        > > important team self-organization is to success.
                                        > >
                                        > > -- Victor Szalvay
                                        > > http://www.danube.com/
                                        > >
                                        > > To Post a message, send it to: scrumdevelopment@...
                                        > > To Unsubscribe, send a blank message to:
                                        > > scrumdevelopment-unsubscribe@...
                                        > > Yahoo! Groups Links
                                        > >
                                        > >
                                        > > To Post a message, send it to: scrumdevelopment@...
                                        > > To Unsubscribe, send a blank message to:
                                        > scrumdevelopment-unsubscribe@...
                                        > > Yahoo! Groups Links
                                        > >
                                        > >
                                        > >
                                        > >
                                        > >
                                        >
                                        > To Post a message, send it to: scrumdevelopment@...
                                        > To Unsubscribe, send a blank message to:
                                        > scrumdevelopment-unsubscribe@...
                                        > Yahoo! Groups Links
                                        >
                                        >
                                        > To Post a message, send it to: scrumdevelopment@...
                                        > To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@...
                                        > Yahoo! Groups Links
                                        >
                                        >
                                        >
                                        >
                                        >
                                      Your message has been successfully submitted and would be delivered to recipients shortly.