Hello! My name is Lyosha. I work in the division of Alfa-Bank, which is engaged in the development of electronic channels. Internet and mobile banking is all about us.

Often, speaking of Scrum, we mean one team working on one product and consisting of no more than nine people. But sometimes the product is so complicated that for its implementation by the appointed date nine people are few. What to do?

Today I want to talk about our experience in scaling Scrum, when several teams worked on a single product at once. How did we get here and what came of it? I ask all interested under cat.


We are currently developing a wide variety of products. Here you can find large monolithic legacy systems, the legacy of a large Bank, and innovative solutions, which are based on modern technologies, such as the blockchain or the technology of contactless payments . However, most products are web or mobile applications that allow customers to use the Bank’s services without having to physically visit its branches.
')
The main combat unit of our unit is the team working on the creation and development of a particular product. Most teams are cross-functional and live according to Scrum, which allows them to independently organize and carry out their activities. And this independence remained until the realization that our products are interconnected and we make not just separate applications, but integrated solutions that provide customers with a wide range of services.

Formulation of the problem

The Bank was tasked with creating a new Internet bank for the customers of one of the business segments by the deadline. The final product should provide customers with various services, such as making single payments, group operations on payments, generating a statement of payments and so on. Temporary restrictions dictated the need for parallelization of work, so a separate team was formed for each service.

In Scrum, teams are independent; they independently determine the length of the sprint, its purpose, and the list of stories that need to be closed in order to obtain an increment. Independence, in turn, could cause a number of risks.

Low priority functionality implemented

Each team has a product specialist who has a vision of the development of his product, a separate service included in the integrated product. This vision is often limited to a specific service. Therefore, the functionality implemented by the moment of launching a new Internet bank could have been significant within the framework of a separate application, but insignificant within the framework of a complex final product.

Functionality duplicated

And it’s not about application fronts anymore, but about middle-services called from the front. Sending a payment for execution to the Bank should be carried out using a single algorithm, regardless of whether it originates from the page of a specific payment or from the list of customer payments. Otherwise, the final product will be too complex for maintenance and development.

Only part of the integrated product has been transferred for accompaniment.

One of the requirements for the transfer of the product to the maintenance is the availability of documentation on the front and microservices. The description of the front should be given on the project page in confluence. Documentation for microservices should be placed next to the code in git.

Five teams worked on the new Internet bank. Two teams kept documentation in accordance with the requirements of functional support. The rest decided to keep all documentation in git, including documentation to the front. The decision is reasonable, but it could lead to difficulties in the transfer of applications for maintenance.

The product is one, and the design is different

Each team has a designer who is responsible for the appearance of the application. Therefore, even if there are certain agreements between designers at the time of assembling the final product from individual applications, discrepancies can be found in the components used by the teams, fonts, indents, etc.

The teams have been working in coordination for several months. However, until now, in the process of the design review, discrepancies are revealed that are promptly resolved. It’s hard to imagine what kind of load would be on the teams, if we knew about all discrepancies at the very end when building a new Internet bank.

Our solution

To prevent risks, they began to explore approaches to scaling Scrum. So they got acquainted with LeSS, according to which several product owners are assigned to one product owner with a single backlog, the activities of the teams are aligned with sprints, and to coordinate the work, general meetings are held with representatives of all the teams participating in the creation of the integrated product.

Of course, its features are everywhere, and the LeSS that we get is somewhat different from the framework described on the official website. But we did not strive for a perfect match. It was important to establish a coordinated work of several teams on a single product. And that's what came out of it.

Sprint

The teams leveled out in sprints. Now sprints start at the same time and last exactly one week. This made it possible to jointly plan and control work on a complex product.

One of the tasks facing all the teams was to transfer applications to a new design. Previously, the main menu was on top, and the background of the application was gray. In the target state of the menu is located on the left side of the screen, the background is white.

The teams took this task in the sprint, and on the penultimate day, the new design was rolled into battle for all applications at once. Thus, it was possible to avoid the situation when part of the Internet bank sections is framed in a new design, while some remain in the old one.

Sprint planning

Productologists have combined their backlog and completed a through prioritization of stories. The revision of the single backlog and the updating of priorities occur weekly before the planning of the sprint. This reduces the risk that teams will work on low-priority stories as part of a comprehensive product.

After the priorities are updated, the product owners disagree on the teams, where they jointly determine the goal and plan the next sprint. Moreover, the teams take in the work of history only for their applications, which allows them to save and accumulate expertise in a particular service of the final product.

The process is completed by a general planning meeting, where team representatives designate a list of stories they plan to take in the sprint. The overall goal of the sprint is formulated, after which the teams proceed to work.

Performance of work

Cross functionality in Scrum means that the team has all the competences necessary to develop a product. And it is not necessary that they are owned by absolutely all team members. So there can be only one java-developer in it, and only he can understand the code of services written in java. Who in this situation will review its code?

Previously, written code was often reviewed by developers not immersed in the project. Now developers of the teams working on one complex product participate in the code review. They are familiar with its features and nuances, which allows us to talk about improving the quality of the code, early detection of errors and preventing duplication of functions.

The interaction is observed in all functions. Automators conduct autotest tests. Analysts agree on a uniform format for project documentation. Designers work together to align the appearance of their applications. All this is aimed at improving the quality of the final product.

Sprint review

The teams see their contribution to the creation of a complex product at the general sprint review, when each of them demonstrates to the others what they managed to do during the sprint.

As you know, everything is relative. If the team, working in isolation, does not close part of the stories taken in the sprint, this can be explained by the phrase “they took a lot”. But if other teams took as many stories comparable in complexity of implementation, and closed them all, this is a reason to reflect on their performance and attitude.

Every two weeks, real users are invited to the general sprint review. The purpose of such activity is to clarify needs, show prototypes and get feedback. All this is aimed at making the final product the most valuable for the Bank's customers.

Retrospective

Issues of team interaction are discussed at a general retrospective, which is held after the team retrospectives. Many useful decisions were made on her. This includes determining the procedure for planning sprints, and adopting a single DoD for all teams, and developing an approach to receiving feedback from the end users of the new Internet bank.

Total

Is it possible to achieve synergy from the coordinated work of several Scrum teams? Practice shows that you can. We prevented the risks that could arise at the end when building the final product from several web applications. We began to share knowledge, work on improving not only our product, but also the products of other teams.

Of course, there are also disadvantages - teams have lost some of their independence, the number of meetings has increased, distracting participants from product development. But in general, the advantages of working together outweighed its disadvantages. Therefore, if you have several Scrum teams working on related products, do not be afraid to coordinate their activities. Perhaps coordinated work will bring them added value, and your customers additional value.