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

Re: Scrum and Business Analysts

Expand Messages
  • scrummasterbob
    Of course - working in a highly collaborative manner is what makes Scrum work so well and I think that it also goes without saying that we shouldn t lose sight
    Message 1 of 94 , Nov 5, 2004
    • 0 Attachment
      Of course - working in a highly collaborative manner is what makes
      Scrum work so well and I think that it also goes without saying that
      we shouldn't lose sight of this - however self organisation will
      naturally gravitate people to the roles they do well.

      I agree that "throwing stuff over the wall" is entirely the wrong
      approach - "throwing stuff into the ring" for the entire team to
      tackle collectively is right and I suggest that BA's are more suited
      to this. If I had a database issue I'd like a DBA to look at it...I
      need to discover information about a business requirement, let the
      BA's at it. We still need to work as a TEAM to tackle the issues and
      requirements once we know more about what we are looking at.

      Another post offered a comment on what their BA did during the
      Sprint and it included a whole raft of "odd jobs" - indeed our own
      BA became the teaboy and yes this did enable the Sprint team to do
      their job more efficiently by removing friction for the "pigs" -
      however is this really the best use of their time? I suggest that a
      BA's time is better spent working *slightly* ahead of the Sprint to
      simply discover complexity and scope of probable backlog items. I am
      not saying this is the entire scope of their role - they need to
      work directly with developers during the sprint to work through the
      items if help is required.

      I believe the key is to ensure that all roles, BA, QA are active and
      productive throughout the entire sprint - consistent utilisation is
      the goal as far as I am concerned. I want the BA's working as hard
      at the end of the sprint as at the start, the same for the QA
      guys...and the way to acheive this is highly iterative cycle of
      code, test, refactor and break the waterfall mentality that specific
      roles are active at specific blocks in the sprint - the sooner you
      get code to the tester the sooner he can test it. The sooner the
      developer knows what he has to develop the sooner it gets to the
      tester...the more information the developer has to write that code
      the more accurately he can write it.

      I would prefer the BA to be either discovering information about the
      backlog items pre sprint and then buddying up with a developer
      during the sprint than having them doing menial tasks once they had
      envisaged their job was done and "thrown things over the wall" to
      the next guy.

      As a Scrum Master is it MY responsiblity to remove impediments, make
      the tea, organise the meetings and ensure there is enough whiteboard
      markers...not my BA's or anyone else whose time is better spent on
      getting working software out the door surely?.

      James


      --- In scrumdevelopment@yahoogroups.com, Steven Gordon
      <sagordon@a...> wrote:
      > The key point is that it is NOT a different group of people
      participating in those other
      > phases throwing stuff over the wall to the developers.
      >
      > When you start talking about distinct roles like BAs or QAs
      working in relative isolation
      > from the development team, you are moving away from what makes
      Scrum work better
      > than the traditional phasistic approaches.
      >
      > Steven Gordon
      > http://sf.asu.edu/
      >
      >
      > -----Original Message-----
      > From: woynam [mailto:woyna@c...]
      > Sent: Fri 11/5/2004 8:42 AM
      > To: scrumdevelopment@yahoogroups.com
      > Cc:
      > Subject: [scrumdevelopment] Re: Scrum and Business Analysts
      >
      >
      >
      > In Craig Larman's new book, "Agile and Iterative
      Development: A
      > Manager's Guide," there a diagram on page 113 that shows the
      lifecycle
      > of Scrum. The interesting thing about the diagram is that
      the "Sprint"
      > is actually only one phase of overall process, focusing on
      > development. Planning and Staging are treated as separate
      phases, and
      > focus on identifying and prioritizing features, and
      exploring design
      > alternatives. I believe this allows the customer to get a
      better feel
      > for impact of a new/modified feature before it makes it's
      way into the
      > Sprint Kickoff.
      >
      > In my current position, I deal with complex business
      processes and
      > systems that often require *weeks* to define new business
      processes,
      > as they can have far-reaching impact on current users and
      systems. In
      > addition, given the current business model and systems, a
      feature may
      > have more than one way of being implemented, so we need to
      analyze
      > several options before we come up with an initial high-level
      estimate.
      >
      > It must be nice where a feature can be flushed out at a
      Sprint Kickoff
      > meeting, but our world is much more complex than that. One
      of the
      > biggest complaints we've had in our Sprint Reviews is that
      the
      > features were not sufficiently thought through, and that the
      team
      > wound up spending most of the sprint "analyzing" the feature
      before
      > implementation could take place. In several instances, the
      sprint
      > basically degenerated into a waterfall process, as the only
      thing
      > accomplished was the analysis.
      >
      > By spending some time in a pre-sprint phase, we've been able
      to
      > deliver better features and acceptance tests to the
      development team
      > at the Sprint Kickoff. While we haven't perfected the
      process, it's
      > getting better.
      >
      > Another good resource is Cara Taber and Martin Fowler's
      article "An
      > Iteration in the Life of an XP Project"
      > (http://www.thoughtworks.com/us/library/IterationXP.pdf).
      >
      > They describe how a 50-person team is broken into 2 groups,
      where each
      > group takes a set of features through 3 4-week iterations
      (Planning,
      > Development, Rollout) in a pipeline manner.
      >
      > Mark
      >
      > --- In scrumdevelopment@yahoogroups.com, "Arvind
      Sathyamoorthy"
      > <arvind@b...> wrote:
      > >
      > > I work for an organization where we are starting to
      impletement
      > > scrum. We had a few of our developers go in for Scrum
      training and
      > > they came back with some very useful information.
      > >
      > > Being a business analyst, I have been huting around the
      web and in
      > > bookstores as to how a business analyst team would fit
      into an IT
      > > organization practicing scrum.
      > >
      > > We have an IT organization that consists of teams of
      Business
      > > Analysts, Developers, QA folks, Project Managers and
      Business users.
      > >
      > > I understand that scrum reccomends that the same person
      wear
      > > multiple hats, but that is really not possible here.
      > >
      > > In the past I have worked through an organization where we
      > > implemented XP successfully and integrated BA and QA by
      putting BA
      > 1
      > > iteration ahead of dev and QA one iteration behind Dev.
      But within
      > > scrum everyone stays in the same sprint. The BA, Dev and
      QA folks.
      > > So how could all three groups work within the same PB
      > simultaneously
      > > without someone having a good amount of downtime. Since
      you really
      > > cannot develop before analysis and design is complete, and
      since
      > you
      > > cannot QA before dev is complete.
    • Ron Jeffries
      For the record: I am not acknowledging plariarism in XP s Planning Game (nor am I asserting it in XBreed). I think the entire topic of plagiarism is bogus,
      Message 94 of 94 , Nov 12, 2004
      • 0 Attachment
        For the record: I am not acknowledging plariarism in XP's Planning Game
        (nor am I asserting it in XBreed). I think the entire topic of plagiarism
        is bogus, divisive, unproductive and wrong.

        My sole mission in entering the Scrum != XP topic was to point out that
        there is but one elephant here. It is not productive to choose practices
        based on whether or not they are part of Scrum or XP or Crystal.

        As for plagiarism,

        "Not only does I deny the allegation, I denies the alligator".

        Ron Jeffries
        www.XProgramming.com
        You can observe a lot by watching. --Yogi Berra

        On Friday, November 12, 2004, at 1:12:37 AM, Mike Beedle wrote:

        > Thank you for your honesty and fairness in the acknowledgement of plagiarism
        > from the XP community -

        > this means a lot to us scrummers, since both, honesty and fairness are part
        > of our core values.



        > Honesty and fairness make the fertile ground that will allow us to get
        > *unity* in the growing

        > Agile Community of the future.



        > Also, your ability to see from someone else's perspective; and your ability
        > to understand "deep issues"

        > without bailing out on bogus arguments is what convinced me of your
        > leadership abilities.



        > I only now get to really know and understand who you are - thank you, you
        > have opened my eyes

        > to a new level of "understanding",

        End quotation from Mike Beedle, on Friday, November 12, 2004, at 1:12:37 AM
      Your message has been successfully submitted and would be delivered to recipients shortly.