The developers believe they understand what the clients or business users are looking for, while the users have their own expectations of how the project will ultimately turn out.
“This is not really a winning recipe for successful delivery” states Patricia Draper, an executive at BBD, a leading software development company.
The scenario above isn’t impossible to imagine, and it happens more often than you think. Why? Because BAs play the role of translator in the software development life cycle (SDLC), enabling the effective conversion of the business user’s needs into technical specifications that the developers use to build the most appropriate solution. Draper explains that without this ‘meat in the sandwich’, the business logic isn’t clearly defined. The more precise the requirements are, the less likely reworking is needed on the development side. Ultimately, knowing the business as well as the client means a smoother process for the whole team.
The other important function BAs fulfil is project management or stepping into the role of scrum master. As logical, detail-orientated problem solvers, BAs not only outline the initial specifications, but co-ordinate all the moving parts and teams throughout the SDLC, thereby removing most impediments. This process involves numerous tools such as JIRA and Confluence, Microsoft Visio and Excel, Zoom, Enterprise Architect and Trello, to name but a few.
Because BBD has adopted an Agile mindset, the focus for each project team is on working software and client interactions rather than exhaustive documentation. This way of thinking informs how our BAs are adaptive to working in a manner that is most beneficial to our clients. “BBD isn’t prescriptive. Having our BAs as a flexible fulcrum for the management of the task, people and project as a whole, helps ensure that the business logic and user requirements stay top of mind.”
Lastly, and maybe most importantly, is the working relationship between developers, BAs and the client. Like any good relationship, it’s one built on trust. While the BA has to be technically aware, they are not expected nor presumed to be, a technology expert – that’s the developer’s realm. Draper adds that BBD BAs are so good at their job because they ‘speak developer’.
Despite this, a clear understanding of the solution will aid the BA in knowing what is possible; avoiding fanciful requirements and impossible expectations. Similarly, a developer need not be a whizz in the business domain and should rely on the BA to provide the necessary understanding or knowledge of the problem being solved. BAs also shouldn’t be afraid to run thoughts and ideas past the development team.
Remember, solutions are built as a team. Draper explains it as all coming down to the working relationship between the analyst and the developer; the better it is, the more timeous the delivery and better quality the solutions are.
The software development world without BAs would be rife with unmet expectations, unhappy clients and frustrated developers. Draper concludes that any software development house would want to avoid this outcome, and for BBD, BAs are simply non-negotiable in their teams.