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

5099Re: Scrum and Business Analysts

Expand Messages
  • scrummasterbob
    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
      > >
      > >
      > >
      > >
      > >
    • Show all 94 messages in this topic