Agile + Business Analysts, A Marriage Made In Heaven Or Head Straight To The Divorce Courts?
A while ago I posted up Chicken and Pig Make Breakfast - A Scrum Team Story which gives the background to describing a useful and effective Scrum team members as either "pigs" (a team member that is committed to the success of the project) or "chickens" (a team member that makes contributions to the success of the project).Amongst chickens I included Business Analysts "(mostly)".
Yesterday I had a coffee with a top BA to discuss her agile wedding project (the whole thing came together successfully in 6 weeks - all without a Gantt chart :-) and flicked her the above link. She had a view on what I wrote and this is it:
I must admit I've often been called a headless chicken - that's because I'm running around trying to juggle the needs of the pigs (what do we do now) and the chickens (we want this now)! However, as you can understand, I don't really agree with your inclusion of "Business Analysts (mostly)" being lumped in with the chickens. A lot of the time we are the ones trying to make sure that everyone is on the same page with regards to meeting the needs of the project - do we understand what the client wants, does the client understand what they want, are the requirements clearly articulated, what is the cost benefit, are the developers developing just what is required (not too much/not too little), what is the actual problem that we are attempting to resolve, etc.
BA's are pigs because we want to know what nuance of ham the farmer wants - smoked, uncooked, on the bone, no bone, sliced, shaved, rolled, glazed, unglazed, par-boiled, canned, shrink-wrapped, prosciutto, sausages, pink, green, etc...and we'll also find out how the farmer wants his eggs delivered so we can tell the chicken how/when to lay them.
I reject the inference that what we do doesn't really add any value to an Agile project. Requirements elicitation and validation should be considered valid pieces of work because without them none of the other pigs (developers, designers and testers) will have anything to do. Sure, you might decide not to have a dedicated BA on an Agile project, but there will be someone fulfilling that role.
In fact, if we take that one step further, our job as BA's is to ensure that the client's needs are fully understood in terms of their impact on the enterprise (company). If it doesn't meet the strategic imperatives, then why do it; is technology the answer or are we just wasting everyone's time when a tweak to business process would fix it.
There y'go, my $6.50 worth!
Hmmm ... my view is that if a BAs role is only "requirements elicitation and validation" then I definitely put them as Chickens as the true Pigs in that piece of work is the business person asking and the developer (say) doing. Why not get out of the way and let them get on with it? The assumption is that both "pigs" are mature and experienced enough to talk to each other. But if we don't approach work from this as a default position we will always start with a bridge when we may have no need.
As for my mate's second point:
ensure that the client's needs are fully understood in terms of their impact on the enterprise (company)
I whole hearted agree - that is "analysing the business" and a valid role in a lot of projects be they agile or not. However, that's not what a lot of BAs do due to lack of experience/understanding from the BAs themselves or the company/environment they work in.
YOUR VIEW? What do you think - leave a comment
Why do I talk about "agile", because it's part of "What I can do for your organisation":
Help you become an 'open' organisation with special attention to:Gain tangible benefits from on-line collaboration:
- What it means for organisational culture
- Use of Open Source software
- Where agile techniques fit in
Introduce and grow the use of Google Apps
- Generating good information, communication and connections
- Stories from those that have succeeded
- Hints, tips and traps for young players
- Software-as-a-service for business email, information sharing and security
- Getting benefits from the ever expanding toolset
- Hints, tips and traps for young players
See also:
- On Business Analysis in an Agile Setting
- Rethinking the Role of Business Analysts: Towards Agile Business Analysts?
- Google "agile business analyst" search results
Flickr picture credit: Three's a Crowd, Originally uploaded by melodrama maniac
It's a tricky question because agile means different things to different people and business analysis means different things to different people.
ReplyDeleteHowever, your friend nails it with this quote: "Sure, you might decide not to have a dedicated BA on an Agile project, but there will be someone fulfilling that role." On the project I'm working on at the moment (with Mike), I'm the dedicated BA. However, Mike is often playing a BA role - going out to the business, determining needs and requirements, documenting them (in the Wiki :). I happen to be playing a different BA type role - but I am committed to the success of the project and as I understand it, that makes me a pig (I've got just as much "skin in the game" as anyone else!)
Anyway, gotta go to the gym now. I might write a longer comment later :)
Hmmm, I'd agree with your friend on this one. If it was my business I would definitely want the "business person" representative working with the developer to have those BA skills!
ReplyDelete@becs027 That's fair enough, the skills should be present but wouldn't it be fantastic for that to be shared by the "business rep" and the "developer" and then a whole (potential) bottleneck can be removed.
ReplyDelete@Dr Tim (nice) I hear you and agree. But a dedicated BA isn't necessarily someone that provides a direct input into growing working s/w. Traditionally (such as we are both having to do) the B/A writes documents and rarely gets to see/create the working software.
I s'pose my point is how useful is traditional BA work to the user? If it gets working s/w to the users then fine. However BAs are usually caught up in "process" and forget why they are doing it.
Oh, and still think that most NZ BAs don't actually "analysis business" but are either functionality documenters and/or cut-down PMs
the comment can equally be made about most PMs. In my view, there are very few BAs or PMs who contribute significantly to an agile process, but it is dependent on the developers.
ReplyDeleteOften however, I find a BA type role can be useful in documenting detailed rules (eg: validation) that it would too time consuming for a developer/bus rep combo to sort.
Interesting take on this BA/agile discussion over at the Fronde blog: http://www.fronde.com/blog/?p=318
ReplyDelete@Mike: I just noticed your reply now :) Oddly, on one of the projects I'm currently working on, I have sat with the developer and peer-programmed. My knowledge of the business and his of the technology let us make the necessary changes very very quickly. However, I suspect that's very a-typical activity for a BA :)
ReplyDeleteThere is a key element that has been missed here entirely: the role of the analyst is not purely "requirements elicitation and validation", that is the first part. The second part is understanding how those requirements might fit into a solution. In the olden days of waterfall, there was often a 'Requirements document' followed by a 'Functional specification' document, both produced by the analyst. The first was all about business reuqirements, and the second was a logical view of how those requirements were to be implemented. Here you would find state charts, DFDs, and activity flows for the more complex areas. This is the element of a BA's role which is missing in this discussion. And there is still room for this logical level thinking in an Agile environment: logical problems still need to be solved.
ReplyDeleteAgree with you to a point. If someone's role is just "requirements elicitation and validation", then they are really nothing more than a glorified secretary, and unfortunately there are too many people stuck in roles like that. The key is in the second word "analyst", that’s the value a BA adds.
ReplyDeleteIn any case, presenting this as an argument that 'anyone other than the product owner and developer just gets in the way' distorts the majority of mainstream literature on agile, which typically describes a scrum team as cross-functional, i.e. not just developers.
As an example – on the agile projects with which I've been involved, there was full and part-time involvement from: business product owner, user experience designer, solution architect, web-page developer, web-service developer, tester, business analyst (who often stepped in as a delegate for the product owner), and project manager (who often fulfilled the role of scrum master). Sometimes we’d have team members who could combine more than one role (e.g. a BA with UX experience, or a developer who could code server and client side), but more often we’d have specialists – and that’s usually better than working with generalists.
I think the starting propoition is wrong. I know it's scrum folklore that the PO (BA) isn't a pig, but in the enterprise context it is the customer facing people - the BA or PM - that take the heat from sponsors and stakehodlers.
ReplyDeleteThey are often the ones who have their reputations most firmly attached to successful delivery.
Context matters.