The article is devoted to the difficult / labor circumstances of the work of analysts on projects that are carried out according to a certain variant of “Scrum + Analyst”, these circumstances are the cause of stress. If you think that I will give you some solutions, then alas, no. These difficulties will not go away in the foreseeable future, you can consider that you are walking in the circle of Samsara of the analyst. Know that you are not walking alone on it, maybe it will become psychologically easier for you.
Current Sprint VS Future Sprint
Everyone is working in sprints. How many active sprints does an analyst have? Of course, two. In one, he provides analytical support to developers, explains the tasks of the current sprint, eliminates the comments that were thrown at him at the start of the sprint. At the same time, the analyst must form a description of the tasks for the future sprint. From the other members of the team, this seems to be the way it should be. Developers like to think that they are creators and work in a flow from which they cannot be distracted. And for the analyst, as if this is not applicable, it turns out that the analyst is studying the materials, thinking about a solution, here, bam, a question about the task of the current sprint. Then another question on another task, and there will be questions, and this is normal. Suppose an analyst described a bunch of tasks in advance, ran away with the analysis ahead of the development team, wait a minute, does this remind me of something? So this is a waterfall, and what will happen to the tasks when the development team starts them, right, there will still be a lot of questions, and the analyst will have to redo everything. Let’s also imagine that the tasks at the beginning of the sprint are perfectly described and fully understood by the developers. Know what that means? Nothing good. Probably, the project is developing slowly, no one is in a hurry, there is no dynamics, perhaps no one needs your project / product. Thus, the norm is two active sprints for the analyst.
We work in sprints, but we also have a plan!
To understand this contradiction, remember how your projects developed and build a logical chain. Again same all now work on sprints. But initial planning and labor estimation is not done by sprints. In the best case, you have an architect, he or you did a preliminary design, decomposed the system into components and modules, estimated the labor costs for implementation, or even, together with the project manager, built a roadmap, or maybe even a plan with a Gantt chart. At the same time, they still understand that you will work in sprints. And how does this compare with classical planning? It turns out that in the minds of people this gap gets along normally, or rather it is ignored. But this rake can work well if a milestone from the Gantt chart is landed in some future N-th sprint without proper reassessment. Part of this problem is that working on sprints and applying Scrum practices, that is, planning at the beginning of the sprint, daily, demo day, retrospective, many people perceive that we are working on Scrum. But Scrum is categorically against any milestones and long-term plans. And why is it so easy to fit the plan and work in sprints in your head? I want to note that I am not against plans with a distant horizon. Planning is a good mental activity that gives you an understanding of what needs to be done. But I am against fixing the plan in its original form, without adjustments, because that’s not how it works. But will it work if it is broken into sprints? Is sprint work an adjustment to the plan? And if the delivery time is rigidly fixed, then this can be called a clarification? Well, yes, there are still two parameters that we can clarify. Does everyone understand in which direction the change will take place?
And why did your analysis tasks in the sprint change?!
This problem is familiar to everyone, this is the case when there is some work schedule, according to which all the work of the team should be carried out in sprints in Jira. Analysts, developers, testers are all driven into a typical sprint. And at first it even looks like a meme “Everything is mixed up in the Oblonsky house.” Why it is impossible to work with analytical tasks in the same way as with development tasks, and what tricks are made to prevent it from happening or vice versa. And why an analytical task can open or close at any time. And about how this ruins sprint reporting for the entire team. I won’t talk about it. But, I ask you to think about this, again, about quality, in this case, about the quality of analytical work. If your sprint planning is purely formal and you don’t keep a separate map or list of analytical tasks, then the analytical work is disorganized. To prevent this from happening, analysts resort to the help of external tools, and can form a parallel sprint outside the rules of Scrum, it will probably be in a tool something like Trello. As a result, we get a string situation that if you work according to the rules of Scrum, it entails disorganization of the analysis, and parallel work outside of Scrum is the underwater part of the iceberg that is not reflected in the reports and describes a bunch of work and risks on the project. What to do with it?
Hello, I am a designer, I will build CJM
Designer is a relatively young IT specialty. The activities of designers are very closely intersected with analysts. But they deservedly won their place in the sun. What are their cool tools like Figma, and their wonderful techniques that they stole from marketers, just kidding, borrowed. I will not describe banal things about the need to build CJM together and not go separately to different users. And depending on how the analyst and designer work together, they will become friends or enemies. I propose to see what the designers think about everything that was said above, because they also have to work in sprints. Or shouldn’t?
Combining Agile and design is like looking at a picture through a keyhole. The designer has to work in increments, breaking the whole into parts. It is this approach that can lead to what I call the “Frankensteining” of digital products or services.
Frankensteining occurs when products or services built using Agile become fragmented or disjointed. Fragmentation breaks the integrity of perception, which negatively affects the user experience.
It is easy and comfortable for programmers to work in iterations, but for designers it is not. Because it is easier for a designer to think over the concept completely, rather than split this task into smaller ones, while losing a global vision of the client’s problem to be solved.
It turns out a dilemma: either qualitatively and for a long time (when the concept is thought out holistically), or a raw product, but quickly (when there is no time for a global vision, but the work is subject to the laws of Agile).
In fact, a compromise solution was invented long ago – parallel streams of design and development, where the design stream goes ahead by one iteration.
As you can see, if “design” is replaced by “analysis”, we get a similar situation. Well, how do you like this Agile, where analysts have their own sprint in terms of content, designers have their own sprint, and developers have their own. Let’s say they even technically work within the same sprint in Jira. But according to the rules for the sprint, a goal is assigned, what is the goal of such a sprint? How is reporting collected?
Have you found a job as an analyst in Scrum?!
And there he is not. Well, no, no, you can add? But first you need to understand a simple thing: Scrum is way of organizing work for creating software products. And the types of work on the creation remained the same as before: analysis, design, programming, testing. And here you need to understand the second simple thing: the task of analysis is the fight against uncertainty, in order to come to an understanding. Scrum does not allocate a separate analyst role for this. Analysis, design and programming work is performed by the developer. This organizational method works well for a small team, where close interaction, rapid exchange of information, direct contact is implied by the concept of “Product Team”. As soon as the second product, the second team appears, and it is necessary to ensure the interaction of the team, which means understanding between the teams, then Scrum has no way to organize this. To solve this problem, I begin to use other methodologies, for example, SAFe. But if Scrum is used at the bottom level, then this means that the understanding of the product is locked in the heads of the product team. And this is where the fun begins:
Did they have the time and task to write the documentation?
Should developers write documentation at all?
Who among the developers wants to be distracted by the questions of the neighboring team?
Does one of the developers want to analyze the Scrum board and backlog of the neighboring team?
Does he want to agree on something and make compromises?
And, of course, a brilliant idea arises: “Come on, let the analyst do it!” In addition, developers get tired of doing the analysis prescribed by Scrum, it is interesting at the beginning, but somehow difficulties arise, their enthusiasm quickly disappears. After all, it is much more interesting to write code. This is how the analyst gets his cut. Now he needs to somehow organize his work, which means facing the difficulties that I described above:
conduct a comprehensive analysis broken down by sprints;
work in two active sprints;
don’t break the team’s scrum board reporting.
Samsara / Scrumsara
All the designs on how to embed analytics in Scrum are specific to the project and the company, they even look good at first glance, but in practice they are limited in performance, just like the waterfall model works in theory, but in practice it all depends on people. And, generally speaking, if you have a team of professionals, then in principle it doesn’t matter what methodology they work with. But what I know for sure is that working according to the “Scrum + Analyst” scheme on live and fairly active projects regularly leads to the burning of analysts’ work and burnout of the analysts themselves. They are motivated to work in such difficult conditions. Phrases like “No need to look for the guilty, you need to get the job done!” are used! or “We’ll fix it later,” and the like. But since Scrum does not inherently assume a separate role for the analyst, this is irreparable by any retrospectives. No matter what anyone says, Scrum cannot fundamentally change itself. Maybe you need to accept the fate of the analyst in projects that are carried out according to some version of “Scrum + Analyst”? Is this Skramsara?