Agile_BA_Requirements : Messages : 20-49 of 657

#20

From: "Shane" <shaneh@...>
Date: Mon Sep 21, 2009 4:02 am
Subject: My ideas on where to start

Hi Folks

I'd like to suggest the following as a starting point for this piece of
work:

Can we each write a small section on the Wiki which summarises how we
see the role of the analyst changing (and staying the same?) in Agile
projects.   Links to blogs and articles we've written and perspectives
we respect could also be useful.

Once we have these perspectives we could try to find a (hopefully)
common viewpoint and then provide linkages into the BABOK sections where
we feel Agile methods will change the content, and identify if we feel
the BABOK needs new sections or topics.

How does this work as a way forward?

Cheers

Shane

Reply | Messages in this Topic (5)

#21

From: Chris <chris.matts@...>
Date: Mon Sep 21, 2009 6:09 am
Subject: Re: My ideas on where to start

chrisjmatts1968

Send Email

Hi Shane

Thank you for the suggestion. If you do not mind, we will revisit it in a week or so.

For the next week or so we want to focus on getting the operational aspects up and running, and get a core group set up with access to the yahoo list and the wiki.

That way everyone will be in from the start. The core group will bre set up as moderators of the yahoo group.

I am hoping to convince Ellen Gottenstein to facilitate the early collaboration ( just so I can see her in action ).

Note to all. I've invited people I knew. Are there any people we should also invite. I'm looking for experienced BAs with at least a couple of years Agile experience.

Regards

Chris

Sent from my iPhone

On 21 Sep 2009, at 05:02, "Shane" <shaneh@...> wrote:

Hi Folks

I'd like to suggest the following as a starting point for this piece of
work:

Can we each write a small section on the Wiki which summarises how we
see the role of the analyst changing (and staying the same?) in Agile
projects. Links to blogs and articles we've written and perspectives
we respect could also be useful.

Once we have these perspectives we could try to find a (hopefully)
common viewpoint and then provide linkages into the BABOK sections where
we feel Agile methods will change the content, and identify if we feel
the BABOK needs new sections or topics.

How does this work as a way forward?

Cheers

Shane

Reply | Messages in this Topic (5)

#22

From: "chrisjmatts1968" <chris.matts@...>
Date: Mon Sep 21, 2009 8:23 am
Subject: Agile Alliance Representative

chrisjmatts1968

Send Email

Dear All

Is there anyone out there who is a member of the Agile Alliance board ( your
name might rhyme with "Teaser" )? They could investigate....

1. The benefits we could extract from the Agile Alliance by becoming an AA
programme.

2. The costs ( probably emotionally ) associated.

This person would be responsible for managing the relationship with the Agile
Alliance. They could use it as a way of finding out about the AA 12 step
process.

Regards

Chris

Reply | Messages in this Topic (4)

#23

From: C�sar Idrovo Carrillo <cesaridrovo@...>
Date: Mon Sep 21, 2009 8:29 am
Subject: Re: Agile Alliance Representative

cesar_idrovo

Send Email

Aw alright then... I'll look into it but do bear with me as I am 24h away from relocating to another continent!

Cheers,

"Teaser"

On Sep 21, 2009, at 9:23 AM, chrisjmatts1968 wrote:

Dear All

Is there anyone out there who is a member of the Agile Alliance board ( your name might rhyme with "Teaser" )? They could investigate....

1. The benefits we could extract from the Agile Alliance by becoming an AA programme.

2. The costs ( probably emotionally ) associated.

This person would be responsible for managing the relationship with the Agile Alliance. They could use it as a way of finding out about the AA 12 step process.

Regards

Chris

Reply | Messages in this Topic (4)

#24

From: Chris Matts <chris.matts@...>
Date: Mon Sep 21, 2009 9:15 am
Subject: Re: Agile Alliance Representative

chrisjmatts1968

Send Email

Cheers Mate

No hurry. Sort it when you land in San Fran properly.

I'll give you end of 2009 as the initial deadline. We can negotiate an extention.

Chris

2009/9/21 C�sar Idrovo Carrillo <cesaridrovo@...>

�

Aw alright then... I'll look into it but do bear with me as I am 24h away from relocating to another continent!
Cheers,
"Teaser"

On Sep 21, 2009, at 9:23 AM, chrisjmatts1968 wrote:

Dear All

Is there anyone out there who is a member of the Agile Alliance board ( your name might rhyme with "Teaser" )? They could investigate....

1. The benefits we could extract from the Agile Alliance by becoming an AA programme.

2. The costs ( probably emotionally ) associated.

This person would be responsible for managing the relationship with the Agile Alliance. They could use it as a way of finding out about the AA 12 step process.

Regards

Chris

--
Regards

Chris Matts

Reply | Messages in this Topic (4)

#25

From: ellen@...
Date: Mon Sep 21, 2009 11:16 am
Subject: Re: My ideas on where to start

egottebg

Send Email

Hi All:
ellen (gottesdiener) here -- nice try chris but you did a good job on my
name, but no worries, it's a killer name!). I am writing from Aizu, Japan,
having been just in Osaka and Tokyo on a biz trip, some speaking, book
tour including a talk to the IIBA-Japan chapter where their was a keen
interest in facilitated techniques and agile.

thanks all for joining in; i am a tad 'disabled' from being able to
contribute over the next several weeks -- i'll be here through the end of
the week then away on a client engagement next week and some of the
following week -- essentially not back in my office till oct 8th.

i am trying to follow the emails via limited access, and am grateful to
you chris for getting this going and to you dennis for setting up the wiki
and yahoo group. thank you!

thanks chris for your faith in me as 'facilitator', although online
facilitation of a wiki is a bit different from real time facilitation ;-)

i hope to get some insight from the folks who set up the agile/PM wiki,
ask them for their retrospective comments so we can leverage their
successes and mitigate their regrets in our efforts here on the agile ba
group and wiki.

that said, with my time deficient over the next several weeks, i think it
would be useful to hear how folks would prefer to proceed and gather this
info. for example, Shane made some very useful suggestions.

how would others suggest we proceed?

all the best, and looking forward to collaborating with you'all on this
important work for agile/ba/iiba...

~ ellen

> Hi Shane
>
> Thank you for the suggestion. If you do not mind, we will revisit it
> in a week or so.
>
> For the next week or so we want to focus on getting the operational
> aspects up and running, and get a core group set up with access to the
> yahoo list and the wiki.
>
> That way everyone will be in from the start.  The core group will bre
> set up as moderators of the yahoo group.
>
> I am hoping to convince Ellen Gottenstein to facilitate the early
> collaboration ( just so I can see her in action ).
>
> Note to all. I've invited people I knew. Are there any people we
> should also invite. I'm looking for experienced BAs with at least a
> couple of years Agile experience.
>
> Regards
>
> Chris
>
> Sent from my iPhone
>
> On 21 Sep 2009, at 05:02, "Shane" <shaneh@...> wrote:
>
>>
>> Hi Folks
>>
>> I'd like to suggest the following as a starting point for this piece
>> of
>> work:
>>
>> Can we each write a small section on the Wiki which summarises how we
>> see the role of the analyst changing (and staying the same?) in Agile
>> projects. Links to blogs and articles we've written and perspectives
>> we respect could also be useful.
>>
>> Once we have these perspectives we could try to find a (hopefully)
>> common viewpoint and then provide linkages into the BABOK sections
>> where
>> we feel Agile methods will change the content, and identify if we feel
>> the BABOK needs new sections or topics.
>>
>> How does this work as a way forward?
>>
>> Cheers
>>
>> Shane
>>
>>
>

Reply | Messages in this Topic (5)

#26

From: ellen@...
Date: Mon Sep 21, 2009 11:19 am
Subject: Re: Agile Alliance Representative

egottebg

Send Email

i'm sure any help you can provide will be wonderful, thank you,
teaser/caesar! ;-)
~ ellen


> Aw alright then... I'll look into it but do bear with me as I am 24h
> away from relocating to another continent!
> Cheers,
> "Teaser"
>
>
> On Sep 21, 2009, at 9:23 AM, chrisjmatts1968 wrote:
>
>> Dear All
>>
>> Is there anyone out there who is a member of the Agile Alliance
>> board ( your name might rhyme with "Teaser" )? They could
>> investigate....
>>
>> 1. The benefits we could extract from the Agile Alliance by becoming
>> an AA programme.
>>
>> 2. The costs ( probably emotionally ) associated.
>>
>> This person would be responsible for managing the relationship with
>> the Agile Alliance. They could use it as a way of finding out about
>> the AA 12 step process.
>>
>> Regards
>>
>> Chris
>>
>>
>>
>
>

Reply | Messages in this Topic (4)

#27

From: "chrisjmatts1968" <chris.matts@...>
Date: Mon Sep 21, 2009 4:39 pm
Subject: Initial Activity for the next two weeks.

chrisjmatts1968

Send Email

Dear All

For the next couple of weeks I would like us to focus on two key things.

1. Lets get the right people on the bus! I have invited about 25 people to the
group. I would like others to identify people they think will contribute to a
core group. So far 11 people have signed up to the group. I would like to get
most of the core group ( whoever they decide they are ) signed up before we
start any significant discussions about content or process. Most of this core
group will be set up as moderators on the yahoo group.

2. Start to get the infra-structure in place. The wiki and the community.
Contact and learn from other initiatives such as the PMI group or Opium 3.
Identify how we will get access to the BABOK. And identify a few key roles and
fill them with "interim" candidates.

Please note that there will be two significant parts to this initiative.

The first is to create an Agile Business Analysis Body of Knowledge. This has
NOTHING to do with the IIBA although we hope that Kevin and David will
contribute.

The second is to mine the Agile Analysis Body of Knowledge for the IIBA. This
will be lead by David with the support of an Agile Team lead ( mentored ) by
TBD.

Exact details to be driven out but this is the rough idea.

So far, roles identified are...

Wiki maintenance ( Dennis volunteered )
IIBA leader - ( David Morris )
Agile liaision to IIBA leader - ( Hopefully to identify someone with help of
Greg and Kent as the previous Customer Stage producers )
Agile Alliance liaision ( Cesar Idrovo - He's on the board )

When we start on the knowledge base there will be lots of pain to share ;-)

