Yesterday, Craig Brown asked Do we need Agile Business Analysts?. Two and a half years back when I joined ThoughtWorks, I would have said "No, we don't". Today I strongly disagree with the view that Business Analysts can be done away with on Agile projects.
The objective of an Agile project is to provide maximum value to the client as soon as possible.
Now I agree that the ideal situation would be when you have business users & developers who agree and abide by this sentiment. You can happily get rid of the BA in such a situation. Real life, for some reason, is never ideal.
Anyone who has interacted with business users on a medium to large project will have faced situations where it has been hard for the business users to come to a consensus on what they want. Business users are generally representatives of different functions of the organization. Each of them has expectations from the application which more often than not are conflicting. Keeping these users focused on what we set to achieve when we started building the software is what a BA does.
Being on an agile project gives the business users many chances to dream, many chances to make changes. Developers are human too. They dream about technology. While sometimes this can lead to some really cool/unique/usable feature in the product, it can also lead to "overcoolified unnecessities". Now in an ideal situation, all these dreams would come true. Unfortunately, dreams in the real world are bound by budgets & deadlines. Managing these dreams, ideas, changes so as to keep them aligned to the original business objective and deliver most value in the given time and budget is what a BA does.
What agile aims at, is to start minimal and change as required. When a small bug on a story turns out to be a big chunk of enhanced functionality, we create a new story. The tasks mentioned above, along with writing user stories, supporting implementation of the functionality, planning the iterations and releases, testing the developed functionality, etc. together makes for a considerable chunk of work. That's when you create a seperate role called Business Analysts.
Now this role can definitely be performed by developers. In my experience, though, good developers don't really want to do any of this. They want to write good code. That's what they are best at. That's where they will deliver maximum value.
Hence Business Analysts.
The objective of an Agile project is to provide maximum value to the client as soon as possible.
Now I agree that the ideal situation would be when you have business users & developers who agree and abide by this sentiment. You can happily get rid of the BA in such a situation. Real life, for some reason, is never ideal.
Anyone who has interacted with business users on a medium to large project will have faced situations where it has been hard for the business users to come to a consensus on what they want. Business users are generally representatives of different functions of the organization. Each of them has expectations from the application which more often than not are conflicting. Keeping these users focused on what we set to achieve when we started building the software is what a BA does.
Being on an agile project gives the business users many chances to dream, many chances to make changes. Developers are human too. They dream about technology. While sometimes this can lead to some really cool/unique/usable feature in the product, it can also lead to "overcoolified unnecessities". Now in an ideal situation, all these dreams would come true. Unfortunately, dreams in the real world are bound by budgets & deadlines. Managing these dreams, ideas, changes so as to keep them aligned to the original business objective and deliver most value in the given time and budget is what a BA does.
What agile aims at, is to start minimal and change as required. When a small bug on a story turns out to be a big chunk of enhanced functionality, we create a new story. The tasks mentioned above, along with writing user stories, supporting implementation of the functionality, planning the iterations and releases, testing the developed functionality, etc. together makes for a considerable chunk of work. That's when you create a seperate role called Business Analysts.
Now this role can definitely be performed by developers. In my experience, though, good developers don't really want to do any of this. They want to write good code. That's what they are best at. That's where they will deliver maximum value.
Hence Business Analysts.
Interesting thoughts. In a recent project, a person on the client side filled the BA's role, which produced superb results.
ReplyDeleteI agree about the developer´s point of view.
ReplyDeleteWe are implementing a new process involving BAs and system analysts. BAs work on the BRD (mostly use cases and static models), and they get from there.
This week a developer came to talk to me about their documentation, what they should use, what they should consider and he was concerned about requirements tracking, and I said that it has no use for us because we describe our functional requirements on use cases.
I don´t want to discuss the approach, the interesting part is what he asked and it was "what if the client asks to change something in the middle of the project, how do I track it back?"
I said, "dude, they won´t, we fight till death to guarantee stable requirements before you do your analysis, that won´t happen".
Well, the look is his eyes betrayed the feeling of taking a hundred tons from his back, now he could focus.
Ok, it´s a big promise, but we are handling it well since we showed the client that a good business analysis is the basis of a good project managing that´s the basis of something they love: to be sure of something.
Another interesting stare I received came from the UI designers when they heard they would get well described and again, stable functional requirements from us.
I believe we have a big gap to fill and someone should treat the other parts of the process as clients. We do it.
Damien, Just a quick question. Was this "client side BA" from the client's IT Department?
ReplyDeleteIf yes, I am not too surprised that it worked out well.
If not, I am happy to know that the ideal situation (Clients understanding and abiding by the business objectives) is also realistic.
Also, is this an agile project you are talking about?
Great Blog! Thank you for keeping us informed.
ReplyDeleteShane Grady
Thanks for the comments Akshay. I'm glad my post is stimulating discussion.
ReplyDeleteCraig
Better Projects
I'm having a hell of a time finding business analysts for agile or even waterfall projects. Do you think that training a BA in agile development differs than training them for a Waterfall methodology project?
ReplyDeleteTraining a BA in agile is definitely different than training a BA in waterfall.
ReplyDeleteThe basic requirement gathering practices are mostly the same, except that agile prefers more face-to-face communication. What differs is what the BA does after gathering requirements.
A waterfall BA will put them into a requirement specification document while an agile BA will be required to
1) Split them into user stories (with the INVEST principle).
2) Define short, valuable releases with the help of the customer
3) Support the development of all these stories
4) Test the developed functionality
and all this to be done everyday.
On what a BA does...
ReplyDeleteRegardless of projct development approach all BAs should endeavour to get as much face to face contact with BOTH the project stakeholdes and the development (solution) team as possible.
Additionally they should be managing the requirements through the project liecycle, just lik a product manager.
They should constantly be assesing and reassessing whether specific sets of requirements are going to add value, where they sit in the project priorities, and how value will be deliverred by their inclusion.
Good business analyst and requirement management work, just like good project management sits above any one type of methodology.
Having said that, if you have a BA that is excellent in waterfall, they will probably be excellent at Agile.
The thing is though; it's not document quality that demonstrates whether a BA is excellent. It's project outcomes.
Valuable Blog:
ReplyDeleteIT Role matures in a ZIG ZAG motion:
let me explain-
Every role in a project has its own unique value and in IT projects we have a notion to undermine that. If we see an excellent developer the expectation would be to promote the person to a project leader/BA/PM/Lead consultant
i mean to a role depending on a comapines requirement. mostly a non-linear approach is applied. The same happens with BA's, belied is ny one can do what a BA does. and i stronlgy disagree with this.
BA is skill set which has its own KPI and values like anyother Role set. We cannot expect a PM to be a developer and the same way we should expect the same developer to excel at BA skill set. They two are unique in their respect.
the other issue i see is that the BA skill set is highly undermined, people dont realize the value and importance of it. and thats why it gets easy for organisations to play with the role. No one will replace a developer with a BA.
Now on AGILE or Waterfall and the role of BA in the two:
Fundamental Role of a BA remains constant no matter what methodology we work in i.e. a bridge between User/stakeholder community and Devleoment team. Our basic role is to undertsnad the strategic and tactical needs of the objective outlined in the business case and make sure project and business team undertsands that.
Now Agile to me is a tool to timebox the business needs. Challenge with IT systems are that the end result or objectives are virtualk in nature hence users cannot judge or picturize all the requirements at the very outset of any project and this is where the problems starts to originate.
Changes manifest due to surprise elements. thats why requirements gets defined better progressively. Agile works or targets the drawbacks embedded within the waterfall method. i.e. limit the though process. Lets work in a iterative fashion focus on quick wins and progressively build the project. which only a BA should be able to do.
Agile Business Analysts nice blog post!!!!
ReplyDeletetop analytics companies
Analytics for Micro Markets
Business Analytics
business data analysis