Want a Successful Agile Team? Include a BA!

My client’s project struggled for direction. The team spent 4 months trying to determine what to build. Then, most of the team quit. A new team formed with the imperative to “just get something in the hands of the end user.” The team achieved this in 2 months, but now they realize the value, purpose, and priorities of the project are unknown. In discussing next steps, the Development Lead Manager asks:

“Why would we need a business analyst? Can’t the developers just talk with the end user? Isn’t the problem the users don’t know what they want?”

Agile teams often overlook the role of business analysis or assume the Product Owner fulfills this role. Show me a team struggling with quality, product reworks, and delivering value, and I’ll show you a team with no business analyst.

Successful BAs Help With Communication

The biggest benefit provided by a business analyst (BA) is communication. Expressed as an Agile value, business analysts help with customer collaboration over contract negotiation.

Business owners and developers speak different languages. In many cases the developer has a natural tendency to think they know how to build a solution without the need for clarification. The business owner struggles to express needs in terms of priority and treats every idea or suggestion as equally important. The result of this is an incomplete solution and an unhappy customer.

Having someone there to get everyone on the same page and agree is critical. The business analyst is an honest broker for building the right solution, defining the acceptance criteria, and seeking clarification when needed. The business analyst is constantly facilitating discussion, documenting requirements, and testing and validating the solution.

The goal of Agile software development is working software over comprehensive documentation. A common conclusion is that developers matter and non-developers are unnecessary.

When a software product team is successful, the developers and designers (those making the tangible product) get all the credit. When the product team does not succeed, the blame is on ill-defined requirements, poor testing, or lack of management.

As a result, management tends to overlook the BA role when forming a team. Since the work of the business analyst on the Agile team is non-tangible, it is easily forgotten. This is like building the next best search engine but omitting the server capacity necessary to handle the traffic load – a disaster waiting to be discovered.

BAs and the High Performing Team

So what does a high performing team with business analysts look like? It is a team which responds to change quickly and easily over following a plan. What leads a team to success is really about preparation: determining the value, purpose, and priority before investing time and money.

The business analyst brings preparation and planning to get stakeholders’ perspective. These advance conversations discover those insights in advance, so the approach is from a value-first, holistic solution rather than functional perspective.

The high performing team also gets feedback early and often. The business analyst will solicit and facilitate this feedback throughout the process, even more often than just at sprint reviews. Getting the feedback sooner means the team doesn’t make mid-stream course corrections or deliver an unsatisfactory solution.

In the end, it is about individuals and interactions over processes and tools. There is no single correct answer for implementing Agile principles and values on a team. In the same fashion, there is no single correct answer for how a business analyst works with an Agile team. If there is a project with many repeatable steps and few unknowns, a BA is not necessary. But when the team relies on stakeholder input, the product is new or a significant change, or your Product Owner struggles to break down features to stories, the team needs a business analyst or team of BAs to succeed.

Don’t forget to leave your comments below.