Experience of yahoo groups indicates it can be a painful and daunting take-on
process if you have to join in the conversation after the bus has left. As such,
please can we hold off discussions about content and structure of the knowledge
base until we have most of the people on board. This should only take a week or
two but will be worth it. For example, I know that Steve Adolph and the Calgary
crowd have already started a similar initiative but they are not signed up yet.
Their experience will be very valuable.

Many thanks

Chris

Reply | Messages in this Topic (4)

#28

From: Agile_BA_Requirements@...
Date: Mon Sep 21, 2009 5:50 pm
Subject: New file uploaded to Agile_BA_Requirements

Agile_BA_Requirements@...

Send Email

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the Agile_BA_Requirements
group.

   File        : /SurveySummary_09212009-1.pdf
   Uploaded by : kevinjbrennan <kevin.brennan@...>
   Description : Survey by IIBA of BAs with Agile Experience

You can access this file at the URL:
http://uk.groups.yahoo.com/group/Agile_BA_Requirements/files/SurveySummary_09212\
009-1.pdf

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/help/uk/groups/files

Regards,

kevinjbrennan <kevin.brennan@...>

Reply | Messages in this Topic (7)

#29

From: "flybynight107" <steve@...>
Date: Mon Sep 21, 2009 5:51 pm
Subject: Vancouver Agile BA Fish bowl

flybynight107

Send Email

Hello Everyone

Its really serendipitous this group is starting just as we started an "Agile BA"
series in Vancouver. Last week we held a joint Agile Vancouver (the local Agile
Methods User group www.agilevancouver.ca) IIBA vancouver chapter fish bowl event
to discuss the challenge of the Agile BA. Over 60 people participated
enthusiastically in this event. We took notes and hopefully when one of us has
enough time, we will post the notes some place.

When we planned this event we had no idea there were plans for this group. My
suggestion is that given the success of this first fish bowl and the interest it
generated, and how it brought the two communities together ( members of the
local IIBA chapter and members of agile vancouver) this is something we may want
to try in other locations. Think of this as a town hall series, getting people
truly involved at the grass roots.

Also there are easily 4 or 5 people in Vancouver who are definitely interested
in moving this topic ahead.

best regards,
Steve Adolph

Reply | Messages in this Topic (4)

#30

From: "kevinjbrennan" <kevin.brennan@...>
Date: Mon Sep 21, 2009 5:59 pm
Subject: Re: New file uploaded to Agile_BA_Requirements

kevinjbrennan

Send Email

Hey everyone,

Back when we were finalizing the current version of the BABOK Guide, we ran a survey of the BA community to find out what analysis techniques people were using. I have uploaded the summary of our findings, filtered to limit the results to BAs who indicated they had experience on agile projects (about a third of respondents). I thought it might be interesting information for this group to have, even though it's not quite the same thing as asking what techniques they use when DOING agile projects.

Reply | Messages in this Topic (7)

#31

From: Chris <chris.matts@...>
Date: Mon Sep 21, 2009 5:57 pm
Subject: Re: Vancouver Agile BA Fish bowl

chrisjmatts1968

Send Email

Steve

Are you sure you live in Vancouver? I could have sworn it was Calgary. ;-)

Please get your 4 or 5 to sign up.

Like the idea of the Goldfish bowl. Might be good to get the IIBA to promote it as well. Kevin, how do we do that?

Thanks

Chris

Sent from my iPhone

On 21 Sep 2009, at 18:51, "flybynight107" <steve@...> wrote:

Hello Everyone

Its really serendipitous this group is starting just as we started an "Agile BA" series in Vancouver. Last week we held a joint Agile Vancouver (the local Agile Methods User group www.agilevancouver.ca) IIBA vancouver chapter fish bowl event to discuss the challenge of the Agile BA. Over 60 people participated enthusiastically in this event. We took notes and hopefully when one of us has enough time, we will post the notes some place.

When we planned this event we had no idea there were plans for this group. My suggestion is that given the success of this first fish bowl and the interest it generated, and how it brought the two communities together ( members of the local IIBA chapter and members of agile vancouver) this is something we may want to try in other locations. Think of this as a town hall series, getting people truly involved at the grass roots.

Also there are easily 4 or 5 people in Vancouver who are definitely interested in moving this topic ahead.

best regards,
Steve Adolph

Reply | Messages in this Topic (4)

#32

From: ellen@...
Date: Tue Sep 22, 2009 12:04 am
Subject: Re: Initial Activity for the next two weeks.

egottebg

Send Email

When I return to US I will contact agile ba's I'm aware of and reach out as well;

Question: when I get names-emails, how do I go about getting them invited to the yahoo group and the wiki?
Thx
Ellen

Sent via BlackBerry by AT&T

From: "chrisjmatts1968"
Date: Mon, 21 Sep 2009 16:39:03 -0000
To: <Agile_BA_Requirements@...>
Subject: [Agile_BA_Requirements] Initial Activity for the next two weeks.

Dear All

For the next couple of weeks I would like us to focus on two key things.

1. Lets get the right people on the bus! I have invited about 25 people to the group. I would like others to identify people they think will contribute to a core group. So far 11 people have signed up to the group. I would like to get most of the core group ( whoever they decide they are ) signed up before we start any significant discussions about content or process. Most of this core group will be set up as moderators on the yahoo group.

2. Start to get the infra-structure in place. The wiki and the community. Contact and learn from other initiatives such as the PMI group or Opium 3. Identify how we will get access to the BABOK. And identify a few key roles and fill them with "interim" candidates.

Please note that there will be two significant parts to this initiative.

The first is to create an Agile Business Analysis Body of Knowledge. This has NOTHING to do with the IIBA although we hope that Kevin and David will contribute.

The second is to mine the Agile Analysis Body of Knowledge for the IIBA. This will be lead by David with the support of an Agile Team lead ( mentored ) by TBD.

Exact details to be driven out but this is the rough idea.

So far, roles identified are...

Wiki maintenance ( Dennis volunteered )
IIBA leader - ( David Morris )
Agile liaision to IIBA leader - ( Hopefully to identify someone with help of Greg and Kent as the previous Customer Stage producers )
Agile Alliance liaision ( Cesar Idrovo - He's on the board )

When we start on the knowledge base there will be lots of pain to share ;-)

Experience of yahoo groups indicates it can be a painful and daunting take-on process if you have to join in the conversation after the bus has left. As such, please can we hold off discussions about content and structure of the knowledge base until we have most of the people on board. This should only take a week or two but will be worth it. For example, I know that Steve Adolph and the Calgary crowd have already started a similar initiative but they are not signed up yet. Their experience will be very valuable.

Many thanks

Chris

Reply | Messages in this Topic (4)

#33

From: Chris <chris.matts@...>
Date: Tue Sep 22, 2009 5:46 am
Subject: Re: Initial Activity for the next two weeks.

chrisjmatts1968

Send Email

Ellen

If you send me the e:mail addresses I will send the invites from the yahoo groups page.

Chris

Sent from my iPhone

On 22 Sep 2009, at 01:04, ellen@... wrote:

When I return to US I will contact agile ba's I'm aware of and reach out as well;

Question: when I get names-emails, how do I go about getting them invited to the yahoo group and the wiki?
Thx
Ellen
Sent via BlackBerry by AT&T
From: "chrisjmatts1968"
Date: Mon, 21 Sep 2009 16:39:03 -0000
To: <Agile_BA_Requirements@yahoogroups.co.uk>
Subject: [Agile_BA_Requirements] Initial Activity for the next two weeks.

Dear All

For the next couple of weeks I would like us to focus on two key things.

1. Lets get the right people on the bus! I have invited about 25 people to the group. I would like others to identify people they think will contribute to a core group. So far 11 people have signed up to the group. I would like to get most of the core group ( whoever they decide they are ) signed up before we start any significant discussions about content or process. Most of this core group will be set up as moderators on the yahoo group.

2. Start to get the infra-structure in place. The wiki and the community. Contact and learn from other initiatives such as the PMI group or Opium 3. Identify how we will get access to the BABOK. And identify a few key roles and fill them with "interim" candidates.

Please note that there will be two significant parts to this initiative.

The first is to create an Agile Business Analysis Body of Knowledge. This has NOTHING to do with the IIBA although we hope that Kevin and David will contribute.

The second is to mine the Agile Analysis Body of Knowledge for the IIBA. This will be lead by David with the support of an Agile Team lead ( mentored ) by TBD.

Exact details to be driven out but this is the rough idea.

So far, roles identified are...

Wiki maintenance ( Dennis volunteered )
IIBA leader - ( David Morris )
Agile liaision to IIBA leader - ( Hopefully to identify someone with help of Greg and Kent as the previous Customer Stage producers )
Agile Alliance liaision ( Cesar Idrovo - He's on the board )

When we start on the knowledge base there will be lots of pain to share ;-)

Experience of yahoo groups indicates it can be a painful and daunting take-on process if you have to join in the conversation after the bus has left. As such, please can we hold off discussions about content and structure of the knowledge base until we have most of the people on board. This should only take a week or two but will be worth it. For example, I know that Steve Adolph and the Calgary crowd have already started a similar initiative but they are not signed up yet. Their experience will be very valuable.

Many thanks

Chris

Reply | Messages in this Topic (4)

#34

From: Kevin Brennan <kevin.brennan@...>
Date: Tue Sep 22, 2009 2:50 pm
Subject: Re: Vancouver Agile BA Fish bowl

kevinjbrennan

Send Email

I'll talk to our chapter folks about it. Mostly we'd need the local
contacts so people know who to talk to.

On 2009-09-21, at 1:57 PM, Chris wrote:

