[Et al.] Look After The BAs!

As a Developer in an Agile environment, I want to appreciate the Business Analysts (BA) so that we can continue working in a respectful and collaborative manner.

Sounds like a user story right? Well maybe it should be so that we can persistently practise this principle. Often we are faced with feuds between colleagues in the tech industry (most other industries have this too) due to a difference in opinion or even work ethics. Sometimes personalities clash, the pressure and tension might get a little too much, sometimes requirements are nearly impossible to meet in the unrealistic timelines presented to the stakeholders and sometimes those timelines were decided upon without consulting the technical team.

All of the above can be considered valid points and sometimes they raise valid concerns. Granted, it is a two way street – it is important to maintain bidirectional respect between developers and BAs.

I used to be a developer who was quick to judge non-technical colleagues based on the textbook description of their job title and the reality of how they carry it out. I have recently started working with a team of BAs who have fundamentally changed the way I see non-technical colleagues (especially BAs) who set out to do the best job that they possibly can do, in-line with their job description!

That’s good and all but what is a BA really? A Business Analyst is an agent of change. They work together with organisations to help them improve their processes and systems. As developers and technical “resources” we tend to make their life a lot more complicated than that.

Those involved in Robotic Process Automation (RPA) projects, would understand why I would say that the bulk of the work lies in the process understanding phase which is generally conducted by the BA (and in some instances the Solution Architect).

I have found that developers often look down on BAs as many of them don’t possess the skill to write code. Now based on what I have experienced working with a team of highly talented BAs, I have come to realise that the greatest difference between BAs and the developers is that they communicate the same process in different ways (or languages).

Although a developer is able to translate a business requirement specification, process definition document or even a functional specification document into code, it is important to remember that it remains an in-depth depiction of the process outlined by the BA.

Okay cool… But how can I do my part as a developer? Good question! Here are a few things you should keep in mind when working with BAs:

  • We enable those who enable us. A good BA may come across as someone who tries to make your life easier when in actual fact, they are trying to simplify a process. Help your BA help you by providing assistance with some technical aspects of a situation if and where possible.
  • Appreciating and respecting anyone will generally result in improved efforts made on a project. It is a common reaction to respond more positively when feeling respected and appreciated.
  • Be patient. Many BAs may have an ambition to gather more technical understanding around certain things that you have insight over, however, they may not always understand your predicament. The best advice I have gotten over the last months is to ELI5 (Explain like I’m 5). It has helped me tremendously in translating the highly technical explanations in a way that removes frustration for myself (as the developer) and the BA(s). In the process of ELI5, enlighten and enable the BA to understand the situation for future reference. If explained well enough, once is enough and twice is a revision.
  • Learn. There is always an opportunity to learn new things. There’s nothing stopping the devs from understanding a BAs process or a BA understanding the devs process.
  • Stick together. I cannot emphasise how important this point is. Dealing with the business (internally or externally) is strenuous enough, dealing with tension and pressure internally can often cause conflict between colleagues too. Sticking together against stakeholders and sharing the pressure as a team helps keep the team positive and often removes some of the additional pressure. Sometimes it helps just knowing that you’re not in something alone.

What happens when you have a personality clash with the BA? Get a new one? No, it doesn’t always work like that. Like I have mentioned above (and will mention further down too), this remains a two way street. Sometimes it is a good idea to discuss an ideal working situation with the BA that you may be clashing with. It is important that all parties respect and participate in the above. The responsibility does not solely lie with the developer, however, a first step goes a long way!

Great… But how do you spark a great working relationship? Get your colleague a coffee, or tea, or hot chocolate… Or water. Or a bunch of sweets.

To the BAs and other non-techies / semi-techies out there, thank you for the work that you do! You are appreciated and hopefully your dev team will show their appreciation too. Feel free to reach out to them too. It’s a two way street.

Let’s take this opportunity to be better together!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: