The Modern Business Analyst: How has his role evolved from requirements gatherer to value architect in an agile world?

In the traditional cascading world of software development, the Business Analyst (BA) was a central figure, like the chief architect of a building. His job was to conduct a series of meetings with stakeholders, gain an in-depth understanding of their needs, and then translate them into an extensive, extremely detailed and formal document – the System Requirements Specification (SRS). This document of several hundred pages, created over many months, became the “bible” of the project, an unassailable blueprint that was then passed “over the wall” to the development team. The analyst’s success was measured by the completeness and precision of this document. It was a key bridge over the chasm dividing the business and technology worlds.

However, the agile revolution (Agile) did not build better bridges. She bridged the gap. In a world where software development takes place in short, two-week iterations, and where close, day-to-day collaboration between business and technology is the foundation of success, the analyst’s role of creating large documents “in stock” has lost its raison d’être. Many organizations, moving to Agile, have fallen into the trap of thinking that the role of the business analyst has become redundant, that it can be fully replaced by the Product Owner. This is a fundamental and extremely costly mistake.

The role of the business analyst has not disappeared. She has evolved in a spectacular way. The modern, agile business analyst has ceased to be a passive requirements gatherer and documenter. He has become a proactive facilitator, system analyst, strategist and value architect. He or she is a key partner to the Product Owner and the entire development team, helping them not only to understand the “what” to build, but more importantly to deeply understand the “why” and to decompose complex problems into small, actionable and value-adding chunks. This article is an in-depth analysis of this evolution.

Why did traditional business analysis, based on great specifications, have to die?

The old model, based on creating big upfront requirements specifications (so-called “big upfront design”), is not only ineffective, but downright toxic in an agile environment. Its harmfulness stems from several fundamental reasons that every modern organization needs to understand.

• The illusion of predictability. Creating detailed specifications months before the real development work begins is based on the false assumption that we can predict the future and precisely define all user needs. The reality is that the market, competition and customer expectations change at a rapid pace. A document that was current in January is often already scrap paper in June. Agility accepts and manages this uncertainty through short feedback cycles, rather than trying to eliminate it through planning.
• A barrier to communication. Large specification documents, counterintuitively, kill real communication. Instead of promoting direct, day-to-day conversation between developers and the business, they create a formal, bureaucratic barrier. The development team, when given such a document, is often afraid to ask questions and question provisions, assuming that “everything is in the document.” This leads to misinterpretations and building a product that conforms to the specification, but not to the real needs of the user.
• Waste Generation (Waste). Months spent writing and agreeing on details that will later change anyway is time and money thrown down the drain. What’s more, detailed requirements imposed from above kill the creativity and innovation of the development team, which, instead of seeking the best possible solution to a problem, is reduced to the role of a passive “coder” carrying out someone else’s orders. This is a straightforward path to declining engagement and high turnover of top talent.
• Delaying the delivery of value. In the old model, long months of analysis and documentation pass before the first working line of code is created. In the agile world, the goal is to deliver a small but working and valuable piece of product (MVP) as soon as possible to gather feedback and learn from it. Traditional analysis is in complete contradiction to this fundamental principle, pushing back the moment of market verification by quarters.

What are the key responsibilities and competencies of a modern agile business analyst?

In an agile ecosystem, the role of the Business Analyst (often combined with that of the Systems Analyst) is transformed. Instead of being a single “bridge,” he becomes an all-around “facilitator” and “gas pedal” of the work of the entire product team, working closely with the Product Owner and developers. His new responsibilities and competencies can be divided into several key areas.

Product Owner’s Strategic Partner

The modern analyst is the right hand and strategic partner to the Product Owner. While the Product Owner focuses on product vision, prioritization and stakeholder communication, the analyst goes down to a much deeper level of analysis. His job is to gain an in-depth understanding of the business problem the product is meant to solve. He conducts workshops, interviews with users, analyzes data and processes to make sure the team is building the right thing (“building the right thing”). He helps the Product Owner decompose big, epic ideas into smaller, manageable and value-adding user stories (user stories). He is a master at asking the “why?” question, helping to distinguish real needs from superficial stakeholder “wants.”

Process architect and system analyst

The second extremely important area is systems analysis and modeling. An analyst is someone who can look at a problem holistically, understanding how a new function will affect existing systems, processes and data flows. He or she uses modern modeling techniques such as BPMN diagrams, Value Stream Mapping and data flow diagrams to visualize complexity and identify potential problems, dependencies and risks. His work is crucial in integration and modernization projects, where understanding “how things are” is a prerequisite for designing “how things should be.”

Master of facilitation and clarification of requirements

The analyst is a master of communication. His job is to ensure that the entire product team – Product Owner, developers, testers – has a shared, unambiguous understanding of what is to be built. He organizes and leads workshops, such as Story Mapping and Event Storming, that allow for a collaborative, visual exploration of a problem. He is an expert in writing clear, concise and testable user stories and defining precise acceptance criteria. He makes sure that requirements are ready to work (ready for development) before they hit the sprint, eliminating misunderstandings and team downtime.

Why is it so difficult to recruit an elite agile analyst, and why is he or she a multiplier of the entire team’s effectiveness?

The role of the modern agile analyst is extremely demanding and requires a unique hybrid mix of competencies. He or she must combine “soft” skills – such as empathy, communication, facilitation and negotiation – with “hard” skills – such as analytical thinking, systems modeling, technology understanding and data analysis. He or she must be able to talk freely with both the CEO about strategy and the developer about API structure.

Finding people with such a broad and deep competency profile in the market is extremely difficult. Many companies, when trying to fill this role, make the mistake of hiring either people with a pure business background who don’t understand technology, or former programmers who lack communication skills.

However, investing in finding or acquiring a true, world-class analyst is one of the most profitable investments in productivity. A single, excellent analyst can be a force multiplier (efficiency multiplier) for an entire development team of up to ten people. By providing the team with clear, well-crafted and unambiguous requirements, he eliminates dozens of hours wasted on incorrect implementations, misunderstandings and downtime. It frees up the Product Owner’s time, allowing him to focus on strategy, and the developers’ time, allowing them to focus on what they do best – writing quality code.

That’s why at ARDURA Consulting we take the role of Business and Systems Analyst with the utmost seriousness. We understand how critical and at the same time how difficult to find this competency is. For years, we have specialized in identifying, vetting and providing our clients with the best experts in the field in a flexible Staff Augmentation model. Our selection process tests not only theoretical knowledge, but more importantly practical skills in facilitation, modeling and solving complex problems.

When you engage an analyst from ARDURA, you don’t just get an additional employee. You get an experienced professional who becomes a gas pedal of your team’s work from day one. He or she brings with him or her battle-tested techniques, helps implement best analytical practices and acts as a mentor for less experienced team members. This is the fastest and most effective way to raise the analytical maturity of your organization.