From : Chris Matts
Reply-To :
Sent : Wednesday, March 29, 2006 2:17 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Hi Jeff, Kent. Long time no speak. Hello David
Lets get something straight. There is a place for business analysts within Agile. Business Analysis is not about writing documents though.Lets get something else straight. The reason Agile says they do not need them is because approximately 98% of BAs are crap. I should know I have interviewed close to 100 in the last year or so. One of the problems is that no one knows what a BA is. I do (from my perspective) and as a result I have tried to train the 20 people in my department to do the role. Guess what..... they are lazy/scared and do not want to change.........
Does this sound like Agile?Drop me a line and we can chat when I'm sober.
Chris
From : David Wright
Reply-To : agileanalysis@yahoogroups.com
Sent : Thursday, March 30, 2006 6:03 PM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
Chris, what are you drinkin'? I think I could use some too...
"Business Analysis is not about writing documents though."
Right, it is about documenting Requirements, which is different.
I have written about this a fair bit at
http://www.businessanalysis56.blogspot.com/
From : Kevin Brennan
Reply-To :
Sent : Thursday, March 30, 2006 7:41 PM
To : agileanalysis@yahoogroups.com
Subject : Re: [agileanalysis] Any activity in this Group?
Chris Matts wrote:> Lets get something else straight. The reason Agile says they do not need> them is because approximately 98% of BAs are crap....
That's one of the big reasons the IIBA got started. The goal behind developing the Body of Knowledge and associated certification activities is to try and get people to understand what a BA does and does not do. I agree, it's hard to find someone with the right general skills.A big part of the problem is that a lot of BAs are "accidental"; they get seconded to the job as part of an IT project and then become a"Business Analyst" because their old job got filled while the poject was going. The result is that many BAs are little more than above-average end users with no special training or aptitude for the role.-------------------------------------
Kevin Brennan, PMPCo-Chair, IIBA Body of Knowledge Committeekevin.brennan@theiiba.org
From : Jeff Patton
Reply-To : agileanalysis@yahoogroups.com
Sent : Friday, March 31, 2006 8:24 AM
To :
Subject : RE: [agileanalysis] Any activity in this Group?
:-) Good to hear from you Chris! Although Chris might be drunk, his point isn't completely off. I'll be honest. I work alongside business analysts in agile contexts, and struggle with their thought processes at times. I consider myself an interaction designer. I work with end users and business stakeholders, talk with them about their goals, build models, think hard, and work to arrive at solutions that optimize business's return on investment while meeting user goals. I call that work design. The BAs I work with do very much the same work, only they refer to it as requirements capturing. I struggle with the term requirements capture vs. design. For me design implies some creativity and invention - and most importantly some responsibility. Requirements capture doesn't imply any of those things to me - sounds sort of like a passive thing that requires good listening and recording skills. Although I know that if I pick up any decent book on requirements work, I'll find the words creativity and invention in it - I just won't find the words design in it -at least not in reference to what the BA does. I sometimes wonder if that posture of elicitation and capture vs. a posture of responsible design isn't part of the key to their effectiveness - or lack thereof.
Although I'm not drunk, my plane is over 3 hours late and I'm ticked off and stuck at the airport. So if this sounds inflammatory to BAs - I'll blameUnited Airlines.
Cheers,-Jeff
From : David Wright
Reply-To :
Sent : Friday, March 31, 2006 9:58 AM
To : agileanalysis@yahoogroups.com
Subject : RE: [agileanalysis] Any activity in this Group?
In short, having Requirements first supports the choice of solution, which may not always be to design and develop something new.I can't recall where I first heard this mantra-like statement, but it has stayed with me:
"Re-Use before Buy, Buy before Build, Build for Re-Use".
Requirements are like blue-prints, especially those using models. If system delivery and software development (which are not always the same thing) are to move beyond being a craft to a real discipline, we have to stop starting with Design and know What to build before we decide How.
Dave Wright
>From: "Kent J. McDonald" mailto:kent@kentmcdonald.com
Reply-To: agileanalysis@yahoogroups.com>
To: agileanalysis@yahoogroups.com>
Subject: RE: [agileanalysis] Any activity in this Group?>
Date: Fri, 31 Mar 2006 21:13:11 -0600>>
Is it necessarily a bad thing that Software Development is a craft?
>-->Kent J. McDonald>kent@kentmcdonald.com>http://www.kentmcdonald.com>Words to lead by: Collaborate; Iterate; Serve the Team; Consider Context;>Practice Excellence; Reflect and Adapt; Deliver Value
From :
David Wright
Reply-To :
Sent :
Saturday, April 1, 2006 9:22 PM
To : agileanalysis@yahoogroups.com
Subject :
RE: [agileanalysis] Any activity in this Group?
"Is it necessarily a bad thing that Software Development is a craft?"
A craft-work approach to delivery implies custom-made, low-volume and high-cost results. Shoes haven't made by cobblers for a century or two, and just because software is a relatively new and uniquely malleable product, this does not mean it won't and shouldn't be produced using engineering-based production methods. This will be the way software will become a product where quality is assumed, not just hoped for.
What implications does this have for programming as we know it? It will become less and less of a technical creation skill amd more of an assembly role, putting together software components to create systems.
(If that upsets any programmers reading this, well, I have been out drinking some single-malt tonight, so my opinions may be a little direct by this time of night.... :-) )Dave W
1 comment:
I welcome the above mentioned bashing. BAs do a thankless job indeed, and most of them dont love what they do, which is why they dont try and justify what they do.
I believe that the importance of a BA can only be realised by studying a scenario which lacks a BA.
Be it agile or waterfall, in the absense of a BA, the stake holders will have to interact with the developers. This is taking software development to where it was nearly 50 years ago. The customer will give his requirements, and the developer would be able to compel the customer to signoff his development. He could do that gradually (agile) or using gun point convincing (waterfall) just before the release date.
Had a BA been there, he would have stood up for actual customers expectations, and must have explained him the developers constraints. He would not be appriciated by either, but the deliverable would be like it should have been.
Thats all for now, looking forward for your responses.
Post a Comment