>
> Steve
>
> Are you sure you live in Vancouver? I could have sworn it was
> Calgary. ;-)
>
> Please get your 4 or 5 to sign up.
>
> Like the idea of the Goldfish bowl. Might be good to get the IIBA to
> promote it as well. Kevin, how do we do that?
>
> Thanks
>
> Chris
>
> Sent from my iPhone
>
> On 21 Sep 2009, at 18:51, "flybynight107" <steve@...>
> wrote:
>
>>
>> Hello Everyone
>>
>> Its really serendipitous this group is starting just as we started
>> an "Agile BA" series in Vancouver. Last week we held a joint Agile
>> Vancouver (the local Agile Methods User group
>> www.agilevancouver.ca) IIBA vancouver chapter fish bowl event to
>> discuss the challenge of the Agile BA. Over 60 people participated
>> enthusiastically in this event. We took notes and hopefully when
>> one of us has enough time, we will post the notes some place.
>>
>> When we planned this event we had no idea there were plans for this
>> group. My suggestion is that given the success of this first fish
>> bowl and the interest it generated, and how it brought the two
>> communities together ( members of the local IIBA chapter and
>> members of agile vancouver) this is something we may want to try in
>> other locations. Think of this as a town hall series, getting
>> people truly involved at the grass roots.
>>
>> Also there are easily 4 or 5 people in Vancouver who are definitely
>> interested in moving this topic ahead.
>>
>> best regards,
>> Steve Adolph
>>
>
>

________________
Kevin Brennan, CBAP, PMP
Vice-President, Professional Development
International Institute of Business Analysis (IIBA�)
"Helping Business Do Business Better"
www.theiiba.org
kevin.brennan@...
Office: (416) 233-8743

Reply | Messages in this Topic (4)

#35

From: "dennisstevens" <dennis.stevens@...>
Date: Tue Sep 22, 2009 5:15 pm
Subject: Re: New file uploaded to Agile_BA_Requirements

dennisstevens

Send Email

Thanks Kevin,

This is really fascinating stuff. It highlights real opportunities for maturing
and raising the value of the Business Analysis activity. Is this content
available for public comment?

Dennis Stevens

--- In Agile_BA_Requirements@...,
Agile_BA_Requirements@... wrote:
>
>
> Hello,
>
> This email message is a notification to let you know that
> a file has been uploaded to the Files area of the Agile_BA_Requirements
> group.
>
>   File        : /SurveySummary_09212009-1.pdf
>   Uploaded by : kevinjbrennan <kevin.brennan@...>
>   Description : Survey by IIBA of BAs with Agile Experience
>
> You can access this file at the URL:
>
http://uk.groups.yahoo.com/group/Agile_BA_Requirements/files/SurveySummary_09212\
009-1.pdf
>
> To learn more about file sharing for your group, please visit:
> http://help.yahoo.com/help/uk/groups/files
>
> Regards,
>
> kevinjbrennan <kevin.brennan@...>
>

Reply | Messages in this Topic (7)

#36

From: Kevin Brennan <kevin.brennan@...>
Date: Tue Sep 22, 2009 5:35 pm
Subject: Re: Re: New file uploaded to Agile_BA_Requirements

kevinjbrennan

Send Email

Feel free to make use of the data.

Kevin Brennan, CBAP, PMP

VP, Professional Development

IIBA

On 2009-09-22, at 1:15 PM, "dennisstevens" <dennis.stevens@...> wrote:

Thanks Kevin,

This is really fascinating stuff. It highlights real opportunities for maturing and raising the value of the Business Analysis activity. Is this content available for public comment?

Dennis Stevens

--- In Agile_BA_Requirements@yahoogroups.co.uk, Agile_BA_Requirements@yahoogroups.co.uk wrote:
>
>
> Hello,
>
> This email message is a notification to let you know that
> a file has been uploaded to the Files area of the Agile_BA_Requirements
> group.
>
> File : /SurveySummary_09212009-1.pdf
> Uploaded by : kevinjbrennan <kevin.brennan@...>
> Description : Survey by IIBA of BAs with Agile Experience
>
> You can access this file at the URL:
> http://uk.groups.yahoo.com/group/Agile_BA_Requirements/files/SurveySummary_09212009-1.pdf
>
> To learn more about file sharing for your group, please visit:
> http://help.yahoo.com/help/uk/groups/files
>
> Regards,
>
> kevinjbrennan <kevin.brennan@...>
>

Reply | Messages in this Topic (7)

#37

From: "dennisstevens" <dennis.stevens@...>
Date: Fri Sep 25, 2009 8:11 pm
Subject: Re: Initial Activity for the next two weeks.

dennisstevens

Send Email

Send them to me or Chris.

--- In Agile_BA_Requirements@..., ellen@... wrote:
>
> When I return to US I will contact agile ba's I'm aware of and reach out as
well;
>
> Question: when I get names-emails, how do I go about getting them invited to
the yahoo group and the wiki?
> Thx
> Ellen
> Sent via BlackBerry by AT&T
>
> -----Original Message-----
> From: "chrisjmatts1968" <chris.matts@...>
>
> Date: Mon, 21 Sep 2009 16:39:03
> To: <Agile_BA_Requirements@...>
> Subject: [Agile_BA_Requirements] Initial Activity for the next two weeks.
>
>
> Dear All
>
> For the next couple of weeks I would like us to focus on two key things.
>
> 1. Lets get the right people on the bus! I have invited about 25 people to the
group. I would like others to identify people they think will contribute to a
core group. So far 11 people have signed up to the group. I would like to get
most of the core group ( whoever they decide they are ) signed up before we
start any significant discussions about content or process. Most of this core
group will be set up as moderators on the yahoo group.
>
> 2. Start to get the infra-structure in place. The wiki and the community.
Contact and learn from other initiatives such as the PMI group or Opium 3.
Identify how we will get access to the BABOK. And identify a few key roles and
fill them with "interim" candidates.
>
> Please note that there will be two significant parts to this initiative.
>
> The first is to create an Agile Business Analysis Body of Knowledge. This has
NOTHING to do with the IIBA although we hope that Kevin and David will
contribute.
>
> The second is to mine the Agile Analysis Body of Knowledge for the IIBA. This
will be lead by David with the support of an Agile Team lead ( mentored ) by
TBD.
>
> Exact details to be driven out but this is the rough idea.
>
> So far, roles identified are...
>
> Wiki maintenance ( Dennis volunteered )
> IIBA leader - ( David Morris )
> Agile liaision to IIBA leader - ( Hopefully to identify someone with help of
Greg and Kent as the previous Customer Stage producers )
> Agile Alliance liaision ( Cesar Idrovo - He's on the board )
>
> When we start on the knowledge base there will be lots of pain to share ;-)
>
> Experience of yahoo groups indicates it can be a painful and daunting take-on
process if you have to join in the conversation after the bus has left. As such,
please can we hold off discussions about content and structure of the knowledge
base until we have most of the people on board. This should only take a week or
two but will be worth it. For example, I know that Steve Adolph and the Calgary
crowd have already started a similar initiative but they are not signed up yet.
Their experience will be very valuable.
>
> Many thanks
>
> Chris
>

Reply | Messages in this Topic (4)

#38

From: "greyskinnedboy" <david.morris@...>
Date: Sat Sep 26, 2009 11:28 pm
Subject: Re: Working collaboratively IIBA and Agile Alliance

greyskinnedboy

Send Email

Hi Angela,

Many thanks. I am working towards becoming an honourary Kiwi, but as I've only
been here since November 2008 I have a way to go. Great country!

I had a good meeting with Shane Hastie last week, who has a keen interest in
this for a number of reasons, so I'm glad to see he's in this group too.

Cheers,
David.

Reply | Messages in this Topic (4)

#39

From: "greyskinnedboy" <david.morris@...>
Date: Sat Sep 26, 2009 11:40 pm
Subject: Re: My ideas on where to start

greyskinnedboy

Send Email

H Ellen,

It will be great to get insights from agile PM group. What is the timeline on
that?

Although I'm sure we're all really keen to get going on this, Chris is right
that we need to have some kind of framework in place (however loose that is).
So, let's not blow the starting whistle until we've got all the forwards, backs,
and coaches together.

In principle, I have no issue waiting until 8th October before getting started
in earnest. If we can in the meantime get chatting amongst ourselves to
understand a little of what makes us each tick, that will definitely help down
the line. We can get ready in the changing rooms.

If it's going to take longer than 8th October to get all these things in place,
then it might be useful to get something going like Shane suggested -- getting
us all to nail our own colours to the mast -- i.e. what we think being a BA in
an agile context means. We could start warming up on the sidelines (OK, enough
with the rugby allusions, already)

Cheers,
David.

Reply | Messages in this Topic (5)

#40

From: "greyskinnedboy" <david.morris@...>
Date: Sat Sep 26, 2009 11:47 pm
Subject: Re: Vancouver Agile BA Fish bowl

greyskinnedboy

Send Email

Great idea. Our last IIBA Auckland event looked at how we need to adapt the way
we communicate requirements in an agile environment, and it was one of the more
highly attended events recently (helped by being very hands on and interactive,
using break-out rooms and a team-based activity with a competitive edge -- great
fun).

We have a very active Agile Professional Network here in New Zealand too, so
I'll talk to them about holding a joint event here to explore this topic.

Cheers,
David.

Reply | Messages in this Topic (4)

#41

From: Chris Matts <chris.matts@...>
Date: Sun Sep 27, 2009 7:28 am
Subject: Re: My ideas on where to start

chrisjmatts1968

Send Email

Hi shane

We've given them about a week to sign up so hopefully those who are passionate are on board now.

Lets get going. I suggest we start with your suggestion but as a discussion on the group rather than on the wiki. I find wikis are great for knowledge stores but less good for discussions.

Although one end point is the BABOK, I would prefer if the Agile wiki had the aim of becoming "A comprehensive knowledge base for anyone interested in Business Analysis and Requirements in Agile"..... or something similar ( please discuss etc.)� David and the IIBA team will filter what they want for the BABOK

Chris

On Mon, Sep 21, 2009 at 5:02 AM, Shane <shaneh@...> wrote:

�

Hi Folks

I'd like to suggest the following as a starting point for this piece of
work:

Can we each write a small section on the Wiki which summarises how we
see the role of the analyst changing (and staying the same?) in Agile
projects. Links to blogs and articles we've written and perspectives
we respect could also be useful.

Once we have these perspectives we could try to find a (hopefully)
common viewpoint and then provide linkages into the BABOK sections where
we feel Agile methods will change the content, and identify if we feel
the BABOK needs new sections or topics.

