At one time, in an attempt to shorten the time-to-market, we managed to try and implement various Agile practices. As expected, the most viable of them was SCRUM.
At the beginning of 2020, we began to scale SCRUM, studied the LeSS framework and built offline interaction processes, but the pandemic made its own adjustments: in March we were transferred to a remote work format. I had to urgently rebuild everything.
Under the cut, we will tell you about what tasks we had to solve, how the SCRUM and LeSS tools helped us in this, and what came of it.
Decrease in offline sales
Of course, the pandemic has affected business performance. Dealerships, where customers came to buy a car on credit, closed, and our sales decreased.
But there was no time to worry: in order to build up the business and help partners, we transferred interaction with the client online.
Going online in one day?
In the beginning (let's call this time "before the pandemic") the whole team sat together, a physical board with tasks hung on the wall, and planning and retrospective took place in the office "behind closed doors." We just tried to follow the AGILE Manifesto and the SCRUM Guide.
But over time, the team began to grow. The guys from Samara joined our Moscow development team. This made some adjustments to the established world and pushed to invent workarounds. So, we began to use video conferences and Skype for Business more often, and for the daily we put a webcam near the physical board. But even despite the fact that the team was distributed between Moscow and Samara, it, in fact, remained offline.
We had the opportunity to hang up interaction rules that were in sight and helped in our work (for example, rules for planning, daily, grooming, retro). Everyone could pay attention to them.
This was not the case online and we had to look for other approaches to using best practices / tools.
IT isn't Flex at all
It turned out that this is not such a trivial process. The bank has been actively and for a long time working on the transition to the Flex-office, which allowed the majority to go online painlessly. But IT is a separate world: it is difficult for us to take a thin 13 ”ultrabook and leave to work in a cafe, we need powerful productive computers, large diagonal monitors and, preferably, at least two pieces.
What can we say about the ability to remotely connect to servers - information security in any bank is extremely important, but this requires additional approvals, settings, the use of cryptography, and so on.
And, of course, the human factor cannot be omitted. Yes, IT professionals love to sit in silence, most of them were happy to be able to work from home while sitting in a comfortable environment, but personal communication is something that is sorely lacking. Questions that previously could have been easily resolved by exchanging a few words with a colleague in the format of communication via Skype, Slack has become more difficult to solve.
For example, how to transmit and take the floor, how to moderate a conversation with so many participants? Offline it happened organically, as everyone saw each other, and online we instantly lost all non-verbal.
To solve the problem with moderation, we suggested the following: each of the employees, in turn (for two days), became the leader of the daily scrum. Thus, everyone could feel the complexity of communication "from the other side" and understand how to better behave in online discussions so that all participants feel comfortable.
In addition, we solved the problem of "silence": when it is not clear who should answer a question addressed to the team as a whole (the team consisted of more than 50 percent of new employees who definitely faced discomfort in such situations). In this case, the moderator addressed one of the participants by name and asked his opinion. Thus, the “old people” did not pull the blanket over themselves when making decisions, and new employees could speak in a comfortable way.
And vice versa: we have proposed a “stop word” that stops a protracted and out-of-topic discussion. When someone says "falafel", everyone should shut up, park the issue that requires further separate discussion, and return to the topic of the meeting.
Smooth transition to "full online"
The transition to “full online” started quite smoothly: at first, we took all the meetings that remained face-to-face to online - planning, daily, grooming, sprint review, retrospective. All communication went through Skype for Business (fortunately, it was introduced in the bank a long time ago).
The next question was what to do with the physical board. We quickly came to the decision that JIRA allows us to make an online whiteboard with a similar visualization without much difficulty. This decision was on the surface, since we have been using JIRA for a long time to maintain Product Backlog and Sprint Backlog. For general convenience, the presenter took over the transfer of stickers from WIP to DONE, who broadcast the board in Skype for Business.
Retrospective
The most difficult, probably, turned out to be translated into an online retrospective. In the pre-pandemic world, holding a retrospective was a whole ritual - prepared exercises, drawn flips, purchased donuts / pizza / sweets - there was a lot of room for imagination. We tried to use everything to maintain a healthy and friendly atmosphere in the team. Therefore, when switching to online, it turned out that there are not so many tools for such a SCRUM event. We tried many tools: IdeaBoardz, Miro, Mural, FunRetro, and some others.
In the end, we settled on TeamRetro. This is a convenient platform with the ability to send retro results to the mail or to the desired channel in Slack, as well as, with other chips and "goodies". The functionality is really similar to many other platforms, but the point is in the nuances that greatly simplify the work: conducting votes, preparing cards, the mechanism of automatic grouping. In general, we liked it.
Communication with partners
By the way, about Slack: with the transition to "full online", this communication channel has found a second life for us. We connected our partners to it to discuss and promptly resolve issues, as well as other teams that are working with us on one product within LeSS, and revised the channel structure so as not to mix business issues with development issues or environments.
We also had to look for interaction tools with partners: Trello - to analyze bugs and improvements on the partner's side, Slack - for operational interaction and answer questions 24/7, ZOOM, Skype - for meetings.
We put all improvements and bugs on the partner / contractor's side in Trello to monitor their statuses. We have 8 columns: "New", "In progress", "Done", "Test", "Waiting for Prod", "Prod", "Completed (does not require removal)", "Hold". These statuses allow you to track where the task is currently located, as well as promptly notify new incidents. Both we and the partner have access to Trello, in case of a status change, a notification is sent to the mail.
With the move to online, it has become more difficult for business analysts to gather information. It was not always easy to arrange a Skype meeting, and correspondence by mail took too long. As a result, the process of obtaining data became less efficient and began to take more time than offline.
I had to introduce regular Zoom and Skype conferences with end users, with our customers (in this case, car dealers). They fumbled with us computer screens, clearly explained what their problems were. Based on the explanations received, business analysts drew conclusions and built business processes.
Online development and division into teams
When going online, it was necessary to clearly separate the stories in the Product Backlog and Sprint Backlog. Therefore, we decided to divide the work with history into phases "Discovery", "Delivery", "On Prod".
This is an example of a Discovery phase performed in a sprint. Based on the results of this stage, a decision is made whether to go to "Delivery" or leave the idea unrealized.
Scalable SCRUM (LeSS) requires the coordinated work of several teams on one product, namely, a car loan service. Testing hypotheses, developing and optimizing so many features is simply impossible with the efforts of one team. Four Scrum teams actually formed online during the pandemic, but that's another story too.
All teams are working on the Car Loan product. Online application is one of its features. The teams are engaged in the development of API for integration with software / CRM partners for receiving applications and processing credit transactions, development and implementation of new services and services for clients (for example, "Prolongation of CASCO online", "Reduced rate for online lending"), integration with external systems to optimize the process of filling in data by the client, for example, with the ESIA service. All tasks are aimed at increasing the application funnel and converting applications into loans. The teams have common commercial KPIs, so everyone is interested in doing what will bring results.
The teams are working not only on new features and process improvements, but also constantly make changes to the already implemented improvements, fixing bugs both from "Sale" and "Test".
Online results for 3+ months
Testing
In the testing team, the priorities shifted to tasks due to the increased pace of development of online services. In this regard, at the beginning of the pandemic, a small rush occurred, but then the load leveled off.
In general, during the pandemic, the number of tasks did not change significantly, but it became possible to distribute the load throughout the day. For example, work with longer breaks, extending the work day.
Development of
It was quite difficult for us to assess our performance. Initially, we had only five people on the development team. More precisely, even four and a half, since one participant was partially loaded with administrative issues.
In three months, we recruited five more people - therefore, the comparison of the results "before" and "after" should be carried out taking into account both the increase in the number of team members and the time spent on their training, adaptation and immersion in new conditions.
But we do have a good metric called achieving sprint goals. Previously (sometime before June) we successfully coped with only one of the three planned goals, and in July we reached 90 percent.
Another important indicator is solving problems related to covering technical debt: refactoring, fixing sub-optimal implementation, and so on. If the team is overloaded, there is no time to allocate for this, and everything is put on the back burner.
Over the past one and a half to two months, we have managed to solve many such problems: we have abandoned legacy in many places and even were able to completely rewrite something, using new technologies (for example, React).
In the 5 months before the pandemic, we made 146 stories / tasks / bugs. For 3 months, 198 stories / tasks / bugs were made in isolation. With the move to online, the team not only did not lose efficiency, but, on the contrary, became even more focused and productive.