Business intelligence in Agile - why, why, how

Why do we need business analysts

Most people believe that only programmers are needed to develop a program, because they are the ones who write the code and make the customer’s dream come true. But between what the customer says and what the programmer eventually does is a whole gulf. Not because they are bad people or do not want to communicate and understand each other, but because the customer thinks at the scale of the goal, thinks what the program should do, why he wants to use it. And the programmer is obliged to think about how the program should work, where to get the data, how to name the new column in the data table, etc., to put it simply, think about the implementation details.







Since both programmers and customers are busy people, the clarification of details takes place in the form of question-answer rounds, without fixing anywhere, when and why such a decision was made or how it changed over time. But the main disadvantage of such communication is that the developer asks “how?”, And the customer can only answer “why?”, And the rest is of little interest to him. Moreover, usually, responding to “how?”, The customer leads himself to a dead end, because he cannot and is not obliged to know how many options exist to fulfill his need and what is optimal. The programmer is only doing what he was told. As a result, a situation arises when a puzzled client asks why the application does not fit into his picture of the world, and the puzzled programmer answers that they asked to do so.



Even from the name of the analyst profession, it is clear that his duties include not only collecting requirements, but also analyzing them, namely choosing the optimal way to accomplish the goal. That is, the analyst should know, and why the client has this or that functionality, and how it is made by competitors in order to analyze possible ways of implementation, choose the best one and describe to programmers in detail.

')

Analyst in Agile

Today, flexible software development methodologies are gaining popularity in Russia and the CIS countries. When considering the possibility of transition to them (and even in the process of transition or initial use), a number of questions almost inevitably arise. One of them is the need for a business analyst to participate in the development process.



The usual set of analytic functions - gathering requirements and writing detailed specifications of how the system should work. Even before the launch of the project requirements must be collected, the specification is written, the designs are drawn, and only then programmers begin to write code. This beautiful story of writing a program rarely corresponds to reality even in projects according to the methodology of waterfall, not to mention Scrum.



Project documentation has a tendency to quickly become obsolete — especially in combination with Agile, where change is the norm, and not force majeure.



In this regard, in Agile-methodologies it is strongly advised to minimize documentation:

• Avoid write-only documentation, i.e., one that no one will read.
• To write concisely, highlighting the main thing and omitting unnecessary details, for the details change more often.
• Use more visual images, schemes, graphic notations.

But this does not mean that everything must be minimized to zero. In the absence of documentation, most likely, the following problems will arise:

• It's hard to introduce new people to the project.
• There is a high probability of losing the general concept and vision (of the project as a whole and its parts).
• It is difficult to control the quality: it is not clear what to compare with (in particular, this concerns full-featured regression testing, which is very hard to fully automate).
• It is difficult to accompany and develop the old functionality: everyone has already forgotten why and why they did it that way.

Possible analyst functions in Agile

Link between developers and customers

In contrast to the classical interpretation of analytics functions, in Agile it is the provision of effective communication between customers (users) and the development team that plays, in fact, a key role.



That is, the analyst is a person who is trusted by both users and developers:

• If problems arise in formulating or interpreting requirements, it is necessary for someone to organize a general meeting at which all the parties involved (from both development and business) would turn out, while managing the discussion, helping to form a common solution and formulating it so that it is clear to all concerned.
• If users passionately want one thing, and developers stubbornly insist on another, someone should help find a compromise or convince developers to do as customers and users ask.
• If the solution of the problem requires clarification of a number of essential details, and customer representatives refer to each other or contradict each other, someone is needed who can effectively get out of this situation.
• If customers are actively using internal jargon (business), and developers - their own (technical), someone is needed who can translate.

In most cases, this “someone” is an analyst, assisted by managers, when administrative resources are required, and key project experts or even companies, when generation or verification of non-standard solutions is required.

Quality control

Traditionally it is believed that quality is controlled by special people who perform acceptance tests according to the described methods and programs. However, who will check that they have done what they need from a business point of view, and what is convenient to use?



Users and customers for the demonstrations are, of course, an option, but, firstly, it’s not a fact that people interested in this functionality will be among them; secondly, it’s possible to lose face (the demonstration will turn into a testing and debugging session); thirdly, a certain amount of resources and time will already be spent on debugging a possibly wrong business solution.



It is quite obvious that instead of (or together with) the owner of the product, this honorable duty may be placed on the analyst.

Analyst interaction patterns - team

