The Business Analyst’s Curse: a profession or a DYI thing?

What are Business Analysts?

Business Analysts (BAs) often find themselves quietly putting together threads of information, deciphering requirements, and navigating stakeholders’ expectations.

Yet, in the big picture of projects, the critical tasks performed by these analytical minds are sometimes dismissed as mere footnotes or relegated to the background.

So, that Business Analysts are disposable is common knowledge. After all, what is the point of a professional who has the following tasks:

Anyone, in their daily lives, can do this. In fact, does this profession make sense?!

Better yet, there is only one thing worse than a Business Analyst: a Business Analyst who works with Scrum!

And the Agile methodology?

We can describe the agile methodology as a method that is based on two basic principles: iteration and incrementation. It is known for being flexible, adaptive and customer oriented following the Agile Manifesto.

The great advantage is that it does not follow a plan from the beginning to the end of a project. It allows direction changes, more or less pronounced, and it is based on continuous collaboration between multidisciplinary teams.

Theoretically, it is the most effective way to bring a development to life, with the lowest possible risk, as it is based on the following concepts:

Sounds easy, right? But will it be that easy to get the machine rolling?

---

Get down to it: Agile classification

If I had to organize the five points on a scale of 1 to 5, where 1 is the easiest to put into practice and 5 the most difficult, this would be my rating:

First, the easiest: Scrum

You would expect that the most difficult thing to control would be the daily business, right? After all, Scrum has a series of rules that must be followed, as seen in the image bellow:

In fact, the events and personas that are described in the diagram are relatively easy to implement and serve precisely to assist the daily business.

To manage product development, work is defined in Product Backlog and the magic happens throughout sprints.

As a Business Analyst (with Product Owner functions), I see the four types of events in this work framework as a way of ensuring efficiency, whether in planning (sprint planning), reviewing what was done (sprint review) and even understanding strengths and points of improvement for the team (sprint retrospective).

And honestly, what could be better than a daily meeting for the development team to share what they did, what they are going to do, and existing roadblocks?

When it comes to organization, BAs can boast of being quite efficient. So, just add something almost innate to the advantages of a well-defined method and everything will work. But does the whole team think the same way?

If you want to go deeper into this topic, I invite you to visit the following article and take your own conclusions.

The second step: Multifunctional and self-organizing teams

Creating a multifunctional team that can organize itself on a day-to-day basis can be challenging and may depend on several factors such as company culture, leadership, communication with managers, team size and even the experience of the personas in agile methodologies.

But there is one thing that puts this point, in my opinion, in second place: a clear definition of objectives and tasks for each person.

With this, it is easy to know which task corresponds to whom and allow everyone to manage their time in the most efficient way possible. Furthermore, with effective sprint planning meetings every sprint, if people are responsible, it is safe to expect that there will be self-organization throughout projects.

However, it is up to the BA to ensure that the “machine is running without sand in the gear”: is the board up to date? Are there people who are blocked and afraid to share their problems? Does everyone have access to everything they need to work?

It starts to seem like a BA has a full day after all, doesn’t it?

It starts to get complicated: Incremental delivery

Theoretically, following everything described in the first point, this would be of equal complexity. Will it be?

Let’s imagine a scenario where the customer wants to exchange their OCR reader for a new supplier. So, it is necessary to develop full integration with what already exists. In this project, not one, not two, but three systems will be involved, which will only talk to each other through a fourth system.

The design is assembled and, therefore, everything needs to go smoothly. Until the pitfalls of incremental delivery begin to emerge:

Meanwhile, what is a BA doing? What a lot of people see: nothing. What a BA actually does: documentation, testing, speeding up communication between the various personas of the project (client included), testing, keeping requirements updated, opening bugs… did I mention testing?!

The beginning of the great challenge: Continuous Adaptation

Projects are made by people. People are themselves, constantly iterating projects, and a person is not based on binary code. There is much more on a person than zeros and ones… It’s easy to see why I ordered this as point fourth on the table: aversion to change!

Change is a much more complex verb than its syntax. It refers to the process of moving from one state, a condition or situation to another. It can involve transformation in several aspects: attitudes, behaviors, processes, and structures… It can be natural or driven, for example, by the search for improvement or adaptation. However, if a requirement can change at the speed of light, for a person to change, it is perhaps one of the most difficult actions.

Effective change management is very important, helping people and organizations to face transitions positively and take advantage of the opportunities that change can bring. How? Educating and communicating the effectiveness and benefits of incremental delivery and paradigm shifts throughout the project. Honesty and sharing are the basis.

Now, a BA is that person who “forces” others to accept and embrace change. It seems like things are starting to get complicated, right?

The big challenge: Collaboration and communication

If only it were as easy to communicate as it is to send messages through Kafka! Whoever agrees with me, raise your hand!

We return to the same: people.If we were MuleSoft APIs that can only transmit the information they receive, it could be easy. But we are beings that accumulate information and react to it. We map and transform data almost continuously, while we can change states (of mind), sometimes faster than calling an API. And, whether due to a lack of trust or too much trust, we tend to filter information, hiding fears and trying not to show weaknesses. So, this is when in the successful response blame (in others) and/or excuses (about what was not done) may arise!

When a BA/tester opens a bug in a given system, it doesn’t matter who developed that part that has a bug. The objective is just one: for the test to be carried out successfully and to deliver functionality to the customer.

But is this what the team feels? Human sensitivity and fragility are easily affected when our efforts are put into perspective. And truth to be told, who likes to fail?

So here come the difficulties in collaboration and communication: “that’s not mine”, “that’s from another system”, “it’s not my fault!”. Who has heard, or said, these phrases? All of us, at some point, for sure.

In conclusion, this point is the biggest challenge, as it is necessary to keep people focused on the solution and not the problem and convey the message that it doesn’t matter where the blame comes from, but rather where the resolution is.

The BA scope: to navigate daily challenges

With everything said until now, we can conclude that being a Business Analyst is much more than what the job description says:

• It is the Get…/daily-motivation and Put…/team-and-client-trust-and-encouragement APIs that always give 200 – Success.
• It’s being able to turn around each test that returns 500 – Internal Server Error.
• It’s not to despair when it must be Job Repeat-all-tasks.
• It’s learning how to fill in new mandatory fields that appear daily…
• And it’s especially about ensuring that the team is really a team and not just a group of people working together.

How can we achieve all this? With openness, honesty, being the first to admit failures and help with solutions and a lot of trustworthy daily work: being a BA, and adapting to everyone, without blame or excuses.

If it’s easy, no! There are days that really seem like a curse. But honestly, what is life without challenges?