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

Re: Scrum and Business Analysts

Expand Messages
  • scrummasterbob
    I DO NOT advocate the analysts being one sprint ahead - that is pushing the limits of there being a mismatch in what the customer wants and what you will build
    Message 1 of 94 , Nov 4, 2004
    • 0 Attachment
      I DO NOT advocate the analysts being one sprint ahead - that is
      pushing the limits of there being a mismatch in what the customer
      wants and what you will build - in that month they could completely
      change their minds so wasting this time completely.

      I am saying that one, at most two weeks prior to Sprint start that
      the analysts start DISCOVERING information about the PROBABLE Sprint
      work items so the TEAM can evolve a better approach to how the tasks
      will be tackled and what is realistic to commit to.

      I DO NOT advocate changing how you work IN the Sprint, this MUST
      adhere to granular, testplan, code, test, refactor and I even
      promote, from experience, that a developer should buddy/pair with
      testers/QA/BDE whilst they are IMPLEMENTING the deliverables.

      I also DO NOT agree with you that you should Design, Develop, Test
      unless you are talking about on a very granular, almost daily level -
      what this smacks of is a mini waterfall pattern and one that I
      personally never wish to experience again during a Sprint.

      --- In scrumdevelopment@yahoogroups.com, Hubert Smits
      <hubert.smits@g...> wrote:
      > Fully agree with Boris here, and couldn't have worded it better.
      The
      > idea of a BA being a sprint ahead and QA being 1 sprint behind does
      > not make sense to me. A sprint delivers working software, and
      executes
      > all work involved: design, develop, test. Full stop. A next sprint
      is
      > a new start, and all previous plans can become void, because the
      > busines priorities change. When this happens in the suggested
      approach
      > then the work of the full sprint becomes useless (it's not tested)
      and
      > the whole team goes waiting for a full sprint for the BAs to
      complete
      > the analysis for the next sprint.
      >
      > Go back to the principles of Scrum: every Sprint delivers working
      > software that can be released to the users.
      >
      > Don't try to push a square peg into a round hole, it won't work and
      > you'll end up without any working process at all, not waterfall,
      not
      > Scrum, just confusion all around.
      >
      > --Hubert
      >
      >
      > On Thu, 4 Nov 2004 11:52:36 +0100, Boris Gloger
      <boris.gloger@g...> wrote:
      > >
      > > Hello,
      > >
      > > I have a very bad feeling by reading this comment - I read all
      the
      > > time "planning", "be better informed"; "better
      decisions"; "planning
      > > upfront" ; "we poorly planned the Sprint, we had inadequate
      analysis
      > > and understanding of the Sprint backlog items", ....
      > >
      > > A Sprint Planning is a conversation of involved people about the
      > > deliverables they want to deliver at the end of the Sprint. A
      Sprint
      > > Planning is NOT the planning of a sprint. We do not plan, what
      we need
      > > to do but we identify what needs to be done. We do not plan when
      it
      > > needs to be done but how it will be done.
      > >
      > > So it is about co-ordination of people not about planning of
      people.
      > > And again, and again and again ----
      > >
      > > What the hell is an "inadequate analysis" who decides this? When
      is
      > > this decided? A sprint plannning meeting is timeboxed to 4hrs -
      so it
      > > is not possible to make a detailed analysis. To create a detailed
      > > analysis upfront means to jeoperdize the whole process. Shall we
      > > involve the whole team to do the analysis - or only the business
      > > analyst - so the business analyst will DEFINE what needs to be
      done?
      > > She knows all about estimates.....
      > >
      > > If you want to have my opinion about what the role of the
      business
      > > analyst might be .... he is the project owner/the proxy
      customer - or
      > > he is the one who explaines during the development phase the
      business
      > > processes.
      > >
      > > Boris
      > >
      > > On Thu, 04 Nov 2004 09:35:57 -0000, scrummasterbob
      > >
      > >
      > > <developer@j...> wrote:
      > > >
      > > >
      > > > 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
      > > >
      (http://blogs.conchango.com/jamessimmonds/archive/2004/10/28/148.aspx
      > > > ) 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.
      > > >
      > > > James
      > > >
      > > > --- 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.
      > > >
      > > >
      > > > To Post a message, send it to: scrumdevelopment@e...
      > > > To Unsubscribe, send a blank message to: scrumdevelopment-
      unsubscribe@e...
      > > > Yahoo! Groups Links
      > > >
      > > >
      > > >
      > > >
      > > >
      > >
      > >
      > >
      > > To Post a message, send it to: scrumdevelopment@e...
      > > To Unsubscribe, send a blank message to: scrumdevelopment-
      unsubscribe@e...
      > > Yahoo! Groups Links
      > >
      > >
      > >
      > >
      > >
    • 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.