Re: Scrum and Business Analysts
- 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?.
--- In firstname.lastname@example.org, Steven Gordon
> The key point is that it is NOT a different group of peopleparticipating in those other
> phases throwing stuff over the wall to the developers.working in relative isolation
> When you start talking about distinct roles like BAs or QAs
> from the development team, you are moving away from what makesScrum work better
> than the traditional phasistic approaches.Development: A
> Steven Gordon
> -----Original Message-----
> From: woynam [mailto:woyna@c...]
> Sent: Fri 11/5/2004 8:42 AM
> To: email@example.com
> Subject: [scrumdevelopment] Re: Scrum and Business Analysts
> In Craig Larman's new book, "Agile and Iterative
> Manager's Guide," there a diagram on page 113 that shows thelifecycle
> of Scrum. The interesting thing about the diagram is thatthe "Sprint"
> is actually only one phase of overall process, focusing onphases, and
> development. Planning and Staging are treated as separate
> focus on identifying and prioritizing features, andexploring design
> alternatives. I believe this allows the customer to get abetter feel
> for impact of a new/modified feature before it makes it'sway into the
> Sprint Kickoff.processes and
> In my current position, I deal with complex business
> systems that often require *weeks* to define new businessprocesses,
> as they can have far-reaching impact on current users andsystems. In
> addition, given the current business model and systems, afeature may
> have more than one way of being implemented, so we need toanalyze
> several options before we come up with an initial high-levelestimate.
> It must be nice where a feature can be flushed out at a
> meeting, but our world is much more complex than that. Oneof the
> biggest complaints we've had in our Sprint Reviews is thatthe
> features were not sufficiently thought through, and that theteam
> wound up spending most of the sprint "analyzing" the featurebefore
> implementation could take place. In several instances, thesprint
> basically degenerated into a waterfall process, as the onlything
> accomplished was the analysis.to
> By spending some time in a pre-sprint phase, we've been able
> deliver better features and acceptance tests to thedevelopment team
> at the Sprint Kickoff. While we haven't perfected theprocess, it's
> getting better.article "An
> Another good resource is Cara Taber and Martin Fowler's
> Iteration in the Life of an XP Project"where each
> They describe how a 50-person team is broken into 2 groups,
> group takes a set of features through 3 4-week iterations(Planning,
> Development, Rollout) in a pipeline manner.Sathyamoorthy"
> --- In firstname.lastname@example.org, "Arvind
> <arvind@b...> wrote:impletement
> > I work for an organization where we are starting to
> > scrum. We had a few of our developers go in for Scrumtraining and
> > they came back with some very useful information.web and in
> > Being a business analyst, I have been huting around the
> > bookstores as to how a business analyst team would fitinto an IT
> > organization practicing scrum.Business
> > We have an IT organization that consists of teams of
> > Analysts, Developers, QA folks, Project Managers andBusiness users.
> > I understand that scrum reccomends that the same person
> > multiple hats, but that is really not possible here.putting BA
> > In the past I have worked through an organization where we
> > implemented XP successfully and integrated BA and QA by
> 1But within
> > iteration ahead of dev and QA one iteration behind Dev.
> > scrum everyone stays in the same sprint. The BA, Dev andQA folks.
> > So how could all three groups work within the same PByou really
> > without someone having a good amount of downtime. Since
> > cannot develop before analysis and design is complete, andsince
> > cannot QA before dev is complete.
- 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".
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