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

Re: Scrum and Business Analysts

Expand Messages
  • scrummasterbob
    After completing a successful Scrum based development project our team had a bit of an introspective about how and why Scrum worked and out of this came some
    Message 1 of 94 , Nov 4, 2004
    • 0 Attachment
      After completing a successful Scrum based development project our
      team had a bit of an introspective about how and why Scrum worked
      and out of this came some interesting thoughts.

      Our organisation is of a similar composition to the one you describe
      and we approached the project with a combined business
      analyst/project manager, 3 developers with testers and business
      domain experts supplied by the client.

      One of the problems we identified was the inconsistency in how the
      BA (and team in general) was utilised by having the Sprint planning
      and analysis starting at the beginning of the Sprint. My blog post
      ) details this issue and a possible resolution - that of moving the
      Sprint planning and initial analysis of the Sprint backlog to mid
      way into the previous Sprint.

      This allows the team to be better informed about the Sprint backlog
      and make a better decision as to what items the team commit to
      building in the Sprint. The BA's utilisation is more consistent as
      they are busy all the time with 2 weeks of Sprint planning then 2
      weeks of clarification and working closely with the development team
      and business to resolve any issues.

      Another point I must make is that it is all too easy to fall into a
      waterfall approach within the Sprint - we fell for this in one of
      our Sprints and it was terrible! We quickly identified in the Sprint
      review that this should never happen again.

      The prime reason I believe that we reverted to a waterfall in the
      Sprint was because we poorly planned the Sprint, we had inadequate
      analysis and understanding of the Sprint backlog items. This I
      believe is a consequence of the pressure to get the team coding and
      productive. Once our understanding of the work grew we realised we
      had over committed ourselves but by then we were mid Sprint and
      under vast pressure to deliver all this work (more as a pride
      issue). Testing got pushed to the end of the Sprint as we continued
      to code away and as a consequence the overall quality suffered.

      So to summarise,

      There is a role for BA's and I believe with a small adjustment to
      how and when they are utilised they provide good benefits for the
      team performance and ability to deliver consistently each Sprint.

      I AM advocating the BA's understand the Sprint backlog items prior
      to Sprint start at which point the TEAM can make a better judgement
      on what they can acheive.

      I am NOT advocating changing how you work within the Sprint, this
      should remain a highly iterative Code, Test, Refactor affair - avoid
      reverting to a waterfall pattern over the Sprint like the plague.

      For those people that have responded to your initial question along
      the line "start developing or find a new job" I would argue that
      developers cannot replace the functions of a BA - and Scrum is about
      adapting the best you can to solve a problem...in my experience
      having the BA do the initial planning and discovery about the Sprint
      backlog items is crucial to a successful Sprint, equally having them
      available for the initial two weeks of the Sprint as implementation
      starts to help the developer understand in detail what they are
      doing is just as vital. I will be blogging about my experience with
      Pair Programming - however with a twist, using a BA/Business Domain
      Expert (BDE) paired with a developer and my belief that THIS IS THE
      MOST EFFICIENT implementation approach possible.

      Working for a consultancy does raise these questions as they are
      tradionally aligned along fixed roles. Getting BA's to become
      developers, developers to become testers and the general crossing of
      roles is an adaptive process built on iterative attempts at projects
      and inspection that this is right direction to take.


      --- 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
      > 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
      > 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
      > without someone having a good amount of downtime. Since you really
      > cannot develop before analysis and design is complete, and since
      > 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
        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.