How does this work as a way forward?

Cheers

Shane

--
Regards

Chris Matts

Reply | Messages in this Topic (5)

#42

From: "Shane Hastie" <shaneh@...>
Date: Mon Sep 28, 2009 11:12 am
Subject: Nailing my colours to the mast

shane_hastie

Send Email

Hi Folks

I proposed we do this, so I’ll start.

I do like Chris’s goal of "A comprehensive knowledge base for anyone interested in Business Analysis and Requirements in Agile" – I would expand Agile to “Agile software development”, although these principles apply to other types of projects we are focused on software development (or are we??).

My feeling is that the fundamental skills of business analysis remain vitally important in Agile projects. These skills include

· Communication

· Facilitation

· Investigation

· Persuasion & influence

· Presentation

· Analysis (the ability to examine a problem and break it apart into manageable bite-sized chunks)

· Synthesis (the ability to visualise solutions and identify components of those solutions)

· Modelling – the ability to represent complex problems in simple terms using effective representation techniques

· Business process identification and business process improvement understanding (IT projects are ALWAYS about changing/improving business processes – computer systems are enablers of business processes, not the reason for business processes)

· Requirements identification

There are a number of ways that the Analyst role changes (compared to “traditional” approaches), including:

· When we undertake analysis – there needs to be some (minimal) analysis up front to understand the “shape” of the project, identifying the user stories/use case briefs (or whatever your team calls them – high level requirements which can be prioritised and estimated), and then expanding the analysis to the detailed requirements (acceptance criteria/detailed use case scenarios/feature details …) on a Just in Time basis. This conscious deferment of detail until it is really needed (one iteration ahead at the most) prevents psychological lock-in or fixation so we are prepared to accept change. One of the issues with BDUF (even if it is done well) is the emotional investment in the work done results in a natural resistance to change (“they don’t like my baby – waaaah”)

· We are not solely responsible for “gathering” requirements – I see the Agile Analyst role as the “shepherd of stories” – like the shepherd in the field (I come from New Zealand after all, we’re an agricultural economy) we have a responsibility to ensure that the herd moves in the right direction, is protected and nurtured to grow and mature but we don’t own the sheep – we are an agent for the owner (the business stakeholders who have the real need)

· The analyst contributes to design as well and we need to have an understanding of user interaction and interface design principles

