This article aims to encompass, detail and solve a project’s life through the process of refactoring and how this has been detrimental in the life cycle of Altenar’s sportsbook solutions
This is a true story in the “first-person" format fr om one of Altenar’s IT analysts. I hope that our experience on refactoring features will be useful to you.
Have you ever done an apartment renovation? A beautiful project, a clear plan, euphoria fr om the anticipation of a quick result, a lively fire in the eyes of employees, their optimistic promises at the start… But all this is quickly replaced by disappointment, bitterness and an ever-present desire to finish your favorite repair as quickly as possible with minimal expenditure of moral strength and material resources. After all, quite soon the first difficulties and delays appear. All of a sudden there are not enough materials, and the available ones were simply selected incorrectly.
Unexpectedly, new unaccounted-for jobs appear, and the complexity of the planned ones turns out to be catastrophically underestimated, employees give vague explanations of the reasons for the difficulties that have arisen and draw vague prospects for their elimination. At the same time, the quality of work is so “outstanding” that much has to be redone, and often with the involvement of other employees. The estimate is growing, the deadlines are flying beyond the visible horizon, but there is no turning back. Welcome to the world of refactoring!
The Essence & Aims Of Refactoring | Tech Solutions
Despite the fact that it was with the above scenario that we encountered in our idealistic attempt to perfect one of the most important tools of the company's main product.
This article is about our difficulties, ways to overcome them and the benefit for the company, Altenar, for which it was worth going through the pain of never-ending difficulties and overcoming these in the small time frame of 5 months. In case the topic of refactoring is not relevant enough for you, then this article may well warn you against mistakes in the repair of your apartment.
With the apartment metaphor lost to the early lines of this article, I will immediately make a reservation that although the article was mainly inspired by the experience of implementing this refactoring project, it nevertheless summarizes the daily work of our company, Altenar. So, surprisingly, it turns out that there is more and more diverse refactoring in this work.
Refactoring itself and the implementation of new features are sometimes so intertwined and inseparable that it is difficult to distinguish one from the other. For this reason, this article can be attributed to a lot of what is happening in our company. Naturally, all this is adjusted for the perception of what is happening through the prism of my personal and potentially not always objective views.
First of all, we will eliminate any ambiguity and clearly reveal the meaning of the concept of “refactoring” in the context of this article. We are not talking about highly specialized types of technical refactoring, such as code refactoring, database refactoring, or architecture refactoring.
Here we define refactoring as a functional and technical upd ate of a particular part of a product, and the upd ate is large-scale, so much so that it leads to the creation of a new significant business value.
So, our company, in international terms, is a sportsbook software provider. In this niche, we have our own flagship product, and we continuously strive to build on its excellence with each and every day.
The back office of our product has a tool for managing event results. This tool is one of the most frequently used and important from the point of view of ensuring the smooth operation of the company. Its work involves visualizing a large amount of data and managing individual elements of this data, including filtering them, manually changing them, and saving them.
The tool consists of two forms: event management and event results management. The amount of data on the second form can reach more than a thousand objects with at least two more controls with seven options to choose from. And, all this on one page … without pagination.
Refactoring In Context | Altenar & You
To understand the context, we will make a small trip into the background of our product. At the time of launching the refactoring project, the backend was completely written by the backend team in C# using the Kendo UI framework and supported by its forces. This created two major problems:
- The backend was constantly distracted by the admin panel to the detriment of server logic tasks
- The very quality of the admin panel no longer meets our requirements from a functional and UI/UX point of view.
We were well aware that in this form, the back office was implemented as a temporary solution and became a victim of the desire to roll out a new version of our flagship product to production as soon as possible. There came a time when the importance of new business requirements for the back office outweighed its existing technical potential, and the company made a strategic decision to completely rewrite the admin panel. After all, in addition to using it more effectively on our side, we planned to significantly expand its use by our clients.
Among the goals se t at that time: the implementation of new functionality with the possibility of its flexible and rapid expansion of the development of a new UI/UX interface by specialists, the use of new technologies for implementing the frontend.
It was decided to move towards these goals by gradually updating form after form, i.e. embed refactored pages instead of old ones in the existing back office. In the end, according to our plan, this process should have led to the complete absorption of the upd ated admin panel of its predecessor.
It was decided to implement the frontend by the frontend-team in Java Script using the React framework and the Material-UI library. Looking ahead, the choice of react was a fatal mistake of this project, since at that time the company used the Vue framework for all production solutions. Now, after the fact, we can say that with the start of large-scale development on React, we were in a hurry, but we all understand perfectly well that life without ambitious challenges is boring and uninteresting.
In relation to the refactoring project of the tool described above, two extreme states can be fixed:
- Original: we have a "not quite good tool".
- Desired: we want to have a “very good tool”.
The vector between these states sets the trajectory of project implementation, and the “potential difference” between them - motivation, energy, and speed of movement along this trajectory. With motivation and energy, we were fine, but at the “speed” point, our plans failed critically. But about this in order.
Next, I will focus on the project team as its most important resource, the actual stages of the project's life cycle, and, most importantly, the lessons that we learned from this challenge, which in fact this project has become for us.
However, and first of all, I must list the main results that we received at the end of the project in order to understand the context of further narration:
- Exorbitant terms of implementation. Instead of the expected one of two months, we got 5. Having no experience in planning and implementing so many large refactoring projects, we could take some liberties in scheduling deadlines, but we didn't expect things to get so complicated.
- Working functionality, which covered 99% of your business requirements. There are a number of minor issues that have been postponed due to the next item.
- Low level of technical implementation of certain aspects of the frontend part, in particular, the architecture and individual components. This does not allow us to upgrade the tool flexibly and quickly at the moment, and requires a new mini-refactoring.
A Team Of Daredevils | Altenar A Sportsbook Provider
The composition of the project team was determined by its content:
- It was necessary to implement a sufficiently large amount of new basic server logic that provides advanced processing of incoming data according to new business requirements.
- It was necessary to implement the backend (API) and frontend (interface) parts of the new tool that works with the new server logic.
- Of course, it was necessary to develop a mockup of the new tool, embodying in the interface the best UI / UX ideas that our company was capable of at that time.
- Comprehensive testing of a new large tool required non-trivial efforts on the part of the QA team.
It would seem that you can form a SCRUM-a self-organizing project team of the necessary technical specialists, se t a task for the team and simply get the finished result in a reasonable time. We naively assumed so. I can assume that many readers of this article understand that such technocratic idealism in practice, as a rule, does not work.
The greatest failure is caused by the interpretation of business requirements in those specific tasks that fall on the developer’s input in the right volume, with a clear interpretation and in the correct sequence, as well as ensuring coordinated work of all team members, quickly overcoming all current problems and progressive product creation.
The whole reason is that a large task, multiplied by a considerable number of diverse specialists involved in its solution, often becomes unsolvable without applying non-standard organizational approaches that are relevant to each specific company.
Trying to practice non-standard thinking, even before the start, we firmly decided that in addition to technical specialists, we need a bridge in the project that will unite all team members and will permanently direct their efforts in a common direction in exact accordance with business requirements, and at the same time ensure the creation and effective operation of all the necessary processes for project implementation, starting with from initial interaction with stakeholders to meeting their needs with the results of the final release.
We do not have any strict formalized “project management”in our company. In principle, we do not have it at all. We have excellent technical specialists, two-week sprints and many, many rallies. In any case, this was the case at the time of the project's launch.
In this matter, we made a knight's move. At the initiative of a business analyst, by the way, the author of this article, we decided to give him the functions of a project manager. He knows business requirements better than anyone else, communicates with stakeholders, and also writes tasks for developers, i.e. actually accompanies the entire life cycle of new product features.
This solution also looked very attractive from the point of view of optimizing organizational costs, allowing you to load an existing staff unit with important management functionality instead of creating a new role and hiring an additional employee. Looking ahead, I would like to note that this approach has not only fully justified itself, but has also become the basis of the current project management in the company.
As part of that refactoring project, I preferred to use the term “coordinator” instead of “project manager”, trying to keep the horizontal format of the team and not distinguish this role as a managerial one. In my understanding, this coordinator is one of the ordinary team members who, like everyone else, solves technical issues on the project (in this case, works on business requirements, formulates tasks, describes algorithms, logic).
Nevertheless, for ease of understanding, we will refer to him as a project manager (RP) by default. So, we have introduced a management unit in the form of a business analyst with the functions of RP. In the future, when we mention an employee, we will mean that they are also a business analyst.
On my own behalf, I would like to add that I also se t a super-task for myself, as a manager, to maximize the potential of the project team and each participant individually in order to increase the productivity of joint work as much as possible and solve personal development tasks for myself as a manager.
In my opinion, there are very often undisclosed command reserves and growth points in this direction. I relied on ensuring the utmost clarity of tasks for developers, coordination of actions, personal work with each project participant for full and effective involvement in the overall process, and, finally, transparency for the team of project plans with a clear focus on the final result, so that the focus on the final desired state is constantly maintained.
If you see a mountain to climb, then the forest in front of it will not become a difficult obstacle to overcome. But if you only see the same forest, then it will become harder to pass through it without having a larger final goal in front of your eyes.
| Aspect of work | Team at the time of launch | The production result and organizational implications |
|---|---|---|
| of UI/UX: | A high-level UI/UX specialist has been working in the company for several months, for whom participation in this project was the first and also a very large and difficult task in relation to our main product. | The problem was solved quickly and efficiently. This was the result of a very tight work of the Project Manager with the designer. A preliminary draft of the mockup was presented by the Project Manager The designer completely reworked it creatively, having received an extremely complete understanding of the business context from the Project Manager (PM). At the beginning of implementation, a number of improvements to the mockup were additionally made on the initiative of the developers, which was an important achievement of our team as a productive self-organizing team. The mockup was agreed with the stakeholders. This work did not cause any difficulties due to the strong competencies of the designer and laid the foundation for the design solutions of our back office based on the Material-UI library. Currently, our UI / UX division has grown to four people. Work on creating high-quality interfaces has been put on stream. |
| Basic server logic: | The company had a single backend team that handled all server logic, as well as fully supported the back office. The division within the team into separate components and system blocks was conditional. A developer who had experience relevant to the project content was assigned to the project. | The implementation was also based on the tight work of the RP with the developer to ensure the utmost clarity of logic for the latter. The logic itself was voluminous and complex, consisting of several large epics, and affected the logical core of our product, which caused difficulties in understanding some aspects of the requirements during the implementation process. The developer also made suggestions for optimizing business requirements, matching them with the features of the product's engine-room operation. In general, this task was also completed quickly and efficiently. Later, during the project implementation, the entire backend team was divided into several application teams in accordance with the system components and subject area of our product. This allowed us to maximize the development of developers in certain application areas and thereby improve the quality of implementation. |
| Backend part of the back office: | This area of work was almost new for us. The monolithic architecture of the product had to be divided into server logic and back-office logic. From the backend side, it was necessary to develop an API for the frontend project and, in general, the architecture, technical approach to developing and supporting the API for further development of the backend on new tracks. We did not have any specialists with extensive experience in this particular issue, except for the lead of the backend team. One of the backend developers volunteered, who found it interesting to take part in a new project for the company with the prospect of further development of the backend. In addition to motivation, he had a very large professional potential, and was included in the project team. | Responsible and professional people are often perfectionists. So, in this case, our specialist, instead of developing the API in full as soon as possible and transferring it to the front-end team, began to search for some better approach for developing and maintaining the API. In short, he took up research work for the future, which no one directly asked him to do. This was not due to the fact that he did not want/could not deal with current project tasks, but due to incorrect feedback from the front-end team at the beginning of development. He simply acted according to the agreements with the front-end developers that they make API methods consistently at their request, so he was in no hurry to fully develop them and was simultaneously engaged in the development task on his own initiative. Of course, we made a serious mistake in this matter, which we realized and corrected about a month after the project started. The API for new forms of backoffice needs to be designed and developed immediately in full, so that the front-end team gets the finished result and can flexibly and independently plan their work. Despite these temporary misunderstandings, at some point we dramatically accelerated the development of the API, switched to team planning for this work, and quickly achieved our goal. Having gained quite a lot of experience and a powerful impulse of professional development from this project, in the future, this specialist became an excellent team leader of the backend team of backoffice. His team is growing, and in his person we have received a high-class developer, on whom the development of our product largely depends. |
| The frontend part of the back office: | Is the most interesting and dramatic point about the project team. We came to its start with the following introductory questions: 1. The frontend team did not have a team lead (he left the company shortly before). 2. The frontend team had no experience developing in React. 3. No one in the frontend team was eager to participate in this project. However, one very strong developer was assigned to the project. All of us, including him, thought that the implementation of the frontend part would take no more than a month. With such an optimistic plan for implementing the frontend, we got down to business. | In short, everything went wrong. And if on points, then: Optimism in the estimates of deadlines was greatly exaggerated. In fact, the development React of some seemingly banal elements on React took many times longer than expected. We just hung out for a week+ on some tasks for which we were waiting for a day or two. And no one could do anything about it, because The company did not have any expertise in React. Initially, the entire mockup was not decomposed and planned for development. Let me remind you that these are two functionally complex forms. Our developer started the implementation with a single element, without describing further steps. As a result, we did not have an important section in the project plan, which means that we could not manage either frontend development or the entire project, and we were not able to parallelize work without decomposing and defining logical connections between subtasks. We only worked on one form. As soon as we saw a delay in the deadline for it, we had to add the developer to the project and give him a second form to work in parallel. Long element-by-element development without full decomposition required the backend to use API methods only for the current elements. This lulled the backend's vigilance, who believed that everything was going according to plan, and the frontend was getting everything it needed. When we decided to add a second developer in parallel using a different form, we simply couldn't do this until the backend finished its part. Lack of sufficient experience in React and piecemeal development led to the fact that the second form did not have an optimal architecture, which still does not allow us to improve the functionality on this form and causes performance problems. The architectural refactoring I mentioned above is required. In general, frontend development on this project has become one big and very painful problem for us. A total of 5 developers participated in the project. For one reason or another, only one of them continues to work on back-office. The project did not allow us to create a frontend-team по back office team, but it gave us a clear understanding that we really need it, starting from a team lead with excellent competencies in React and continuing with competent and motivated developers. Currently, a few months after the project was completed, we already have the coolest team lead and a great team under his leadership. The work is fully unified and structured. Productive interaction has been established with the backend team. We're practically happy. |
| QA | We were lucky. We have a great QA team in our company. Of course, there are sometimes difficult and stressful moments in this issue, because features are becoming more and more complex and voluminous. In my opinion, we overcome all such difficulties due to the fact that our testers are very competent and enthusiastic people who live by the product. Their team has a special atmosphere that is always pleasant to get into, because when you are with them, you can look at the product with a fresh, critical look with wide-open eyes. From QA, a specialist was appointed to the project, who brought the same atmosphere. He was paired with a new employee for this project. In total, we had two testers, one of whom had no work experience in the company. | Perhaps this was the most fascinating aspect of the work. Bugs rained down on our heads in an inexhaustible stream. At some point in time, we just started to drown in them and gradually dissolve. Our testers tried to give out on the mountain as many bug descriptions as possible. And here we were forced to restructure our work in such a way as to stabilize the situation, stay afloat and integrate work on bugs into the current development process until all errors are completely fixed. We did the following: Testers began to analyze all bugs additionally for their relationship and search for common root causes, in order to kill several bugs with one generalized description and reduce the volume of descriptions of special cases. All bugs were described in epics for each form, not in dozens of separate subtasks, and were numbered. Next, the RP evaluated bugs, prioritized them, and scheduled their elimination in accordance with current plans. Testers analyzed the business logic inside and out, made suggestions for improving it, modeled all possible cases, and comprehensively checked and tested the feature. As a result, we gained new experience in QA and very quickly trained a new employee in conditions of very intensive project work and dense team interaction. |
It is fair to note that the organization of our work is based not on a rigid vertical boss-subordinate structure, but on soft, almost horizontal connections, the main driving force of which is dense team interaction and personal motivation of employees. The structuring elements in this system are "team leaders". They also play the role of “those leads”.
Based on the meaning of these roles, their main responsibilities include leadership in the field of people management and technology development, namely, the distribution and accounting of tasks within their team, as well as making technical decisions and coordinating them with the leads of other teams.
Since representatives of different teams work on each project in the matrix team format, and projects are often complex and not trivial in nature, there are often cases of technical inconsistencies, blockers, white spots, and stuck questions about the interaction of system components that are responsible for different teams.
As a result, the implementation of the seemingly original clearly and consistently formulated epics gets bogged down in the emerging confusion of many parallel tasks. And by default, it is the team leads that can reanimate the work. And in this regard, I would like to point out that it is necessary not only to be called a team lead, but really to be one, on your own initiative, quickly delving into the existing difficulties and closing those white spots of collective work and technical problems that provoke the greatest failure and overspending of time resources.
Team leader was born with such a leaven on this project for the backend and back office team, which in itself is a huge achievement of the project.
The Project's Life | Twists & Turns
To paraphrase the title of one of the most lyrical bard songs, "refactoring is a small life." From this metaphor, it follows that a refactoring project, having a certain evolutionary outline, can be filled with unexpected and not always pleasant twists and turns, which, as a rule, are characteristic of our life in this crazy and unpredictable world.
Just as each person has their own unique path, complex, large-scale projects pass through unpredictable circumstances, often far from the original plans, if there were any at all at the start.
Our project has lived a somewhat hectic, thus very exciting, but ultimately fruitful life, which can be divided into the stages described below. Some of the facts may be partially repeated with the above, but this is only because this information is important, and repeating important things never hurts.
|
Stage |
Circumstances stage |
Emotional context |
|
Initial enthusiasm |
The beginning of the project was marked by a fairly rapid development of the upd ated layout of the new tool.
Despite a fairly strong redesign of the UI, the layout was quickly agreed with stakeholders and received the go-ahead for implementation.
There was clarity about how everything should work. The functionality was described for developers.
In general, at that time there was a seeming understanding of what and how to do it, and even an enlarged project plan with deadlines was available.
|
Strong optimism. The burning eyes of the team members.
The anticipation of a quick and easy victory. Complete absence of doubts about success. |
|
First difficulties |
The development of the new tool was carried out in three main directions: system logic, backend part of the back office (API, working with data), frontend part of the back office.
The first direction was implemented independently, with some delays, and there were no problems with it. The last two directions were paired.
The backend and frontend team agreed to gradually implement the API from method to method.
The developer of the backend team actually stopped working on the API, because the frontend team requested one (or two) methods on the main page of the tool and began to delve into the details of developing the corresponding frontend part.
React development was causing problems. The frontend team has become very stalled.
The backend developer, in the absence of a download, went into free floating and began to engage in self-education and solve some architectural and technological issues known only to him that are not directly related to the project.
Only with time did it become clear that this work was a valuable investment in the future. Its results came in handy later.
In fact, even at that time, he was solving all the leadership tasks of his then-defunct team.
However, at that time, the project itself began to gradually get out of control. control system. As time passed, no quick expected results appeared. Meanwhile, things were moving towards the New Year 2021.
|
Optimism has waned. Tension began to build due to the lack of a planned result.
Nevertheless, I would like to think that everything is about to get better, the current problems will be solved and we will quickly complete the project.
In reality, this was complacency coupled with a lack of understanding of the real scale of the negative consequences of the problems that appeared.
Apparently, a psychological defense was activated, which caused a subconscious refusal to face the root of the problem situation.
|
|
We reached the bottom |
after stalling for several weeks on linking a couple of API methods to the admin panel. Finally, we realized that the project was up and rolling in a well-known direction for such cases. It clearly went beyond the expected limits and was actually thwarted. More than a month has passed since the launch.
In the bottom line, they had only a small part of the API and the semi-working functionality of the main page of the tool.
This situation escalated to management. Analysis of the situation showed that:
A frontend developer (at that time only one) had fatal difficulties in implementing React (before that, he worked on Vue).
Work that is evaluated in one day is completed for more than a week. Only the first page out of two is started. In fact, it was 10-15 % of the total volume. The developer announced updated deadlines for the first page.
They looked very optimistic, but, as it turned out later, they were underestimated several times.
At the same time, the developer offered the manager to switch to Vue, explaining that this would reduce the time frame, but this proposal was rejected, as it went against the company's technical strategy.
In fact, this was the same 10-15 % of the total API volume of the entire tool.
And all this for more than a month of work. As a result, the task was se t to finish the development of the API as soon as possible and continue to torment React with renewed React.
Another frontend developer was also added to the team. Frontend developer was also added to the team to get started in parallel working on the second page.
At the same time, we started working closely together as a self-organizing team.
Planning the work of all developers was carried out centrally by the RP (analyst-coordinator) of the project.
The meetings have become daily, and the discussion of current progress and problems has become dense and detailed.
With that, we left for the New Year.
|
The tension in the team continued to grow. We did not yet realize (or did not want to realize) what was happening, considering that in our business difficulties are not uncommon, but there is always a way out.
In addition, there was a light at the end of the tunnel - we integrated more strongly as a team with a more fundamental understanding that it was time to stop wasting time, it was time to finish this project faster. There was a healthy anger.
Although we actually pushed off at the end of that stage from the bottom, we did not yet know that the ascent would be excruciatingly difficult. |
|
On the verge of desperation |
, the organizational achievements of the previous phase bore fruit and the API was ready quickly enough. Yes, it was finalized almost throughout the project, but these were already minor details.
The most terrible problem was revealed in all its glory in frontend development. We just got in on the exact timing. We were moving at the speed of a half-dead turtle.
It was as if we were part of an endless slow motion scene in some tragicomic movie.
And increasing the number of developers did not solve this problem. No one had enough experience in React. They were juniors and learned more from the manuals through the process of developing. In particular, they learned from their mistakes, that is, at the cost of deadlines.
Not only was the implementation time stretched many times, but some things had to be redone due to erroneous implementation.
At the same time, backend development was also constantly involved in the process. In addition to the API, it had other important issues on its shoulders - exception handling with error returns, displaying notifications about completed operations, and finalizing server logic.
Many things were done for the first time. They were created and tested on the go.
Despite all the complexity of the situation, we continued to work and do our best. In the same period, an important organizational transformation took place.
The initial description of the tool's functionality turned out to be inconvenient for front-end developers.
Instead of a single large description, they wanted to have decomposed tasks that they could do relatively quickly and submit to the test. This was due to the fact that there was no team lead that could perform decomposition and issue tasks.
For developers, the presence of such tasks played an important psychological role. They could get results faster and see their progress.
We agreed that the RP will create and describe these tasks in consultation with the developers.
In addition, we began using the Gantt chart to visualize the relationship between tasks and the path to the final goal of the project.
But the project moved very slowly, and it put a lot of pressure on us. We tried not to dwell on the negative aspect and act on the principle of " do what you have to, and come what may”, but it was very difficult.
|
The tension grew to a peak. There was a feeling that the whole world was against us.
It might even seem that it is easier and more reasonable to abandon this project and come out with the lowest reputational costs for yourself, rather than continue to drown in its quagmire. The general trend was such that the team began to feel discouraged, and the company's management began to overflow with discontent.
But we gritted our teeth and continued to do our job and not just do it, but try to improve our work as much as possible.
We only focused on that, which saved us in the end. |
|
The Force Awakens |
Strong team interaction, clear organization of work, quick solution of emerging problems, clear and understandable task management have borne fruit.
In the face of a very long implementation period and the disapproval of the business department for the lack of a long-awaited result, the company's management nevertheless believed in the project team and gave it the opportunity to bring it to completion.
The most valuable thing that the management did then - not to interfere with the team, completely entrusting it with the project. This played a key role, becoming a spirit-raising factor for all participants.
At this stage, everyone began to understand that we were doing the " right thing”, that this is really important and valuable work for the company. the implementation of which is becoming more and more productive and efficient.
QA representatives actively joined the work. They were almost completely engaged only in this project and were extremely focused on it.
The integration of team members was exorbitant. Moreover, this concerned not only the professional aspect, but also the human one. It was then that a truly self-organizing team was formed.
|
The emotional tension of the team members significantly subsided.
Healthy emancipation began to be felt. Enthusiasm returned.
Attention was focused exclusively on current tasks, on their high-quality performance.
Distraction to external negative stimuli was reduced to zero.
We caught the feeling that now we are going to the end and will make sure that we are not ashamed of the final result. |
|
Striving for excellence |
At this stage, we already had significant pieces of the new tool working. We already understood quite clearly what we were getting in the end. I then took the position that I should try to create the most perfect product in the remaining development time.
This meant that we had to go beyond our understanding of the product, written and unwritten, and in the process of working for the remaining time, continuously search for and implement opportunities to improve it.
This applied to absolutely everything-from the cosmetic polishing of the interface to the adaptation of system logic to our new understanding.
As at all previous stages, active work with stakeholders continued during this period.
They were aware of everything that it made sense for them to know in order to be able to contribute to the improvement of the product.
All significant adjustments were agreed with them, and their expectations were very well formed. The team's work was completely synchronized with the external environment.
We were moving towards the release with cosmic speed at the lim it of our productive forces.
Even hours before the release, we were still completing some tasks and rolling out updates to the test environment. Still there is no lim it to perfection…
|
The emotional atmosphere in the team was approaching perfect.
We enthusiastically created something new with the awareness of the high importance of our mission for the company.
There was complete immersion in the process, attention to detail, and a broad vision of the product.
We were looking to the future. We created it. And most importantly, the team has become a single entity.
Each of us felt like a part of a single whole, and the sum of all of us gave rise to a qualitatively new formation, within which we could reveal our potential much more and resonate with each other.
This is the most magical state when you get high from the creative process and become happier from the results obtained. This is exactly what the atmosphere should be like for teams to create brilliant products. Fast, easy,and highly motivated. |
|
Long-awaited release |
This was one of the most anticipated and exciting releases of my life. I can assume that not only in mine.
A fairly large piece of our product, created over several months of work, was waiting to be released in production.
The result was very boring. The delivery was successful, the new tool found a new life, still lives and is constantly being improved, getting rid of shortcomings and acquiring new features. |
The tension rose again. As usual in such cases, fear of possible failure was in the air. But the eyes are afraid, and the hands do.
The first feeling experienced after the release was not the excitement and joy of launching a new tool, but relief from the fact that we were freed from the burden of the huge responsibility associated with its creation
, although then, as the first emotions subsided, a well-founded and well-deserved joy came. |
Of course, not all projects in our company are so epic. In this case, due to the long duration and high complexity, the project has absorbed a lot of components in various aspects, and has become a collective image. It is like a fractal, which includes the features of everything that surrounds it. Looking at it, we can see how the entire company works, how other tasks and projects are being implemented.
Retrospective
Any activity in our life requires awareness. Otherwise, there will be neither a useful result at the output, nor high-quality development in the process. In the modern IT world, there is a practice of conducting retrospectives, which is designed to bring this very awareness to people's thinking and work processes.
On the eve of the release, we held a retrospective session with the participation of the entire project team and management. Naturally, having almost reached the finish line a few unplanned months after the start of the project, the team was eager to have an objective attitude to what had happened. And first of all, this was what the RP, which was directly responsible for the project timing and product quality, craved.
It required a detailed analysis of mistakes and achievements, their causes and consequences. As a result, the retrospective was very productive and solved all these tasks. We have thoroughly analysed the pros and cons of the project, recorded personal and team results, made conclusions about scaling a number of practices, and taking corrective actions. In summary, we have drawn two important conclusions:
- Each participant did their best. Even if mistakes were made, they were quickly eliminated, but even in the course of the project, the work was purposefully improved in dynamics.
- A key role in the implementation of the project was played by the same RP, who is also an analyst-coordinator. Of course, without it, the project could also have been implemented in some way. But the point is that “somehow” is much slower and with poor quality. In this case, we are talking about positive changes due to the role of the RP.
All project participants recognised that the existing team results were achieved largely due to the effective organization of work. RP ensured project planning, clarity of requirements for participants, elimination development process blockers, synchronicity of participants 'actions, relevance of results to the external environment, and stakeholders' expectations. This person connected all the components of the project together and sent this monolith in one direction. And all this is not surprising. RPS exists to make projects more successful.
In our case, an analyst with good organisational skills became the team member who performed the necessary RP functions for the company. It helped to create a productive working environment on the project, in which the potential of all participants could be revealed to the maximum extent. We continue to apply and develop this model of RP in our work.
Resume
This project gave the company quite a strong evolutionary impulse. The company began to change thanks to him, and in some aspects quite significantly. The refactoring of the product provoked the refactoring of the company itself. He opened our eyes to many important points and taught us many lessons. Personally, I began to look at my future work, including through the prism of this project, discovering many parallels with it and developing the organisational ideas that were highlighted by its results.
You can discover more about Altenar’s tech insights and uses by contacting the team today! You can request a sportsbook demo here.
