Analyst in Agile Team

The role of the analyst and the importance of analysis in many organizations is strengthening and in others it is disappearing. Quite often, where there is an agile approach, the role of an analyst is difficult to define. In the agile programming manifesto you can read:

Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan.

Manifesto for Agile Software Development

I deliberately emphasized from detailed documentation. In the extreme case, it means no documentation. Or rather, there are lanes in JIRA, but not all tasks in JIRA are documentation. They are probably not than they are J

An analyst appears in this new puzzle. The analyst is associated with BPMN processes, use cases, a table with requirements and the approach that is planned to be coded once. I do not mention the multi-page documentation in Word J.

Returning to the manifesto. In many places the manifesto of agile software development says the analyst is not needed. The development team is to understand the essence of the problem. It should be as close to the problem as it is trying to solve. It seems that the development team should find out what the problem is and solve it by providing a working solution. That’s what the theory says, quite simply. In practice, it seems that an analyst is needed, regardless of whether we work agile or classic, or hopefully not cascade. The complexity of business processes, the interdependencies between ventures, and the multiplicity of products being developed, mean that mature analysis can be very much needed.

Variant 1 – no analyst

This is an approach in which there is no analyst. The team is working agile. There is no analyst, no sensible documentation. Sometimes there are pictures from arrays in team or wiki cells, or Confluence. Work is done without a wider view of the product. Iterations provide certain functions.

Here you can fall into a trap, in which the team seems to know better how the application should work and what the business expects. In this approach sometimes there may be a shortage of time to understand the essence of the product and enterprise.

Option 2 – analyst outside the team

The classic approach is that the analyst is and works iteratively. What the specified time provides the products of the analysis. This model is close to the classic cascade, because the sprints or iterations of the development team are not directly and closely related to the analyst’s work.

The analyst manufactures the analysis products well in advance. Analysis products may become obsolete from the time they are created to the time of implementation. Here the approach is somewhat agile, as it concerns only programmers. This approach can be seen in organizations where agility is only available for developers. There are classic projects with budgets, time frames and PM. It is such a hybrid that if the analyst is very actively involved in sprinting and is available to the team, it will “work” as well. If only it provides artifacts, we have a sensible approach.

Option 3 – analyst in agile team

As part of the team, the analyst performs analytical work in accordance with the team’s iterations. It is part of it. In my opinion, this is the best solution.

Why do I think so?

First of all, and in the assumptions of the Agile Manifesto:

Business people and developers must work together daily throughout the project. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. The best architectures, requirements, and designs emerge from self-organizing teams.

(Emphasis is mine)

The least happy model, in my opinion, is one in which the analyst takes responsibility for the requirements  and the developers for coding.

In this approach and such a system of responsibilities, the developers are cutting off from a very important aspect, which is the attempt to understand the product, processes or the problem being solved. In this arrangement, we have a situation almost similar to option 2. the analysis is created separately and the code separately.

The analyst is to work with the team. The idea of ​​agility is to create the right amount of documentation (as few as possible) and time should be devoted to communication, read the conversation, and analyze. It is about everyone knowing what problem we have to solve. Too many diagrams can be over interpreted by developers. What’s more, too little, for example only user stories or use cases without specifying the context, purpose of the business, well-defined business needs, specific business processes may cause that the solution created will carry out the story and not solve the business problem.

It seems that it is better to talk and build documentation not as during this conversation.

Here is important note. You can, of course, scratch many tables, take pictures, but in my opinion it’s good for once. If you then want to use the documentation of the results of our findings, you must apply at least a minimum of formalities. Use languages ​​and notations known more widely. This will help you implement yourself to others.

Simple BPMN, requirements, user stories, state machine diagrams, domain model. Several elements adequate to the scope of the problem being solved. They do not have to be sophisticated artifacts. They are to be as simple as possible. Simple enough to allow us to understand the problem and so complex that by the next iteration they can be used for development, to prepare the next version of the product.

It also seems that the analyst is right in larger companies or teams. In smaller, with the development of one or two products, direct contact between developers and business may be a better solution. The lack of analysts does not mean that the team may lack analytical competence. Analytical competence, regardless of whether the analyst is or not – must be.

The analyst has a lot of work to do especially where we have many relationships between business processes.

If there are many teams, it may be worth it in the organization to be a business architect to create a map of processes so that teams, and analysts in particular, can find the relationships between processes, requirements and iterations more easily. Moreover, the analyst must be in constant contact with the developers so that his analysis is implementable. The analyst should be the glue between business expectations and the capabilities of the system and the team. In addition, in my opinion, the analyst brings to the team simply his experience of his story in previous projects.

The analyst must participate in the sprint and not say “wait for the documentation”.

A mature analyst is a person who asks questions and tries to determine with the team the answers. The analyst asks questions that are meant to capture the essence of the problem. An analyst cannot be just a scribe and should develop his own workshop to moderate the discussion. He can use his facilitation skills to support the team in working on a complex problem. Drawing diagrams is needed to a certain extent, but rather as an effect / document of the design decisions made. The analyst should use more agile techniques, such as story mapping, outside the classic BPMN. In addition, the analyst’s role is to look a bit wider and farther. Here, the impact analysis, contact with other analysts or the support of a business architect are of great importance.

To sum up, the analyst in an agile team is a sapper: what is supposed to disarm mines, which builds bridges over the encountered rivers. An analyst as a member of the team is to help create better, more perfect software.

Is it easy to build such an analyst position that adds value? No, it is not easy. It is rather difficult. In my opinion, it is worth to take this effort, because quoting the above mentioned principles of the agile programming manifesto ” Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. “

I wish you such a software 🙂

More from my site

  • Kanban Workflow In the preceding Kanban post, I wrote about partially done work. I wrote that it is worth limiting partily done work. The WIP (Work In Progress) which is too high results in the fact that […]
  • Implementation of the Methodology – Selection of a Modeling Tool In many companies there is a discussion about formalizing the software development process. Spontaneous creation of diagrams by broadly understood analysts and designers does not build […]
  • Impact Mapping In my practice I have met many times the situation in which the change was implemented in accordance with the maxim of King Julien " Quick, to the volcano, before we all come to our […]
  • User Stories vs. Use Cases We are currently in a “strange situation”. There are user stores and usage case scenarios, of which the latter can be divided into formal and informal use cases as well as summaries of […]
  • My Favorite Perspectives in Enterprise Architecture Modeling On Open Group pages a number of ArchiMate perspectives are presented. Using them all in a given organization is an obvious misunderstanding. I wrote very often about the fact that in each […]

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top