Unlike the classical interpretation of the functions of the analyst, effective communication between customers (users) and the development team plays a key role in Agile.
That means that the analyst is the man trusted by both customers and developers.
If there are problems in the formulation or interpretation of requirements, it is necessary that someone organize a general meeting with all the parties involved (both the development team and the business team), to direct the discussions , to help build a common solution and formulate it in such a way that it was clear to all interested parties
If the customer is passionate about something and the developer stubbornly insists on something else, someone has to help find a compromise or convince the developers to do as the client asks
If a number of important details need clarification and representatives of the customer refer to each other or contradict each other, it needs someone who can effectively solve this situation
If customers are actively using their internal (business) jargon and developers use their technical language, it needs someone who can act as a translator
In most cases, the person you need is the analyst, assisted by managers when required, administrative resources, and the key players of the project, or even other companies when the generation or verification of non-standard solutions is required.
Traditionally it is considered that special people deal with quality control: they perform acceptance tests on the described techniques and programs. But who will make sure that the right thing has been done in terms of business needs and that the program is convenient to use?
Demonstrations to users and customers is certainly an option, but no one guarantees that any of them will be interested in the particular part of the functionality that needs to be tested, and secondly, you can easily lose face (the demonstration may turn into a testing and debugging session) and in conclusion, a certain amount of resources and time will be spent on debugging possible incorrect business decisions.
It is quite evident that this honorable duty may be imposed on the analyst instead of (or together with) Product Owner.
Analyst – Team interaction pattern
In Agile, a lot of attention is paid to teamwork and self-organization. There are various options available to the organizing analyst – team communication, taking into account everything that is expected of it, and depending on the circumstances, different options may be considered the most effective.
Product Owner – Analyst
This is the simplest and the most obvious case. The Product Owner is responsible for the product, for the collection and prioritization of requirements and is a representative of the customer, but on the side of the executor answers or helps to answer specific questions.
All of this is closely connected with the functions of the analyst, discussed above, so you may decide that the analyst performs the function of the Product Owner. Or, if you will, on the contrary, the Product Owner acts as the Analyst.
Among the advantages of such a scheme: simplicity, minimalism, and the relative convenience for the customer and the developers - they both always know exactly who to turn to with their questions.
Too much dependence on a single person - a heavy load and the associated risks of having a "bottleneck"
Extreme indispensability – and what if he falls sick or has a holiday?
Unlikely to get such a Product Owner to system support or active participation in pilot deployments, just because functions of analyst are among many others he deals with.
There is the possibility that the Product Owner will postpone the solution to some problems, not because they have a low priority, but because he had not had time to work them out yet. And this ends the idea of prioritizing work based on business needs, not on the basis of internal or technical circumstances.
Analyst – Product Owner assistant
Most of the shortcomings of the previous scheme can be overcome, if we divide Product Owner and analytics responsibilities between two people, and this is common practice. As a general rule, the "boss" decides on the priorities of tasks, and also performs managerial functions. An assistant concentrates more on the content and details of the work, in other words, plays the role of the analyst.
However, this system also has its dark sides:
The activities of the analyst are not sufficiently transparent for the team, as the analyst does not fully belong to the team
Chances are that the team will take the analyst as Product Owner, to see him not as an assistant and helper, but the boss. This will almost certainly kill the critical perception of proposals and models offered by the analyst as they will be seen not as additional information, but as instructions for the action
Again, it is not easy to draw this kind of analyst to support the program
Analyst within the team
We can go even further and put the analyst within the team. What does this mean?
The analyst sits with the developers, in the same room
The analyst is involved in Scrum-meetings along with the others (telling what he was doing yesterday and that's going to do today)
The analyst work is taken into account when planning iterations
The analyst may be involved in non-standard work to help the rest of the team in difficult moments - for example, to prepare test data or handle parts of the manual tests
Sounds great. And it works great! However, there are circumstances when this scheme is not appropriate:
Several development teams deal with one subject area, so it isn’t possible to have the analyst in each team
There are so many technical and technological subtleties and complexities that the team is mostly focused on them, and the analyst seems more like a foreign body
A shortage of skilled analysts
So, is there a difference between Agile and non-Agile analysts? The univocal answer – there is!
In heavy methodologies, an analyst is similar to the impermeable wall between the development team and the customer / business representatives. To make a good product, we have to spend a lot of energy to "pick holes" in the wall. In addition, the risks associated with analyst errors are terribly high. The minor role is given to the development team in this case.
In Agile, the analyst plays the role of a bridge between developers and customers - a kind of magnet that does not give them the opportunity to hide in different corners and quietly do something without telling each other. And in this case, the development team is given a very significant role. This reduces the risks associated with analytic errors - if anything occurs, the team will update / correct it (and if not, the customers will do that during demonstrations).