In Agile much attention is paid to teamwork, self-organization. How to organize the interaction of the analyst with the team, taking into account the functions assigned to it? There are different options, and depending on the circumstances, these or those turn out to be effective.



Product Owner - Analyst



This is the simplest and most obvious case. The product owner is responsible for the product, for the collection and prioritization of requirements, is a kind of representative of the customer, but on the side of the contractor, he is responsible or helps to answer clarifying questions. All of this is closely intertwined with the analyst functions discussed above.



T. h. You can decide: the functions of the analyst performs the owner of the product Or, if you prefer, on the contrary - the analyst plays the role of the owner of the product.



Among the advantages of such a scheme: simplicity, minimalism, relative convenience for the customer, and for developers - and those and others always know who exactly needs to be addressed with their questions.



Disadvantages:

• Too much depends on one person - a large load and the associated bottleneck risks.
• Extreme indispensability - and if on vacation, and if ill.
• It is unlikely that it will be possible to attract such a product owner closely to support the system or actively participate in pilot implementations.
• There is a possibility that the owner of the product will postpone solving some problems, not because they have a low priority, but because he has not yet had time to properly work out the formulation. That is, the whole idea of ​​prioritizing work based on the needs of the business, and not on the basis of internal or technical circumstances, is being killed.

Analyst - Assistant to the owner of the product



Most of the drawbacks of the previous scheme can be overcome by dividing the responsibilities of the product owner and analyst between two people — a fairly common practice. As a rule, the “main” decides what to do in which queue, and additionally performs managerial functions. And the assistant concentrates more on the content and details of the work, that is, plays the role of an analyst.



However, this scheme also has disadvantages:

• The activity of the analyst is not transparent enough for the team, since the analyst is not included in it.
• Chances are that the team will perceive the analyst as the owner of the product (or even the manager), that is, to see him not as an assistant and expert, but as a manager, which will almost certainly kill the critical perception of the proposals and models offered by the analyst — they will not be perceived as initial approximation and additional information, as well as instructions for action.
• Again, it is not so easy to bring such an analyst to the accompaniment.

Analyst inside the team



You can go even further and put the analyst inside the team. What does it mean:

• The analyst is sitting with everyone, that is, in the same room with the developers.
• The analyst participates in Scrum rallies with the others (tells what he did yesterday and what he is going to do today).
• The work of the analyst is taken into account when planning the iteration.
• The analyst may be involved in uncharacteristic works to help the rest of the team in a difficult moment - for example, to prepare test data, to get rid of part of the manual tests.

Sounds great. And it works great! However, there are circumstances in which the scheme does not fit:

• One subject area (or very similar) is occupied by several development teams, so there is no point in keeping an analyst in each team.
• There are so many technical and technological subtleties and difficulties in the project that the team is mainly concentrated on them, and the analyst in such a team turns out to be a foreign body.
• Shortage of qualified analysts.

Conclusion

So is there a difference between an analyst in Agile and a non-Agile (for example, in a waterfall or other heavyweight methodology)? The unequivocal answer is!



In heavyweight methodologies, the analyst looks like a low-permeable wall between the development team and the customer / business representatives. To make a good product, you have to spend a lot of energy on “picking holes” in this wall. In addition, the risks associated with analyst errors are terribly high. The development team is given a supporting role.



In Agile, the analyst plays the role of a link between developers and customers - a kind of magnet that prevents them from running to different corners and quietly do something there without their knowledge. In this case, the development team has a very significant role. This reduces the risks associated with analyst errors: if anything, the team will clarify / correct (and if not correct, the customers will correct for the demonstration).



Analyst in Agile - the golden mean between extremes:

One extreme	Golden mean	Other extreme
The team is not allowed to analytical work.	Agile	Developers themselves have to fully clarify what is needed.
The analyst communicates little with the customer.	Agile	The analyst spends all the time at the customer.
Detailed specifications before the start of the iteration.	Agile	The absence of any study of the requirements before putting them in the iteration.
The aspirated command refers to the analyst's settings.	Agile	The team does not trust the results of the analyst’s work (does not use them).
The analyst is not involved in testing (QA).	Agile	The analyst has to constantly “pierce” many old interfaces.
The team perceives the analyst as a leader.	Agile	Analyst for the team - a boy / girl "running errands."
The analyst interacts with the team exclusively with the help of documentation and bug tracker.	Agile	The analyst interacts with the team exclusively through verbal communications.
Only the analyst communicates with the customer and users .	Agile	All team members are forced to communicate tightly with customers and users.

Author: Olga Azimbaeva, Senior Business Analyst.