· We need to have basic testing skills (“thinking like a tester” see http://softwareeducation.wordpress.com/2009/09/17/36-testing-heuristics/ and http://testobsessed.com/2007/02/19/test-heuristics-cheat-sheet/ ) to help identify test cases and expose opportunities for improving the product

I wrote an article for InfoQ which explains my thinking – it can be found at http://www.softed.com/Resources/Docs/The-Role-of-the-Analyst-in-Agile-Projects.pdf

That’s my thinking in a few (???) words J

I look forward to reading others’ views

Cheers

Shane

Shane Hastie, MIM, CBAP

Chief Knowledge Engineer

Software Education Associates Ltd

DDI +64 4 924 1270 From Australia 1800 145 952

Switchboard +64 4 568 7806

NZ Mobile +64 21 590 255 Australia Mobile +61 450 604 413

Web www.softed.com

Learn with the experts

Join us for the world's best requirements training - "Mastering the Requirements Process" with James and Suzanne Robertson. Courses are running in Melbourne & Canberra (4 Nov), Wellington (9 Nov), Auckland (16 Nov), Sydney (30 Nov) and Christchurch (9 Dec). Call now for more details or visit www.softed.com

Reply | Messages in this Topic (26)

#43

From: "dennisstevens" <dennis.stevens@...>
Date: Mon Sep 28, 2009 12:43 pm
Subject: Re: Nailing my colours to the mast

dennisstevens

Send Email

I agree that we are focused on Agile Software Development. Although I might
expand it to be Software and Services Development.

I agree that the basic skills haven't changed.

I would like to see us clearly articulate what is different in today's Agile
Software and Services development projects. The different value proposition of
Agile development needs to enabled and enhanced by Business Analysis techniques.
A common perspective on what is different and how Business Analysis capabilities
support this different value proposition would be a good anchoring point for
deciding what is changed in Business Analysis. For example:

1. The Value Stream is less distinct on Agile projects. Requirements, Testing,
and Development overlap and iterate on Agile projects. This leads to decoupling
of some BA activities and the traditional BA role. This decoupling results in
the gap between Agile teams and Business Analysts today. Are we defining the BA
role or BA activities (some of which could be moving onto the development team)?

2. Agile projects are about reducing risk and delivering value early. Time and
cost tend to be more bounded - so Agile teams need to focus on Risk reduction
and then Value delivery. Business Analysis work has to be able to clearly
articulate risks and value and serve as a scoping and prioritization mechanism
to feed the projects appropriately.

3. Today, not all projects are about improving a process. Services change the
perspective. One of my clients has grown through acquisition. Now they are
building a Services based model to consolidate across multiple customer
platforms. The business analysis work is not to improve a single process - it is
to define the services that can be shared across products to leverage IT spend
and improve platform adaptability. This component or service based view takes a
different way of thinking than a process view.

Establishing a solid shared understanding of Agile context is important before
we start solving for it.

Dennis Stevens

--- In Agile_BA_Requirements@..., "Shane Hastie" <shaneh@...>
wrote:
>
> Hi Folks
>
>
>
> I proposed we do this, so I'll start.
>
>
>
> I do like Chris's goal of "A comprehensive knowledge base for anyone
> interested in Business Analysis and Requirements in Agile" - I would
> expand Agile to "Agile software development", although these principles
> apply to other types of projects we are focused on software development
> (or are we??).
>
>
>
> My feeling is that the fundamental skills of business analysis remain
> vitally important in Agile projects.  These skills include
>
> *         Communication
>
> *         Facilitation
>
> *         Investigation
>
> *         Persuasion & influence
>
> *         Presentation
>
> *         Analysis (the ability to examine a problem and break it apart
> into manageable bite-sized chunks)
>
> *         Synthesis (the ability to visualise solutions and identify
> components of those solutions)
>
> *         Modelling - the ability to represent complex problems in
> simple terms using effective representation techniques
>
> *         Business process identification and business process
> improvement understanding (IT projects are ALWAYS about
> changing/improving business processes - computer systems are enablers of
> business processes, not the reason for business processes)
>
> *         Requirements identification
>
>
>
> There are a number of ways that the Analyst role changes (compared to
> "traditional" approaches), including:
>
> *         When we undertake analysis - there needs to be some (minimal)
> analysis up front to understand the "shape" of the project, identifying
> the user stories/use case briefs (or whatever your team calls them -
> high level requirements which can be prioritised and estimated), and
> then expanding the analysis to the detailed requirements (acceptance
> criteria/detailed use case scenarios/feature details ...) on a Just in
> Time basis.   This conscious deferment of detail until it is really
> needed (one iteration ahead at the most) prevents psychological lock-in
> or fixation so we are prepared to accept change.  One of the issues with
> BDUF (even if it is done well) is the emotional investment in the work
> done results in a natural resistance to change ("they don't like my baby
> - waaaah")
>
> *         We are not solely responsible for "gathering" requirements - I
> see the Agile Analyst role as the "shepherd of stories" - like the
> shepherd in the field (I come from New Zealand after all, we're an
> agricultural economy) we have a responsibility to ensure that the herd
> moves in the right direction, is protected and nurtured to grow and
> mature but we don't own the sheep - we are an agent for the owner (the
> business stakeholders who have the real need)
>
> *         The analyst contributes to design as well and we need to have
> an understanding of user interaction and interface design principles
>
> *         We need to have basic testing skills ("thinking like a tester"
> see
> http://softwareeducation.wordpress.com/2009/09/17/36-testing-heuristics/
> and http://testobsessed.com/2007/02/19/test-heuristics-cheat-sheet/  )
> to help identify test cases and expose opportunities for improving the
> product
>
>
>
> I wrote an article for InfoQ which explains my thinking - it can be
> found at
> http://www.softed.com/Resources/Docs/The-Role-of-the-Analyst-in-Agile-Pr
> ojects.pdf
>
>
>
> That's my thinking in a few (???) words J
>
>
>
> I look forward to reading others' views
>
>
>
> Cheers
>
>
>
> Shane
>
>
>
> Shane Hastie, MIM, CBAP
>
> Chief Knowledge Engineer
>
> Software Education Associates Ltd
>
> DDI +64 4 924 1270   From Australia 1800 145 952
>
> Switchboard +64 4 568 7806
>
> NZ Mobile +64 21 590 255   Australia Mobile +61 450 604 413
>
> Web www.softed.com <http://www.softed.com/>
>
>
>
> Learn with the experts
>
>
>
>
>
> Join us for the world's best requirements training - "Mastering the
> Requirements Process" with James and Suzanne Robertson.  Courses are
> running in Melbourne & Canberra (4 Nov), Wellington (9 Nov), Auckland
> (16 Nov), Sydney (30 Nov) and Christchurch (9 Dec).  Call now for more
> details or visit www.softed.com <http://www.softed.com>
>

Reply | Messages in this Topic (26)

#44

From: Kent McDonald <kentjmcdonald@...>
Date: Tue Sep 29, 2009 1:49 am
Subject: Re: Re: Nailing my colours to the mast

kentmcdonald

Send Email

I'm not necessarily going to nail colors to the mast yet, but I will pose this question to the group...

Why does agile in this context have to be limited to Software Development or even Software and Services Development?

Kent J. McDonald
kent@...

Collaborate | Iterate | Serve the Team | Consider Context
Practice Excellence| Decide Wisely | Reflect and Adapt | Deliver Value

On Mon, Sep 28, 2009 at 7:43 AM, dennisstevens <dennis.stevens@...> wrote:

�

I agree that we are focused on Agile Software Development. Although I might expand it to be Software and Services Development.

I agree that the basic skills haven't changed.

I would like to see us clearly articulate what is different in today's Agile Software and Services development projects. The different value proposition of Agile development needs to enabled and enhanced by Business Analysis techniques. A common perspective on what is different and how Business Analysis capabilities support this different value proposition would be a good anchoring point for deciding what is changed in Business Analysis. For example:

1. The Value Stream is less distinct on Agile projects. Requirements, Testing, and Development overlap and iterate on Agile projects. This leads to decoupling of some BA activities and the traditional BA role. This decoupling results in the gap between Agile teams and Business Analysts today. Are we defining the BA role or BA activities (some of which could be moving onto the development team)?

2. Agile projects are about reducing risk and delivering value early. Time and cost tend to be more bounded - so Agile teams need to focus on Risk reduction and then Value delivery. Business Analysis work has to be able to clearly articulate risks and value and serve as a scoping and prioritization mechanism to feed the projects appropriately.

3. Today, not all projects are about improving a process. Services change the perspective. One of my clients has grown through acquisition. Now they are building a Services based model to consolidate across multiple customer platforms. The business analysis work is not to improve a single process - it is to define the services that can be shared across products to leverage IT spend and improve platform adaptability. This component or service based view takes a different way of thinking than a process view.

Establishing a solid shared understanding of Agile context is important before we start solving for it.

Dennis Stevens

--- In Agile_BA_Requirements@..., "Shane Hastie" <shaneh@...> wrote:
>
> Hi Folks
>
>
>
> I proposed we do this, so I'll start.
>
>
>
> I do like Chris's goal of "A comprehensive knowledge base for anyone
> interested in Business Analysis and Requirements in Agile" - I would
> expand Agile to "Agile software development", although these principles
> apply to other types of projects we are focused on software development
> (or are we??).
>
>
>
> My feeling is that the fundamental skills of business analysis remain
> vitally important in Agile projects. These skills include
>
> * Communication
>
> * Facilitation
>
> * Investigation
>
> * Persuasion & influence
>
> * Presentation
>
> * Analysis (the ability to examine a problem and break it apart
> into manageable bite-sized chunks)
>
> * Synthesis (the ability to visualise solutions and identify
> components of those solutions)
>
> * Modelling - the ability to represent complex problems in
> simple terms using effective representation techniques
>
> * Business process identification and business process
> improvement understanding (IT projects are ALWAYS about
> changing/improving business processes - computer systems are enablers of
> business processes, not the reason for business processes)
>
> * Requirements identification
>
>
>
> There are a number of ways that the Analyst role changes (compared to
> "traditional" approaches), including:
>
> * When we undertake analysis - there needs to be some (minimal)
> analysis up front to understand the "shape" of the project, identifying
> the user stories/use case briefs (or whatever your team calls them -
> high level requirements which can be prioritised and estimated), and
> then expanding the analysis to the detailed requirements (acceptance
> criteria/detailed use case scenarios/feature details ...) on a Just in
> Time basis. This conscious deferment of detail until it is really
> needed (one iteration ahead at the most) prevents psychological lock-in
> or fixation so we are prepared to accept change. One of the issues with
> BDUF (even if it is done well) is the emotional investment in the work
> done results in a natural resistance to change ("they don't like my baby
> - waaaah")
>
> * We are not solely responsible for "gathering" requirements - I
> see the Agile Analyst role as the "shepherd of stories" - like the
> shepherd in the field (I come from New Zealand after all, we're an
> agricultural economy) we have a responsibility to ensure that the herd
> moves in the right direction, is protected and nurtured to grow and
> mature but we don't own the sheep - we are an agent for the owner (the
> business stakeholders who have the real need)
>
> * The analyst contributes to design as well and we need to have
> an understanding of user interaction and interface design principles
>
> * We need to have basic testing skills ("thinking like a tester"
> see
> http://softwareeducation.wordpress.com/2009/09/17/36-testing-heuristics/
> and http://testobsessed.com/2007/02/19/test-heuristics-cheat-sheet/ )
> to help identify test cases and expose opportunities for improving the
> product
>
>
>
> I wrote an article for InfoQ which explains my thinking - it can be
> found at
> http://www.softed.com/Resources/Docs/The-Role-of-the-Analyst-in-Agile-Pr
> ojects.pdf
>
>
>
> That's my thinking in a few (???) words J
>
>
>
> I look forward to reading others' views
>
>
>
> Cheers
>
>
>
> Shane
>
>
>
> Shane Hastie, MIM, CBAP
>
> Chief Knowledge Engineer
>
> Software Education Associates Ltd
>
> DDI +64 4 924 1270 From Australia 1800 145 952
>
> Switchboard +64 4 568 7806
>
> NZ Mobile +64 21 590 255 Australia Mobile +61 450 604 413
>
> Web www.softed.com <http://www.softed.com/>
>
>
>
> Learn with the experts
>
>
>
>
>
> Join us for the world's best requirements training - "Mastering the
> Requirements Process" with James and Suzanne Robertson. Courses are
> running in Melbourne & Canberra (4 Nov), Wellington (9 Nov), Auckland
> (16 Nov), Sydney (30 Nov) and Christchurch (9 Dec). Call now for more
> details or visit www.softed.com <http://www.softed.com>
>

Reply | Messages in this Topic (26)

#45

From: "Steve" <steve@...>
Date: Tue Sep 29, 2009 6:23 am
Subject: Re: Nailing my colours to the mast

flybynight107

Send Email

Ok its late and I'm tired, but  I'll toss my hat into the ring or raise my
colours...

First what is agile about? There are two basic assumptions behind agile, change
happens and people trump process. In an environment of change, the utility of
detailed plans and requirements is limited at best. Rather what we need is an
adaptive approach. Ken Schwaber suggested software development is much more like
an empirical process which that requires  monitoring and adjusting  in
real-time. Real-time here means if its late, its wrong. Practices that delay our
ability to monitor and adjust will lead to less than optimal results. The agile
methods offer us light weight practices that enable us to quickly try something,
obtain feedback and adjust. This in my opinion is really what agile is about,
can I create a process for my project that allows me to make decisions about my
project and take action in a timely manner.

For a small project, a method like XP enables very fast decision cycles,
wonderful for a project where things could be changing by the day. It is
unlikely projects like these require a BA, and our enterprise here will have
little utility to people involved in these kinds of projects.

The BA role came about because as projects became more complex customers were
not usually capable of understanding the technology behind the system and tech
people were not usually capable of understanding the requirements. Then of
course there is the problem of resolving competing interests. These problems did
not go away with agile, so the BA still is an important role regardless of the
method.

But what does the BA do in an "agile" environment, write user stories? Well let
me use the consultant's mantra "...it depends..." One thing I do know for sure
is the BA needs to be much more of a communicator, networker, facilitator, and
builder of back channels. The very best BAs already know this, and I strongly
believe the best work that will come from this group is to place interpersonal
skills at the very heart of the profession and the BA BOK. Right now I'm a
little disappointed this topic is dealt with almost as an afterthought in the BA
BOK.

The practices available to the Agile BA will depend a lot on the organization
they are part of. Here I want us to think very carefully about distinguishing
practices as either governance or coordination. Governance are the immutable
practices a project must comply with for either regulatory or internal policy
requirements. Coordination is the set of practices we have in place that enable
people to work effectively together. A mistake we commonly make is that we use
our governance practices for coordination. For example, why do we produce an
SRS? Is it because it is required by law or as internal corporate policy? Ok
fine, but do our developers and testers need it to do their jobs? In fact could
the SRS be getting in the way of the developers and testers doing their job
effectively? In this situation, produce the SRS, but do not use it as the only
mechanism for communicating requirements to the developers and testers.

Now I'm going to step out into much more controversial territory, why the
distance between Business Analysis and Quality Assurance? In many methods they
are at opposite ends of the life-cycle and yet in many ways should be working
closely together.  The most accurate, and up to date specification for a system
are the tests. In XP there are no quote requirements, just stories which are
requirements place holders. The tests are the real requirements. Part of our
work therefore must be to develop recommendations for practices that bring these
two disciplines closer together.

My bottom line, in my opinion I believe the BA will take the brunt of managing
impedance mismatches between the different corporate process in place for the
creation of software. The software development team itself may be "agile"
drawing stories from their backlog and creating "potentially shippable product"
every few weeks, but the surrounding organization may be much more traditional.
The Agile BA are some of the people who will have to be flexible enough to
satisfy the needs of all the processes involved in the creation of software.

ok its bedtime for me, good night everyone
Steve Adolph

--- In Agile_BA_Requirements@..., "Shane Hastie" <shaneh@...>
wrote:
>
> Hi Folks
>
>
>
> I proposed we do this, so I'll start.
>
>
>
> I do like Chris's goal of "A comprehensive knowledge base for anyone
> interested in Business Analysis and Requirements in Agile" - I would
> expand Agile to "Agile software development", although these principles
> apply to other types of projects we are focused on software development
> (or are we??).
>
>
>
> My feeling is that the fundamental skills of business analysis remain
> vitally important in Agile projects.  These skills include
>
> *         Communication
>
> *         Facilitation
>
> *         Investigation
>
> *         Persuasion & influence
>
> *         Presentation
>
> *         Analysis (the ability to examine a problem and break it apart
> into manageable bite-sized chunks)
>
> *         Synthesis (the ability to visualise solutions and identify
> components of those solutions)
>
> *         Modelling - the ability to represent complex problems in
> simple terms using effective representation techniques
>
> *         Business process identification and business process
> improvement understanding (IT projects are ALWAYS about
> changing/improving business processes - computer systems are enablers of
> business processes, not the reason for business processes)
>
> *         Requirements identification
>
>
>
> There are a number of ways that the Analyst role changes (compared to
> "traditional" approaches), including:
>
> *         When we undertake analysis - there needs to be some (minimal)
> analysis up front to understand the "shape" of the project, identifying
> the user stories/use case briefs (or whatever your team calls them -
> high level requirements which can be prioritised and estimated), and
> then expanding the analysis to the detailed requirements (acceptance
> criteria/detailed use case scenarios/feature details ...) on a Just in
> Time basis.   This conscious deferment of detail until it is really
> needed (one iteration ahead at the most) prevents psychological lock-in
> or fixation so we are prepared to accept change.  One of the issues with
> BDUF (even if it is done well) is the emotional investment in the work
> done results in a natural resistance to change ("they don't like my baby
> - waaaah")
>
> *         We are not solely responsible for "gathering" requirements - I
> see the Agile Analyst role as the "shepherd of stories" - like the
> shepherd in the field (I come from New Zealand after all, we're an
> agricultural economy) we have a responsibility to ensure that the herd
> moves in the right direction, is protected and nurtured to grow and
> mature but we don't own the sheep - we are an agent for the owner (the
> business stakeholders who have the real need)
>
> *         The analyst contributes to design as well and we need to have
> an understanding of user interaction and interface design principles
>
> *         We need to have basic testing skills ("thinking like a tester"
> see
> http://softwareeducation.wordpress.com/2009/09/17/36-testing-heuristics/
> and http://testobsessed.com/2007/02/19/test-heuristics-cheat-sheet/  )
> to help identify test cases and expose opportunities for improving the
> product
>
>
>
> I wrote an article for InfoQ which explains my thinking - it can be
> found at
> http://www.softed.com/Resources/Docs/The-Role-of-the-Analyst-in-Agile-Pr
> ojects.pdf
>
>
>
> That's my thinking in a few (???) words J
>
>
>
> I look forward to reading others' views
>
>
>
> Cheers
>
>
>
> Shane
>
>
>
> Shane Hastie, MIM, CBAP
>
> Chief Knowledge Engineer
>
> Software Education Associates Ltd
>
> DDI +64 4 924 1270   From Australia 1800 145 952
>
> Switchboard +64 4 568 7806
>
> NZ Mobile +64 21 590 255   Australia Mobile +61 450 604 413
>
> Web www.softed.com <http://www.softed.com/>
>
>
>
> Learn with the experts
>
>
>
>
>
> Join us for the world's best requirements training - "Mastering the
> Requirements Process" with James and Suzanne Robertson.  Courses are
> running in Melbourne & Canberra (4 Nov), Wellington (9 Nov), Auckland
> (16 Nov), Sydney (30 Nov) and Christchurch (9 Dec).  Call now for more
> details or visit www.softed.com <http://www.softed.com>
>

Reply | Messages in this Topic (26)

#46

From: "dennisstevens" <dennis.stevens@...>
Date: Tue Sep 29, 2009 12:08 pm
Subject: Re: Nailing my colours to the mast

dennisstevens

Send Email

Steve,

Great discussion. I agree with pretty much everything you said. I did want one
clarification within the group.

Are we writing about the Business Analyst role or about Business Analysis
capabilities? In your discussion below you say the XP team probably doesn't need
someone to be the Business Analyst, but aren't there still situationally
specific Business Analysis practices that would be useful to the XP team? As the
project gets more complex some additional Business Analysis practices become
appropriate. Even if these move to a Product Owner or some other role - they are
business analysis capabilities aren't they?

My thought is that in emerging organizations, the Business Analyst may perform
some of the Business Analyst capabilities, facilitate others, and some may
belong to other roles. I think we need to be able to discuss the Business
Analysis capabilities and practices as they might exist in an agile team and
then provide some guidance on where they might be performed - regardless of the
specific role.

Everything you said about the need to be a communicator, networker, facilitator,
and builder of back channels is true regardless of what role performs the
capabilities.

Dennis Stevens

--- In Agile_BA_Requirements@..., "Steve" <steve@...> wrote:
>
> Ok its late and I'm tired, but  I'll toss my hat into the ring or raise my
colours...
>
>
> First what is agile about? There are two basic assumptions behind agile,
change happens and people trump process. In an environment of change, the
utility of detailed plans and requirements is limited at best. Rather what we
need is an adaptive approach. Ken Schwaber suggested software development is
much more like an empirical process which that requires  monitoring and
adjusting  in real-time. Real-time here means if its late, its wrong. Practices
that delay our ability to monitor and adjust will lead to less than optimal
results. The agile methods offer us light weight practices that enable us to
quickly try something, obtain feedback and adjust. This in my opinion is really
what agile is about, can I create a process for my project that allows me to
make decisions about my project and take action in a timely manner.
>
> For a small project, a method like XP enables very fast decision cycles,
wonderful for a project where things could be changing by the day. It is
unlikely projects like these require a BA, and our enterprise here will have
little utility to people involved in these kinds of projects.
>
> The BA role came about because as projects became more complex customers were
not usually capable of understanding the technology behind the system and tech
people were not usually capable of understanding the requirements. Then of
course there is the problem of resolving competing interests. These problems did
not go away with agile, so the BA still is an important role regardless of the
method.
>
> But what does the BA do in an "agile" environment, write user stories? Well
let me use the consultant's mantra "...it depends..." One thing I do know for
sure is the BA needs to be much more of a communicator, networker, facilitator,
and builder of back channels. The very best BAs already know this, and I
strongly believe the best work that will come from this group is to place
interpersonal skills at the very heart of the profession and the BA BOK. Right
now I'm a little disappointed this topic is dealt with almost as an afterthought
in the BA BOK.
>
> The practices available to the Agile BA will depend a lot on the organization
they are part of. Here I want us to think very carefully about distinguishing
practices as either governance or coordination. Governance are the immutable
practices a project must comply with for either regulatory or internal policy
requirements. Coordination is the set of practices we have in place that enable
people to work effectively together. A mistake we commonly make is that we use
our governance practices for coordination. For example, why do we produce an
SRS? Is it because it is required by law or as internal corporate policy? Ok
fine, but do our developers and testers need it to do their jobs? In fact could
the SRS be getting in the way of the developers and testers doing their job
effectively? In this situation, produce the SRS, but do not use it as the only
mechanism for communicating requirements to the developers and testers.
>
>
> Now I'm going to step out into much more controversial territory, why the
distance between Business Analysis and Quality Assurance? In many methods they
are at opposite ends of the life-cycle and yet in many ways should be working
closely together.  The most accurate, and up to date specification for a system
are the tests. In XP there are no quote requirements, just stories which are
requirements place holders. The tests are the real requirements. Part of our
work therefore must be to develop recommendations for practices that bring these
two disciplines closer together.
>
>
> My bottom line, in my opinion I believe the BA will take the brunt of managing
impedance mismatches between the different corporate process in place for the
creation of software. The software development team itself may be "agile"
drawing stories from their backlog and creating "potentially shippable product"
every few weeks, but the surrounding organization may be much more traditional.
The Agile BA are some of the people who will have to be flexible enough to
satisfy the needs of all the processes involved in the creation of software.
>
> ok its bedtime for me, good night everyone
> Steve Adolph
>
> --- In Agile_BA_Requirements@..., "Shane Hastie" <shaneh@>
wrote:
> >
> > Hi Folks
> >
> >
> >
> > I proposed we do this, so I'll start.
> >
> >
> >
> > I do like Chris's goal of "A comprehensive knowledge base for anyone
> > interested in Business Analysis and Requirements in Agile" - I would
> > expand Agile to "Agile software development", although these principles
> > apply to other types of projects we are focused on software development
> > (or are we??).
> >
> >
> >
> > My feeling is that the fundamental skills of business analysis remain
> > vitally important in Agile projects.  These skills include
> >
> > *         Communication
> >
> > *         Facilitation
> >
> > *         Investigation
> >
> > *         Persuasion & influence
> >
> > *         Presentation
> >
> > *         Analysis (the ability to examine a problem and break it apart
> > into manageable bite-sized chunks)
> >
> > *         Synthesis (the ability to visualise solutions and identify
> > components of those solutions)
> >
> > *         Modelling - the ability to represent complex problems in
> > simple terms using effective representation techniques
> >
> > *         Business process identification and business process
> > improvement understanding (IT projects are ALWAYS about
> > changing/improving business processes - computer systems are enablers of
> > business processes, not the reason for business processes)
> >
> > *         Requirements identification
> >
> >
> >
> > There are a number of ways that the Analyst role changes (compared to
> > "traditional" approaches), including:
> >
> > *         When we undertake analysis - there needs to be some (minimal)
> > analysis up front to understand the "shape" of the project, identifying
> > the user stories/use case briefs (or whatever your team calls them -
> > high level requirements which can be prioritised and estimated), and
> > then expanding the analysis to the detailed requirements (acceptance
> > criteria/detailed use case scenarios/feature details ...) on a Just in
> > Time basis.   This conscious deferment of detail until it is really
> > needed (one iteration ahead at the most) prevents psychological lock-in
> > or fixation so we are prepared to accept change.  One of the issues with
> > BDUF (even if it is done well) is the emotional investment in the work
> > done results in a natural resistance to change ("they don't like my baby
> > - waaaah")
> >
> > *         We are not solely responsible for "gathering" requirements - I
> > see the Agile Analyst role as the "shepherd of stories" - like the
> > shepherd in the field (I come from New Zealand after all, we're an
> > agricultural economy) we have a responsibility to ensure that the herd
> > moves in the right direction, is protected and nurtured to grow and
> > mature but we don't own the sheep - we are an agent for the owner (the
> > business stakeholders who have the real need)
> >
> > *         The analyst contributes to design as well and we need to have
> > an understanding of user interaction and interface design principles
> >
> > *         We need to have basic testing skills ("thinking like a tester"
> > see
> > http://softwareeducation.wordpress.com/2009/09/17/36-testing-heuristics/
> > and http://testobsessed.com/2007/02/19/test-heuristics-cheat-sheet/  )
> > to help identify test cases and expose opportunities for improving the
> > product
> >
> >
> >
> > I wrote an article for InfoQ which explains my thinking - it can be
> > found at
> > http://www.softed.com/Resources/Docs/The-Role-of-the-Analyst-in-Agile-Pr
> > ojects.pdf
> >
> >
> >
> > That's my thinking in a few (???) words J
> >
> >
> >
> > I look forward to reading others' views
> >
> >
> >
> > Cheers
> >
> >
> >
> > Shane
> >
> >
> >
> > Shane Hastie, MIM, CBAP
> >
> > Chief Knowledge Engineer
> >
> > Software Education Associates Ltd
> >
> > DDI +64 4 924 1270   From Australia 1800 145 952
> >
> > Switchboard +64 4 568 7806
> >
> > NZ Mobile +64 21 590 255   Australia Mobile +61 450 604 413
> >
> > Web www.softed.com <http://www.softed.com/>
> >
> >
> >
> > Learn with the experts
> >
> >
> >
> >
> >
> > Join us for the world's best requirements training - "Mastering the
> > Requirements Process" with James and Suzanne Robertson.  Courses are
> > running in Melbourne & Canberra (4 Nov), Wellington (9 Nov), Auckland
> > (16 Nov), Sydney (30 Nov) and Christchurch (9 Dec).  Call now for more
> > details or visit www.softed.com <http://www.softed.com>
> >
>

Reply | Messages in this Topic (26)

#47

From: "bw4eev" <brucew@...>
Date: Wed Sep 30, 2009 4:26 am
Subject: Re: Nailing my colours to the mast

bw4eev

Send Email

If we are talking about Business Analysts, what other context than software and
services development could be applicable?

I have not seen the business analyst discipline drive development of
sophisticated systems such as airplanes and automobiles, this would be the
domain of systems engineering.

Bruce Winegarden


--- In Agile_BA_Requirements@..., Kent McDonald
<kentjmcdonald@...> wrote:
>
> I'm not necessarily going to nail colors to the mast yet, but I will pose
> this question to the group...
>
> Why does agile in this context have to be limited to Software Development or
> even Software and Services Development?
>
> Kent J. McDonald
> kent@...
>
> Collaborate | Iterate | Serve the Team | Consider Context
> Practice Excellence| Decide Wisely | Reflect and Adapt | Deliver Value
>
>
>
> On Mon, Sep 28, 2009 at 7:43 AM, dennisstevens <dennis.stevens@...>wrote:
>
> >
> >
> > I agree that we are focused on Agile Software Development. Although I might
> > expand it to be Software and Services Development.
> >
> > I agree that the basic skills haven't changed.
> >
> > I would like to see us clearly articulate what is different in today's
> > Agile Software and Services development projects. The different value
> > proposition of Agile development needs to enabled and enhanced by Business
> > Analysis techniques. A common perspective on what is different and how
> > Business Analysis capabilities support this different value proposition
> > would be a good anchoring point for deciding what is changed in Business
> > Analysis. For example:
> >
> > 1. The Value Stream is less distinct on Agile projects. Requirements,
> > Testing, and Development overlap and iterate on Agile projects. This leads
> > to decoupling of some BA activities and the traditional BA role. This
> > decoupling results in the gap between Agile teams and Business Analysts
> > today. Are we defining the BA role or BA activities (some of which could be
> > moving onto the development team)?
> >
> > 2. Agile projects are about reducing risk and delivering value early. Time
> > and cost tend to be more bounded - so Agile teams need to focus on Risk
> > reduction and then Value delivery. Business Analysis work has to be able to
> > clearly articulate risks and value and serve as a scoping and prioritization
> > mechanism to feed the projects appropriately.
> >
> > 3. Today, not all projects are about improving a process. Services change
> > the perspective. One of my clients has grown through acquisition. Now they
> > are building a Services based model to consolidate across multiple customer
> > platforms. The business analysis work is not to improve a single process -
> > it is to define the services that can be shared across products to leverage
> > IT spend and improve platform adaptability. This component or service based
> > view takes a different way of thinking than a process view.
> >
> > Establishing a solid shared understanding of Agile context is important
> > before we start solving for it.
> >
> > Dennis Stevens
> >
> >
> > --- In
Agile_BA_Requirements@...<Agile_BA_Requirements%40yahoogroups.co.u\
k>,
> > "Shane Hastie" <shaneh@> wrote:
> > >
> > > Hi Folks
> > >
> > >
> > >
> > > I proposed we do this, so I'll start.
> > >
> > >
> > >
> > > I do like Chris's goal of "A comprehensive knowledge base for anyone
> > > interested in Business Analysis and Requirements in Agile" - I would
> > > expand Agile to "Agile software development", although these principles
> > > apply to other types of projects we are focused on software development
> > > (or are we??).
> > >
> > >
> > >
> > > My feeling is that the fundamental skills of business analysis remain
> > > vitally important in Agile projects. These skills include
> > >
> > > * Communication
> > >
> > > * Facilitation
> > >
> > > * Investigation
> > >
> > > * Persuasion & influence
> > >
> > > * Presentation
> > >
> > > * Analysis (the ability to examine a problem and break it apart
> > > into manageable bite-sized chunks)
> > >
> > > * Synthesis (the ability to visualise solutions and identify
> > > components of those solutions)
> > >
> > > * Modelling - the ability to represent complex problems in
> > > simple terms using effective representation techniques
> > >
> > > * Business process identification and business process
> > > improvement understanding (IT projects are ALWAYS about
> > > changing/improving business processes - computer systems are enablers of
> > > business processes, not the reason for business processes)
> > >
> > > * Requirements identification
> > >
> > >
> > >
> > > There are a number of ways that the Analyst role changes (compared to
> > > "traditional" approaches), including:
> > >
> > > * When we undertake analysis - there needs to be some (minimal)
> > > analysis up front to understand the "shape" of the project, identifying
> > > the user stories/use case briefs (or whatever your team calls them -
> > > high level requirements which can be prioritised and estimated), and
> > > then expanding the analysis to the detailed requirements (acceptance
> > > criteria/detailed use case scenarios/feature details ...) on a Just in
> > > Time basis. This conscious deferment of detail until it is really
> > > needed (one iteration ahead at the most) prevents psychological lock-in
> > > or fixation so we are prepared to accept change. One of the issues with
> > > BDUF (even if it is done well) is the emotional investment in the work
> > > done results in a natural resistance to change ("they don't like my baby
> > > - waaaah")
> > >
> > > * We are not solely responsible for "gathering" requirements - I
> > > see the Agile Analyst role as the "shepherd of stories" - like the
> > > shepherd in the field (I come from New Zealand after all, we're an
> > > agricultural economy) we have a responsibility to ensure that the herd
> > > moves in the right direction, is protected and nurtured to grow and
> > > mature but we don't own the sheep - we are an agent for the owner (the
> > > business stakeholders who have the real need)
> > >
> > > * The analyst contributes to design as well and we need to have
> > > an understanding of user interaction and interface design principles
> > >
> > > * We need to have basic testing skills ("thinking like a tester"
> > > see
> > > http://softwareeducation.wordpress.com/2009/09/17/36-testing-heuristics/
> > > and http://testobsessed.com/2007/02/19/test-heuristics-cheat-sheet/ )
> > > to help identify test cases and expose opportunities for improving the
> > > product
> > >
> > >
> > >
> > > I wrote an article for InfoQ which explains my thinking - it can be
> > > found at
> > > http://www.softed.com/Resources/Docs/The-Role-of-the-Analyst-in-Agile-Pr
> > > ojects.pdf
> > >
> > >
> > >
> > > That's my thinking in a few (???) words J
> > >
> > >
> > >
> > > I look forward to reading others' views
> > >
> > >
> > >
> > > Cheers
> > >
> > >
> > >
> > > Shane
> > >
> > >
> > >
> > > Shane Hastie, MIM, CBAP
> > >
> > > Chief Knowledge Engineer
> > >
> > > Software Education Associates Ltd
> > >
> > > DDI +64 4 924 1270 From Australia 1800 145 952
> > >
> > > Switchboard +64 4 568 7806
> > >
> > > NZ Mobile +64 21 590 255 Australia Mobile +61 450 604 413
> > >
> > > Web www.softed.com <http://www.softed.com/>
> > >
> > >
> > >
> > > Learn with the experts
> > >
> > >
> > >
> > >
> > >
> > > Join us for the world's best requirements training - "Mastering the
> > > Requirements Process" with James and Suzanne Robertson. Courses are
> > > running in Melbourne & Canberra (4 Nov), Wellington (9 Nov), Auckland
> > > (16 Nov), Sydney (30 Nov) and Christchurch (9 Dec). Call now for more
> > > details or visit www.softed.com <http://www.softed.com>
> > >
> >
> >
> >
>

Reply | Messages in this Topic (26)

#48

From: "Steve" <steve@...>
Date: Wed Sep 30, 2009 6:33 am
Subject: Re: Nailing my colours to the mast

flybynight107

Send Email

Hi Dennis

Thanks for the feedback...you raise an interesting point distinguishing between
the BA role and capabilities. Definitely the classical XP team will not have
anyone with the title BA, but someone(s) will be playing that role, whether its
the onsite customer or team member. The same is true of larger teams, while I
have never had the title of BA I usually get tapped to carry out the BA tasks.
This thread is somewhat timely because today I had a conversation with a
colleague about Business Analysis to which he remarked "that's what I did as a
program manager".

Steve

--- In Agile_BA_Requirements@..., "dennisstevens"
<dennis.stevens@...> wrote:
>
> Steve,
>
> Great discussion. I agree with pretty much everything you said. I did want one
clarification within the group.
>
> Are we writing about the Business Analyst role or about Business Analysis
capabilities? In your discussion below you say the XP team probably doesn't need
someone to be the Business Analyst, but aren't there still situationally
specific Business Analysis practices that would be useful to the XP team? As the
project gets more complex some additional Business Analysis practices become
appropriate. Even if these move to a Product Owner or some other role - they are
business analysis capabilities aren't they?
>
> My thought is that in emerging organizations, the Business Analyst may perform
some of the Business Analyst capabilities, facilitate others, and some may
belong to other roles. I think we need to be able to discuss the Business
Analysis capabilities and practices as they might exist in an agile team and
then provide some guidance on where they might be performed - regardless of the
specific role.
>
> Everything you said about the need to be a communicator, networker,
facilitator, and builder of back channels is true regardless of what role
performs the capabilities.
>
> Dennis Stevens
>
> --- In Agile_BA_Requirements@..., "Steve" <steve@> wrote:
> >
> > Ok its late and I'm tired, but  I'll toss my hat into the ring or raise my
colours...
> >
> >
> > First what is agile about? There are two basic assumptions behind agile,
change happens and people trump process. In an environment of change, the
utility of detailed plans and requirements is limited at best. Rather what we
need is an adaptive approach. Ken Schwaber suggested software development is
much more like an empirical process which that requires  monitoring and
adjusting  in real-time. Real-time here means if its late, its wrong. Practices
that delay our ability to monitor and adjust will lead to less than optimal
results. The agile methods offer us light weight practices that enable us to
quickly try something, obtain feedback and adjust. This in my opinion is really
what agile is about, can I create a process for my project that allows me to
make decisions about my project and take action in a timely manner.
> >
> > For a small project, a method like XP enables very fast decision cycles,
wonderful for a project where things could be changing by the day. It is
unlikely projects like these require a BA, and our enterprise here will have
little utility to people involved in these kinds of projects.
> >
> > The BA role came about because as projects became more complex customers
were not usually capable of understanding the technology behind the system and
tech people were not usually capable of understanding the requirements. Then of
course there is the problem of resolving competing interests. These problems did
not go away with agile, so the BA still is an important role regardless of the
method.
> >
> > But what does the BA do in an "agile" environment, write user stories? Well
let me use the consultant's mantra "...it depends..." One thing I do know for
sure is the BA needs to be much more of a communicator, networker, facilitator,
and builder of back channels. The very best BAs already know this, and I
strongly believe the best work that will come from this group is to place
interpersonal skills at the very heart of the profession and the BA BOK. Right
now I'm a little disappointed this topic is dealt with almost as an afterthought
in the BA BOK.
> >
> > The practices available to the Agile BA will depend a lot on the
organization they are part of. Here I want us to think very carefully about
distinguishing practices as either governance or coordination. Governance are
the immutable practices a project must comply with for either regulatory or
internal policy requirements. Coordination is the set of practices we have in
place that enable people to work effectively together. A mistake we commonly
make is that we use our governance practices for coordination. For example, why
do we produce an SRS? Is it because it is required by law or as internal
corporate policy? Ok fine, but do our developers and testers need it to do their
jobs? In fact could the SRS be getting in the way of the developers and testers
doing their job effectively? In this situation, produce the SRS, but do not use
it as the only mechanism for communicating requirements to the developers and
testers.
> >
> >
> > Now I'm going to step out into much more controversial territory, why the
distance between Business Analysis and Quality Assurance? In many methods they
are at opposite ends of the life-cycle and yet in many ways should be working
closely together.  The most accurate, and up to date specification for a system
are the tests. In XP there are no quote requirements, just stories which are
requirements place holders. The tests are the real requirements. Part of our
work therefore must be to develop recommendations for practices that bring these
two disciplines closer together.
> >
> >
> > My bottom line, in my opinion I believe the BA will take the brunt of
managing impedance mismatches between the different corporate process in place
for the creation of software. The software development team itself may be
"agile" drawing stories from their backlog and creating "potentially shippable
product" every few weeks, but the surrounding organization may be much more
traditional. The Agile BA are some of the people who will have to be flexible
enough to satisfy the needs of all the processes involved in the creation of
software.
> >
> > ok its bedtime for me, good night everyone
> > Steve Adolph
> >
> > --- In Agile_BA_Requirements@..., "Shane Hastie" <shaneh@>
wrote:
> > >
> > > Hi Folks
> > >
> > >
> > >
> > > I proposed we do this, so I'll start.
> > >
> > >
> > >
> > > I do like Chris's goal of "A comprehensive knowledge base for anyone
> > > interested in Business Analysis and Requirements in Agile" - I would
> > > expand Agile to "Agile software development", although these principles
> > > apply to other types of projects we are focused on software development
> > > (or are we??).
> > >
> > >
> > >
> > > My feeling is that the fundamental skills of business analysis remain
> > > vitally important in Agile projects.  These skills include
> > >
> > > *         Communication
> > >
> > > *         Facilitation
> > >
> > > *         Investigation
> > >
> > > *         Persuasion & influence
> > >
> > > *         Presentation
> > >
> > > *         Analysis (the ability to examine a problem and break it apart
> > > into manageable bite-sized chunks)
> > >
> > > *         Synthesis (the ability to visualise solutions and identify
> > > components of those solutions)
> > >
> > > *         Modelling - the ability to represent complex problems in
> > > simple terms using effective representation techniques
> > >
> > > *         Business process identification and business process
> > > improvement understanding (IT projects are ALWAYS about
> > > changing/improving business processes - computer systems are enablers of
> > > business processes, not the reason for business processes)
> > >
> > > *         Requirements identification
> > >
> > >
> > >
> > > There are a number of ways that the Analyst role changes (compared to
> > > "traditional" approaches), including:
> > >
> > > *         When we undertake analysis - there needs to be some (minimal)
> > > analysis up front to understand the "shape" of the project, identifying
> > > the user stories/use case briefs (or whatever your team calls them -
> > > high level requirements which can be prioritised and estimated), and
> > > then expanding the analysis to the detailed requirements (acceptance
> > > criteria/detailed use case scenarios/feature details ...) on a Just in
> > > Time basis.   This conscious deferment of detail until it is really
> > > needed (one iteration ahead at the most) prevents psychological lock-in
> > > or fixation so we are prepared to accept change.  One of the issues with
> > > BDUF (even if it is done well) is the emotional investment in the work
> > > done results in a natural resistance to change ("they don't like my baby
> > > - waaaah")
> > >
> > > *         We are not solely responsible for "gathering" requirements - I
> > > see the Agile Analyst role as the "shepherd of stories" - like the
> > > shepherd in the field (I come from New Zealand after all, we're an
> > > agricultural economy) we have a responsibility to ensure that the herd
> > > moves in the right direction, is protected and nurtured to grow and
> > > mature but we don't own the sheep - we are an agent for the owner (the
> > > business stakeholders who have the real need)
> > >
> > > *         The analyst contributes to design as well and we need to have
> > > an understanding of user interaction and interface design principles
> > >
> > > *         We need to have basic testing skills ("thinking like a tester"
> > > see
> > > http://softwareeducation.wordpress.com/2009/09/17/36-testing-heuristics/
> > > and http://testobsessed.com/2007/02/19/test-heuristics-cheat-sheet/  )
> > > to help identify test cases and expose opportunities for improving the
> > > product
> > >
> > >
> > >
> > > I wrote an article for InfoQ which explains my thinking - it can be
> > > found at
> > > http://www.softed.com/Resources/Docs/The-Role-of-the-Analyst-in-Agile-Pr
> > > ojects.pdf
> > >
> > >
> > >
> > > That's my thinking in a few (???) words J
> > >
> > >
> > >
> > > I look forward to reading others' views
> > >
> > >
> > >
> > > Cheers
> > >
> > >
> > >
> > > Shane
> > >
> > >
> > >
> > > Shane Hastie, MIM, CBAP
> > >
> > > Chief Knowledge Engineer
> > >
> > > Software Education Associates Ltd
> > >
> > > DDI +64 4 924 1270   From Australia 1800 145 952
> > >
> > > Switchboard +64 4 568 7806
> > >
> > > NZ Mobile +64 21 590 255   Australia Mobile +61 450 604 413
> > >
> > > Web www.softed.com <http://www.softed.com/>
> > >
> > >
> > >
> > > Learn with the experts
> > >
> > >
> > >
> > >
> > >
> > > Join us for the world's best requirements training - "Mastering the
> > > Requirements Process" with James and Suzanne Robertson.  Courses are
> > > running in Melbourne & Canberra (4 Nov), Wellington (9 Nov), Auckland
> > > (16 Nov), Sydney (30 Nov) and Christchurch (9 Dec).  Call now for more
> > > details or visit www.softed.com <http://www.softed.com>
> > >
> >
>

Reply | Messages in this Topic (26)

#49

From: Kevin Brennan <kevin.brennan@...>
Date: Thu Oct 1, 2009 11:46 pm
Subject: Re: Re: Nailing my colours to the mast

kevinjbrennan

Send Email

On 2009-09-29, at 2:23 AM, Steve wrote:

> But what does the BA do in an "agile" environment, write user
> stories? Well let me use the consultant's mantra "...it depends..."
> One thing I do know for sure is the BA needs to be much more of a
> communicator, networker, facilitator, and builder of back channels.
> The very best BAs already know this, and I strongly believe the best
> work that will come from this group is to place interpersonal skills
> at the very heart of the profession and the BA BOK. Right now I'm a
> little disappointed this topic is dealt with almost as an
> afterthought in the BA BOK.

This one probably warrants a little explanation...

When we (that is IIBA) launched the development of the BABOK there
wasn't a lot of consensus out there as to what a BA was or what a BA
should do. A major purpose of version 2.0 of the BABOK was to nail
that down...we were much more focused on being able to answer the
question "what is business analysis" than on trying to answer "what
makes a good BA?". Essentially we felt (and were advised by others,
such as PMI) that we had to get consensus on the first point before we
could hope to get anywhere on the second.

To a large extent I have to say that they were right...it took a lot
of work to reach consensus within the team regarding the BA role and
there were a lot of disputes (for those of you who have read the
BABOK, there are a number of places where people complained the text
was too pro-Agile, for instance). That said there are things that I
would do differently if I had to do it all over again, and one of them
is that we would probably have taken a more competency-based approach
to developing the BABOK Guide. That said, it's not a huge issue--I
have a team of volunteers building a competency model for BAs right
now based on the BABOK Guide, and it turns out our structure supports
that pretty well. By the time version 3 comes out we'll have actual
data on the kinds of interpersonal skills and qualities that make for
a good BA and will revise things accordingly.

One thing that I can say that's interesting is that we are seeing a
real gap between what BAs understand to be important and what they're
actually doing. While the exact figures are confidential, I'm sure it
won't surprise anyone to know there's a marked difference between what
BAs say is critical to be effective and where they are actually
spending their time. In theory, BAs acknowledge that defining the
problem (the Enterprise Analysis KA) and validating the solution as
delivered against the business need is at least as important as the
specification of requirements. But in practice, most of their time is
being spent on specification.
________________
Kevin Brennan, CBAP, PMP
Vice-President, Professional Development
International Institute of Business Analysis (IIBA�)
"Helping Business Do Business Better"
www.theiiba.org
kevin.brennan@...
Office: (416) 233-8743

Reply | Messages in this Topic (26)

Yahoo! UK & Ireland Groups

Group Information

Yahoo! Groups Tips

Did you know...

Messages