Agile Business Intelligence - Why, Why, How

Why do I need business intelligence

Most people believe that only programmers are needed to develop a program, because it is they who write the code and make the customer’s dream come true. But between what the customer says and what the programmer does in the end, there’s a whole chasm. Not because they are bad people or do not want to communicate and understand each other, but because the customer thinks on the scale of the goal, thinks what the program should do, for which he wants to use it. But the programmer must think about how the program should work, where to get the data from, how to name a new column in the data table, etc., in other words, think about the implementation details.



Since both programmers and customers are busy people, finding out the details takes place in the form of “question-answer” rounds, and it’s nowhere fixed when and why such a decision was made or how it changed over time. But the main minus 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 into a dead end, because he cannot and does not have to know how many options exist to fulfill his needs and which is optimal. The programmer just does what he was told. As a result, a situation arises when a perplexed client asks why the application does not fit into his picture of the world, and a perplexed programmer answers that they asked to do so.

Even the name of the analyst’s profession shows that his duties include not only collecting requirements, but also analyzing them, namely, choosing the optimal way to achieve the goal. That is, the analyst must know why the client needs this or that functionality, and how it was made by competitors, in order to analyze possible implementation paths, choose the optimal one and describe it to programmers in detail.

Analyst at Agile

Today flexible software development methodologies are gaining popularity in Russia and the CIS countries. When considering the possibility of switching to them (and even during the 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.

A familiar set of analytics functions - collecting requirements and writing a detailed specification of how the system should work. Before the start of the project, requirements must be collected, the specification is written, designs are drawn, and only then programmers begin to write code. This beautiful story of writing a program is rarely true even in projects using the waterfall methodology, not to mention Scrum.

Project documentation tends to go out of line very quickly — especially when combined with Agile, where change is the norm, not force majeure.

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

• Avoid write-only-documentation, that is, one that obviously no one will read.
• Write concisely, highlighting the main and omitting unnecessary details, because the details change more often.
• Use more visual images, schemes, graphic notations.

But this does not mean at all that everything must be minimized to zero. In the absence of documentation, the following problems are likely to occur:

• It is hard to introduce new people to the project course.
• 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 quality: it is not clear what to compare with (in particular, this concerns full-featured regression testing, which is very difficult to fully automate).
• It is difficult to maintain and develop the old functionality: everyone has already forgotten why and why they did just that.

Possible analytics features in Agile

Link between developers and customers

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

That is, the analyst is a person whom both users and developers trust:

• If there are problems in formulating or interpreting requirements, it is necessary for someone to organize a general meeting at which all the parties involved (both from development and from the business) should be present, while managing the discussion, helping to formulate a common solution and formulate this, 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 solving a problem requires clarifying 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 actively use internal jargon (business), and developers use their own (technical) one, someone is needed who can translate.

In most cases, this “someone” is an analyst who is 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 verify that they have done what is needed from the point of view of the business, and what is convenient to use?

Users and customers at the demonstration - of course, an option, but, firstly, not the fact that among them there will be people interested in this particular functionality; secondly, this way you can 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 incorrect business decision.

It is quite obvious that instead of (or together with) the product owner, this honorable duty can be assigned to the analyst

Analyst - Team Interaction Schemes

At 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 various options, and depending on the circumstances, these or those are effective.

The product owner is an 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, answers or helps to answer clarifying questions. All this is closely intertwined with the functions of the analyst discussed above.

Thus, you can decide: the functions of the analyst are performed by the owner of the product. Or, if you like, the other way around - the analyst acts as the owner of the product.

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

Disadvantages:

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

Analyst - assistant product owner

Most of the shortcomings of the previous scheme can be overcome if you share the responsibilities of the product owner and analyst between two people - a fairly common practice. As a rule, at the same time the “main” decides what to do, and additionally performs managerial functions. And the assistant focuses 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.
• It is very likely that the team will perceive the analyst as the owner of the product (or even the leader), that is, see him not as an assistant and an expert, but as a boss, which will almost certainly kill the criticality of the perception of the proposals and models proposed by the analyst - they will not be perceived as initial approximation and additional information, but as instructions for action.
• Again, it’s not so easy to bring such an analyst to an escort.

Analyst inside the team

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

• The analyst sits with everyone, that is, in the same room with the developers.
• The analyst participates in Scrum rallies with the rest (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 can be involved in uncharacteristic work to help the rest of the team in a difficult moment - for example, prepare test data, drive out part of the manual tests.

Sounds great. And it works great! However, there are circumstances in which the circuit is not suitable:

• One subject area (or very similar ones) is handled by several development teams, that is, it makes no sense to keep analytics in each team.
• The project has so many technical and technological subtleties and difficulties that the team is mainly concentrated on them, and the analyst in such a team is a foreign body.
• Lack of qualified analysts.

Conclusion

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

In heavy methodologies, the analyst is like an impenetrable wall between a development team and representatives of a customer / business. To make a good product, you have to spend a lot of effort 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 scattering into different angles and quietly doing something there without the knowledge of each other. In this case, the development team has a very significant role. Thanks to this, the risks associated with analyst errors are reduced: if anything, the team will clarify / correct (and if it does not, the customers will correct it for the demonstration).

Analyst at Agile is the middle ground between extremes:

One extreme	Golden mean	Other extreme
The team is not allowed to do analytical work.	Agile	Developers themselves have to fully clarify what is needed.
The analyst has little contact with the customer.	Agile	The analyst spends all the time with the customer.
Detailed specifications before starting the iteration.	Agile	The absence of any study of the requirements before setting them to iteration.
The aspirated command refers to the analyst’s attitudes.	Agile	The team does not trust the results of the analyst (does not use them).
The analyst is not involved in testing (QA).	Agile	The analyst is forced to constantly “pierce” many old interfaces.
The team perceives the analyst as a leader.	Agile	The analyst for the team is an errand boy / girl .
The analyst interacts with the team exclusively through documentation and a 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 closely with customers and users.

 

Posted by Olga Azimbaeva, Senior Business Analyst.