Is there analysis in the agile world?

“There are no analysts in our projects!” and “I don’t want to see another analyst in my projects!” are increasingly common phrases in IT projects. Yet, before the triumph of agile development, analysts played a critical role in preparing for IT development. So, how is it done now?

The topic is elaborated by Kaja Trees, a systems and business analyst with over 20 years of experience, who also shares her knowledge through training sessions. She has provided consultancy services in various companies.

The Analyst’s Place in IT Teams

According to Kaja, the structure of IT teams and the analyst’s place in them can be roughly divided into four groups:

1. Teams without analysts

Here, every developer does the analysis for their development task. This can lead to unevenly thought-out solutions, or a ‘hunchback’ system. Such systems may contain duplications, technological debt, and scaling issues. Users are often dissatisfied with the UX, and IT architects with the technical structure.

The challenge is maintaining the big picture, often done by a collective ‘hivemind’ rather than a central role. There are software developers who can collectively maintain the big picture and engage in necessary discussions with the client, though many prefer focusing on the technical side. Agile methodologies offer many practices to mitigate this risk. However, Kaja’s experience shows the need to be aware of the analysis role to avoid problems.

2. Teams with an analyst under a different title

The Product Owner, IT Architect, or even Scrum Master might fulfill this role if they have the relevant skills. This is like doing “secret” analysis to bypass strict restrictions.

The risk here is that their other activities may not receive enough attention, though they are also important. If there is a good balance between developers and other roles, such a team can function very well.

3. Teams Where the Client Conducts the Analysis

This means the client has a strong business analyst who maintains scope and logical coherence of the solution, preparing development tasks (like user stories) and ensuring that the solution is optimal from the client and user perspectives. Ideally, they have an IT background to utilize IT capabilities without overcomplicating things. The development team receives a task that is understandable to developers, allowing them to focus on the technical side.

The biggest risk is when the analyst does not fully understand how IT systems work. Here, an open dialogue with IT architects or developers, who think along and suggest alternatives to proposed solutions, is helpful.

On the other hand, such a team must have either an IT architect or excellent developer collaboration to ensure that all parts of the solution work as a unified whole from a technical perspective. Without a grand vision, for example, development might start on a platform with insufficient scalability for the final solution.

4. Teams with an analyst as part of the development team

The analyst’s task is to prepare tickets just as a developer’s task is to develop them and a tester’s is to test them.

If the client lacks a strong, technologically savvy business analyst, then the project team must fulfill this role. Kaja has been in this position in many projects and found it can work very well. However, purists of agile development see this as sacrilege, believing that the development ticket should be solely in one person’s hands from start to finish.

Analysis is of critical importance

It’s vital to understand that analysis is a critically important part of any project, no matter who does it. To avoid disputes, Kaja often approaches the responsibility of analysis by looking beyond job titles and defined roles – finding the person who takes on this responsibility. An analyst, in her view, is someone who does the analysis, regardless of their job title or where they “sit” in the team structure. The notion that only people with the official title of “analyst” can do this work is limiting and creates conflicts.

Similarly, Kaja’s taught “Business and Systems Analysis Course” is intended for all roles involved in business or systems analysis – including developers, product owners, Scrum Masters, testers, and project managers. It teaches analysis skills through thoughtful theory and feedback-based practice and is an investment in personal and company development.

The article was first published in DigiPRO (in Estonian).