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

5098Re: Scrum and Business Analysts

Expand Messages
  • scrummasterbob
    Nov 4, 2004
    • 0 Attachment
      Ok, I think I can understand your response to my posting as it does
      use the words plan, planning and analysis rather a lot! Planning is
      I think the wrong word to use, DISCOVERY is more the term I meant.

      Just as in the XP world people make the mis-informed decision that
      XP means NO design
      [http://martinfowler.com/articles/designDead.html%5d, so I think that
      DISCOVERY [analysis] has fallen to the same fate with Scrum.

      > A Sprint Planning is a conversation of involved people about the
      > deliverables they want to deliver at the end of the Sprint.

      Yes I totally agree - the entire TEAM is involved at the start of
      the Sprint about the deliverables, I did NOT suggest otherwise - I
      am suggesting entering the 4 hour time box planning session with
      MORE information, gathered by a resource whom we identified is under
      utilised at the later half of each Sprint.

      > A sprint plannning meeting is timeboxed to 4hrs - so it
      > is not possible to make a detailed analysis.

      Ok so how do YOU deal with a work item that was discussed in 20
      minutes flat and given the consent from the TEAM to build and not
      until mid Sprint do they actually understand that this work item is
      actually 5 times the effort they first believed?

      I can assure you that your TEAM will feel deflated that they, mid
      sprint have been sold down the river and a natural reaction is to
      revert to HERO mode and work crazy hours with an urge to ditch best
      engineering practices (Sorry boss, not time for unit tests, gotta
      code!). Plus you now have to inform your client that you CANNOT
      deliver the work item you committed to at Sprint start. To clarify,
      I'm calling a work item one part of the final deliverable
      functionality here. An additional danger is to de-scope the entire
      work item - with more knowledge about it DISCOVERED up front by the
      BA we might even be able to build a portion of it.

      > 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?

      You should have noticed I highlighted that the TEAM can make a more
      informed decision about what is realistically going to be delivered
      in the Sprint in the usual Sprint planning session - I did NOT
      suggest that the BA has control over WHAT is built - only that the
      BA should DISCOVER more INFORMATION about the Sprint backlog items
      prior to the TEAM discussing them in the normal manner.

      > She knows all about estimates.....

      Oh dear...you're not related to that other poor commentator Boris
      Johnson are you?

      > What the hell is an "inadequate analysis" who decides this?

      The TEAM decide that they have not had enough information about the
      deliverables precisely at the point that they realise they have more
      work than time to deliver it. The work item has snowballed mid
      Sprint as the developers and BDE's are working together and they
      DISCOVER much more complexity about it...but...arrgghh..it's to
      late! Panic will ensure once you realise that you cannot deliver it
      and you WASTE TIME RESOLVING THIS ISSUE NOT IMPLEMENTING IT.

      > he is the one who explaines during the development phase the
      business processes.

      I suggested that the BA work closely, even pair/buddy up directly
      with a developer(s) to resolve issues during the first half of the
      Sprint. By mid Sprint the developers should have enough knowledge
      about the work items that they should need little handholding from
      the BA and can work autonomously with the BDE's.

      I believe I understand how Scrum works - I was part of a hugely
      successful team for many months and we learnt many things about
      Scrum - one of them is inspect and adapt...to apply this to Scrum
      itself WITHOUT breaking the fundamental rules of Scrum is surely the
      way the process itself is under continual refactoring? Are you
      saying it is perfect as it stands?

      Check out this book, "Lean Software Development: An Agile Toolkit"
      and look up "Perspectives of Quality", esp the Disneyland example
      (pg16) - it may enlighten you.

      ...and I hope I've cleared up this mis-used on my part of the
      word "Planning"?


      --- In scrumdevelopment@yahoogroups.com, 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
      > >
      > >
      > >
      > >
      > >
    • Show all 94 messages in this topic