This question has been asked several times before, and various answers have been advanced to settle this matter. A short answer is ‘yes’. But, unfortunately, this answer is not good enough to the ‘naysayers’, who think a business analyst has no place in Agile teams.
To answer this question in a long way, we have to take the bull by its horns and talk about the elephant in the room. This article is an attempt to contribute to this ongoing debate. Whether you agree with me or not (as I tackle this elephant in the room), the truth is - this argument is apposite and has to be had.
How about some root cause analysis?
Firstly, why do we find ourselves – as business analysts – with our backs against the wall, and at pains to justify our existence? I strongly believe the origins of our problems in Agile teams lie in the founding of the Agile manifesto itself. This manifesto was founded by a group of developers – and it is a fair argument to put forward that developers’ primary driver is to showcase their skills and expertise through writing code that works, and not necessarily worrying about whether this code addresses business or customer needs.
Is it by accident that the scrum framework does not mention the ‘business analyst’ role, but mentions only three roles - the development team, the product owner and the scrum master? The power of ‘naming’ things cannot be under-estimated. This is where the loss of ground for business analysis begins. In a very casual manner, the ‘development team’ is always interpreted as referring to developers, testers and (sometimes) business analysts. It is an apt question to raise whether the Agile manifesto, from inception, carried due recognition of the critical role played by business analysts in the product development process.
Whose perspective is it, anyway?
With this comes a point of perspective, which is embedded in our subconscious. The developers (in most cases) look at the world through the lens of technology. They get a kick from trying out new technologies. When left to their devices, their point of departure is probably from showcasing their adeptness on the latest technology, and what they can do with it. They do not necessarily depart from a point of view of whether the technology is talking directly to the business needs.
Yes, some of the advances in technology have indeed given birth to new business models. However, for these models to be business and customer-centric, a business analyst is the necessary ingredient to make them ubiquitous and sustainable.
The biggest conundrum to deal with is whether business analysts are stepping up to claim their rightful place in these situations. So, if a developer writes a user-story, whose perspective is s/he representing? Surely, it cannot be that of business. The business analyst is one person who holds the perspective of business in an Agile team, not the tester, not the developer and not the scrum master.
But, are BAs only good for writing user stories?
The question of recognition of the BA skill in the Agile team is always met with a standard answer (almost sounding like a scripted one) – Agile is about T-shaped individuals. It is not about the roles, but about the team. If this is axiomatic, can developers be replaced by business analysts? I do not think so.
This is because, if business analysts are T-shaped, then it means their core skills lie in business analysis and secondary skills (sometimes) in systems development. It is a rare occurrence to find someone who is strong in both business analysis and systems development (simultaneously). I am not saying that such skills combination is an absolute mutually exclusive occurrence.
The reality is that such a person is a rare find. And another reality is this: will business stakeholders be happy to accept an IT system developed by the T-shaped business analyst, with an understanding that the incumbent is strong in business analysis, but has working knowledge in systems development. I do not think so.
The systems development languages are evolving at such a high speed that systems developers have to continuously upskill themselves to keep up. The same applies to business analysis; it is a profession that is evolving, albeit not at the same rate as the systems development languages. So, how can a business analyst be expected to keep up with the developments in his/her field of business analysis and equally keep abreast of the developments in the languages of systems development? It is clear to me that a business analyst cannot replace a developer in the Agile team.
And so, how is it casually taken that developers feel they can replace or do a business analyst's work in these teams? This nonchalant attitude, in my opinion, is founded on one narrow-minded view of what a business analyst is, or does – someone who just writes ‘user-stories’.
The ‘T-shaped individuals’ and ‘self-organising teams’ is a convenient way of dis-empowering business analysts in the Agile world. It is self-evident that it is highly unlikely that stakeholders (including the ‘development team’) can easily accept when a business analyst says ‘because the developer has been booked off sick for the next two weeks, I will take over his/her ‘role’ and write the business function, procedure or method that he/she would have written – so that we can demo to the client at the end of Sprint X’.
One of the contributory misconceptions to the ‘lightweight view’ of business analysts, is the unfortunate and prevalent ‘malpractice’ that Agile replaces the activity and/or the nature of requirements elicitation (I am not talking about requirements representation) and all the necessary pre-work that needs to happen in the analysis phase. Agile advocates for the change in the intensity and duration of analysis, but not for the complete annihilation of the latter.
Nowhere does the Agile manifesto, including the 12 principles of this methodology, say analysis is completely unnecessary – it only argues against extended analysis that would normally end up with ‘analysis paralysis’. The Agile mindset argues that, while we do not have all the answers in terms of the details, we can proceed to start building in small increments, with the big-picture understanding of what is required.
We know how this big-picture fits in with the strategy of the business, and with the architectural lay of the land. To borrow from the finance and legal fraternities, one can say an Agile mindset cultivates an ‘ex post’ approach as opposed to an ‘ex ante’ one. Let us not spend too much time before building the solution, let’s rather learn from what we have built.
However, this approach does not mean going blindly into a project, wishing that all will work out in the end, because ‘we are Agile’. The understanding of the business context – such as, which levers to pull or push, which parameters we can operate within, etc - is a non-negotiable. It shows a lack of prudence on the part of a business analyst to waive the ownership of such understanding to the developers. The true owner lies with the business analyst working very closely with the product owner. This is where, as business analysts, we are short-changing ourselves. We waive our rights to own these conversations and thereby allowing developers to completely take over.
Agile is a delivery vehicle meant to make the process of systems development more efficient and less prone to omissions by emphasising collaboration in what I call the ‘production line’ and fast-tracking the decision-making during this process. People who work together, as experts in various fields of systems development, can decide in the quickest possible manner when they are in one conversation.
The ‘production line’ mindset
If we draw the parallels between manufacturing (motor) and IT (software development) industries, the scrum ceremonies (for instance) can be equated to the assembly or production line. However, in manufacturing, product development does not just begin by lining up material/parts into the assembly line. A lot of business-related activities happen way before a model is lined up for development. However, once the assembly line has been configured correctly, and all the business activities completed, then the production begins and seamlessly runs without any hiccups.
I feel that in software development using the Agile methodology, a lot of business-related activities are skipped and we go straight into the production line. Once we are in the continuous production line, we end up being frustrated and say the methodology does not work. This is where we miss the boat, because the focus is so much on the production line (the Agile ceremonies), culminating in the churning of the user stories – everything else that precedes the user stories is not given as much emphasis. These activities should be owned by business analysts. I am of the view that this ownership is feeble, as business analysts continue to second guess themselves.
Being caught up in the production line, business analysts do not get to do what they should be good at – which is based on two core skills: analytical thinking and logical thinking. Analytical thinking is about is the ability to decompose the whole business (with its complexities) into smaller components, to understand how these smaller components contribute to the generation, replication and sustainability of value. These small components are not only conveyed to the customers through the IT systems but also through business processes. How then can business analysis be about only writing user stories?
User stories are not business requirements. They are an encapsulation of business, functional, non-functional requirements and business rules. They express the end state, the wish of a customer. But to fulfill the wish of a customer, business needs to ensure that it has its ducks in a row, by making sure all the underlying business processes (including customer support) are in place, once that wish of the customer has been automated through an IT system. Can a developer think of that? I don’t think so. A business analyst is tasked with that responsibility – the interest of business is to ensure that all the smaller components have been analysed properly (not extensively).
What does it mean to ‘understand business’?
I believe that when we speak of ‘understanding business’ we do not put things into perspective. I am sure most business analysts – especially junior to intermediate (and some senior as well) – are always confronted by the vagueness of this phrase. The picture below – which depicts the organisational architecture – provides a view of the lengths and breadths of what a business analyst should grasp to demonstrate an accurate understanding of business.
What skills does a BA bring (beyond writing user stories)?
The logical skill talks to the ability to sequence activities in a manner that enables business not only to satisfy the wish of a customer but to be able to support this wish as well – post-IT system production. What is the point of rushing to satisfy the wish of a customer to be able to order his bank card online so that he can withdraw cash at the ATM or swipe at the POS if the card production partner is not ready to timely receive and process orders of those bank cards?
The developer can write the API to interface with the card production partner – but who owns the data that needs to be passed on? Surely not the developer, because he/she is not close enough to the business to understand the nature of the data, that being a must-have versus the one that is a nice to have. Who understands the business process of the card production partner – surely not the developer or the tester? So, how can a developer replace a business analyst in the Agile team?
Logical thinking is about use case thinking. I am not saying business analysts in Agile should write use case narratives, but surely they should possess use case narrative thinking as a skill. The ability to understand how the solution will logically flow into the existing or new business processes to offer a seamless customer experience is a good example.
If the business analyst does not fully understand the entire business processes, how can he/she then claim to understand the business he/she is servicing? I am of the view that business analysts who are thrown into an Agile environment’s production line are deprived of the logical thinking discipline, which use case diagrams and narratives instill. The ability to own and define how exceptions and errors will be handled – from a user point of view (and not the developer’s). The reason why we end with ‘An error has occurred, please try again later’ situation is because business analysts are not owning that part of the logical flow. It is owned by the developers in the Agile world.
In closing, business analysis as a discipline has a lot of value to add in Agile teams. This value sits outside of writing user stories. The business analyst brings to the team a skill that no other team member possesses. The reason why this value is not fully realised in some (if not all) Agile teams is that business analysts are very operational in their thinking, and not elevating themselves to competently represent product owners.
Share