How not to drain your customer’s 10 million budget while playing with Agile
In this post, I will talk about the problems that our Scrum Front End team faced during a year working on a decent project. We started developing the project from scratch using the React + Typescript technology stack. Looking back, I see many millions wasted simply because the development process was not set right from the start. But there are reasons for this.
First you had to win the tender. To do this, it was necessary to quickly file a Minimal Valuable Product. And here lies the first mistake that cost a decent amount for our customer. It sounds like this: quickly gash MVP. The customer wants to quickly see the result, but this means that we sacrifice good infrastructure, reliable architecture and a year later we came to the conclusion that our Front End architecture requires serious refactoring. About a few months. So we leaked 500,000 rubles.
Looking back, I can say with confidence that the first thing to do was take into account all the functionality that the customer wanted to see in the end, after a few years. So we could avoid architectural errors in the style of "this architecture does not provide for this." As a result, each major chip required serious refactoring.
In order to win the tender, our company sent developers who did not have experience in designing large applications and reliable extensible systems. Clear business, the tender is not an order, and nobody wants to scatter good personnel. But the lack of a technical architect at the (class level) led to the fact that our application turned into spaghetti code and stopped satisfying SOLID requirements. And here lies the error of each customer. It is not possible to maintain a constant pace of development without increasing team resources. The Agile principle “Investors, developers and users should be able to maintain a constant rhythm indefinitely” only works in case if the requirements were known and worked out from the very beginning, the entire set of functionality, a reliable and extensible architecture was designed (in a word, if each class was thought out taking into account the final functionality of the system) and the processes are clearly set. And this had to be done in MPV before sawing the product. Otherwise, with linear time, the complexity of the application grows exponentially. This means gash feature in a year will cost O (e (N)) more expensive than at the beginning.
In our team, the only designer was a remote employee. It was a serious mistake. A remote employee always lives his own life. He draws a design for himself, beautifully and well, the customer is happy. But all these charms ultimately boil down to the fact that on the same logical forms we have N different styles and layouts. From the very beginning, it was worth putting a requirement: stylize a certain framework (we had Ant Design). If something is not there, do what is there. The customer thought React was a block constructor. And he still does not understand why we are sawing primitive forms for 4 days. React is a constructor, but only if at the very beginning of development we have a set of similar reusable components (UI framework). A designer without layout experience will never do this himself. The developer will never tell the customer about this. This should be followed by the leader. So the leader of the Front End team should be the Front End developer in the past, and not the Back End as always. Therefore, we come to the conclusion that a fully-functional Agile team should include a competent leader in each of its areas of work (FE, BE). These leaders must have strong Soft skills in order to convey to the customer what I am trying to describe in this article. And this is very, very difficult. These leaders must have strong Soft skills in order to convey to the customer what I am trying to describe in this article. And this is very, very difficult. These leaders must have strong Soft skills in order to convey to the customer what I am trying to describe in this article. And this is very, very difficult.
When we released the first release, we realized that something was constantly breaking on the very last day before the demo. Throughout the year of development, each release branch turns into a hellish set of crutches (turn it off, remove that) which then magically end up in the develop branch. And there is a series of commits (turn this on, turn it on). After a year, we came to the conclusion that we need to have a clear branching policy. But most importantly, a responsible person who would eliminate the existing chaos. This meant: either to moderate the chaotic desires of the customer, or to moderate the chaotic bugs, or on each stand to have its own configuration disabling some kind of graphic features or buttons. Wrapping each button in an if statement is crazy. We have come to the conclusion that we need a plug-in feature-modular Front End architecture (disable - enable). I have been thinking for a long time how to achieve such an architecture. But one thing I understood for sure. We needed a full context. So the js-beans library was born (https://www.npmjs.com/package/js-beans). Each stand had its own json context. Plug-ins were collected in a chain (chain) through the Proxy pattern. So, for example, we had a data source as a separate bin, and various transformations were done as optional Proxy bins replacing this bin, but injecting it into itself. For example, if you need to scale the data model for testing FPS performance, I simply add the line to enable the scaling plugin in the json file. Something broke on the production, but it doesn’t play locally, I turn on the logger with one line without rebuilding the stand (the stand takes about 20 minutes, and a dozen stands are not always enough for everyone).
As time passed, the stands were turned off for a week. It was impossible to develop the front locally. We have not provided for autonomous architecture on the mokas. I had to gash it through the pain with a creak. Looking back now, I would have done it at the very beginning. But we had MVP, and we were forced to write code without deep engineering. But the customer considered us professionals, and thought that we should immediately write code without errors. Here is the following error. The name of the company does not speak about the professionalism of the team. The professionalism of the team is determined by the professionalism of the team leader. If there is no technical leader in the team, in a year your project will come to a standstill. So you merge a couple more millions.
We had a remote architect. But only one thing was known about him: he is. The last stage of development of the leader according to Vladimir Tarasov. In this our architect achieved perfection. Mistake number N: you do not have a technical architect who designs the system at the class level. You do not have a person to ask for help if you are at a standstill. Ask for help from other more experienced teams, the customer told us. But for some reason, the other teams never had time to help us. Our PR has been hanging for the second month. I sincerely hope that there is a brave man who will apprun him. As a result, life has rewarded our code with a rich abundance of paranormal phenomena in the form of magic and sets of crutches for all occasions. Only one was missing. Special Magic Annotationsand @Kostyle. Good idea for the next ES.
We decided that more middles and fewer men were more profitable for the project. Now we think differently. If you have a small budget, you need to hire the most expensive specialists. If you, like ours, have no budget problems, you can safely save on specialists and turn Code Review into a battle of psychics.
We thought we would meet the quarterly deadlines. Now we think differently. In short, for good, we need to rewrite the project. And preferably from scratch. I hope our customer will never know about it. After all, we just recently had a gorgeous team building)
We decided to play around with new technologies in which we had little expertise. They were recommended to us. Of course we wanted to gain experience. Now I think that it would be better to use only those technologies in which I have experience.
We gave estimates based on an 8-hour working day. In reality, estimates should be given on the basis of a 4-hour working day. Why doesn’t anyone include tea, telling interesting stories, searching for a toilet on the navigator, talking on the phone, correspondence, studying new technologies and, most importantly, enthusiastic disputes within the team. The latter is probably the most inevitable, and the most expensive. Although, to be honest, for Open Space you still need to throw a couple of hours. Constant talk terribly reduces concentration. Blessed is the customer who understands all this!
Our estimations were exhausting and turned into a tedious technical polemic anyway. The effectiveness of the rallies was minimal. But we found a solution: delicious pizza. When a delicious smell irritates the nose, a person begins to express his thoughts more clearly.
In the beginning we had one small team, then one big team. Planning took 2-3 hours. Standup 30 minutes. For what I respect our PO, it is because he decided to divide it into many small ones and to allocate his own mini PO in each of them. This was probably the best decision in the history of our project.
From the very beginning, we did not have time to write tests. After half a year, we came to the conclusion that they still needed to be written. But we still do not find time for this. Too much higher priority technical debt has accumulated. Do not save technical debt - this is utopia. He will always be.
My personal subjective conclusions:
You are unlikely to avoid all these problems even after reading this article. My goal is to show you that this is inevitable. And no matter how hard you try, you will never have ideal conditions. So just be prepared for it. And before dismissal, you can safely show this article to your customer. Let him be morally ready for this.
PS: Maxim, if you ever read this article, know everything that I described is completely fictitious and has no resemblance to our project) But all this is not important, because today I am going on vacation. The first vacation in a year of painstaking irregular work! (as FE lead).
First you had to win the tender. To do this, it was necessary to quickly file a Minimal Valuable Product. And here lies the first mistake that cost a decent amount for our customer. It sounds like this: quickly gash MVP. The customer wants to quickly see the result, but this means that we sacrifice good infrastructure, reliable architecture and a year later we came to the conclusion that our Front End architecture requires serious refactoring. About a few months. So we leaked 500,000 rubles.
Looking back, I can say with confidence that the first thing to do was take into account all the functionality that the customer wanted to see in the end, after a few years. So we could avoid architectural errors in the style of "this architecture does not provide for this." As a result, each major chip required serious refactoring.
In order to win the tender, our company sent developers who did not have experience in designing large applications and reliable extensible systems. Clear business, the tender is not an order, and nobody wants to scatter good personnel. But the lack of a technical architect at the (class level) led to the fact that our application turned into spaghetti code and stopped satisfying SOLID requirements. And here lies the error of each customer. It is not possible to maintain a constant pace of development without increasing team resources. The Agile principle “Investors, developers and users should be able to maintain a constant rhythm indefinitely” only works in case if the requirements were known and worked out from the very beginning, the entire set of functionality, a reliable and extensible architecture was designed (in a word, if each class was thought out taking into account the final functionality of the system) and the processes are clearly set. And this had to be done in MPV before sawing the product. Otherwise, with linear time, the complexity of the application grows exponentially. This means gash feature in a year will cost O (e (N)) more expensive than at the beginning.
In our team, the only designer was a remote employee. It was a serious mistake. A remote employee always lives his own life. He draws a design for himself, beautifully and well, the customer is happy. But all these charms ultimately boil down to the fact that on the same logical forms we have N different styles and layouts. From the very beginning, it was worth putting a requirement: stylize a certain framework (we had Ant Design). If something is not there, do what is there. The customer thought React was a block constructor. And he still does not understand why we are sawing primitive forms for 4 days. React is a constructor, but only if at the very beginning of development we have a set of similar reusable components (UI framework). A designer without layout experience will never do this himself. The developer will never tell the customer about this. This should be followed by the leader. So the leader of the Front End team should be the Front End developer in the past, and not the Back End as always. Therefore, we come to the conclusion that a fully-functional Agile team should include a competent leader in each of its areas of work (FE, BE). These leaders must have strong Soft skills in order to convey to the customer what I am trying to describe in this article. And this is very, very difficult. These leaders must have strong Soft skills in order to convey to the customer what I am trying to describe in this article. And this is very, very difficult. These leaders must have strong Soft skills in order to convey to the customer what I am trying to describe in this article. And this is very, very difficult.
When we released the first release, we realized that something was constantly breaking on the very last day before the demo. Throughout the year of development, each release branch turns into a hellish set of crutches (turn it off, remove that) which then magically end up in the develop branch. And there is a series of commits (turn this on, turn it on). After a year, we came to the conclusion that we need to have a clear branching policy. But most importantly, a responsible person who would eliminate the existing chaos. This meant: either to moderate the chaotic desires of the customer, or to moderate the chaotic bugs, or on each stand to have its own configuration disabling some kind of graphic features or buttons. Wrapping each button in an if statement is crazy. We have come to the conclusion that we need a plug-in feature-modular Front End architecture (disable - enable). I have been thinking for a long time how to achieve such an architecture. But one thing I understood for sure. We needed a full context. So the js-beans library was born (https://www.npmjs.com/package/js-beans). Each stand had its own json context. Plug-ins were collected in a chain (chain) through the Proxy pattern. So, for example, we had a data source as a separate bin, and various transformations were done as optional Proxy bins replacing this bin, but injecting it into itself. For example, if you need to scale the data model for testing FPS performance, I simply add the line to enable the scaling plugin in the json file. Something broke on the production, but it doesn’t play locally, I turn on the logger with one line without rebuilding the stand (the stand takes about 20 minutes, and a dozen stands are not always enough for everyone).
As time passed, the stands were turned off for a week. It was impossible to develop the front locally. We have not provided for autonomous architecture on the mokas. I had to gash it through the pain with a creak. Looking back now, I would have done it at the very beginning. But we had MVP, and we were forced to write code without deep engineering. But the customer considered us professionals, and thought that we should immediately write code without errors. Here is the following error. The name of the company does not speak about the professionalism of the team. The professionalism of the team is determined by the professionalism of the team leader. If there is no technical leader in the team, in a year your project will come to a standstill. So you merge a couple more millions.
We had a remote architect. But only one thing was known about him: he is. The last stage of development of the leader according to Vladimir Tarasov. In this our architect achieved perfection. Mistake number N: you do not have a technical architect who designs the system at the class level. You do not have a person to ask for help if you are at a standstill. Ask for help from other more experienced teams, the customer told us. But for some reason, the other teams never had time to help us. Our PR has been hanging for the second month. I sincerely hope that there is a brave man who will apprun him. As a result, life has rewarded our code with a rich abundance of paranormal phenomena in the form of magic and sets of crutches for all occasions. Only one was missing. Special Magic Annotationsand @Kostyle. Good idea for the next ES.
We decided that more middles and fewer men were more profitable for the project. Now we think differently. If you have a small budget, you need to hire the most expensive specialists. If you, like ours, have no budget problems, you can safely save on specialists and turn Code Review into a battle of psychics.
We thought we would meet the quarterly deadlines. Now we think differently. In short, for good, we need to rewrite the project. And preferably from scratch. I hope our customer will never know about it. After all, we just recently had a gorgeous team building)
We decided to play around with new technologies in which we had little expertise. They were recommended to us. Of course we wanted to gain experience. Now I think that it would be better to use only those technologies in which I have experience.
We gave estimates based on an 8-hour working day. In reality, estimates should be given on the basis of a 4-hour working day. Why doesn’t anyone include tea, telling interesting stories, searching for a toilet on the navigator, talking on the phone, correspondence, studying new technologies and, most importantly, enthusiastic disputes within the team. The latter is probably the most inevitable, and the most expensive. Although, to be honest, for Open Space you still need to throw a couple of hours. Constant talk terribly reduces concentration. Blessed is the customer who understands all this!
Our estimations were exhausting and turned into a tedious technical polemic anyway. The effectiveness of the rallies was minimal. But we found a solution: delicious pizza. When a delicious smell irritates the nose, a person begins to express his thoughts more clearly.
In the beginning we had one small team, then one big team. Planning took 2-3 hours. Standup 30 minutes. For what I respect our PO, it is because he decided to divide it into many small ones and to allocate his own mini PO in each of them. This was probably the best decision in the history of our project.
From the very beginning, we did not have time to write tests. After half a year, we came to the conclusion that they still needed to be written. But we still do not find time for this. Too much higher priority technical debt has accumulated. Do not save technical debt - this is utopia. He will always be.
My personal subjective conclusions:
- If your developers do not understand what IOC for FrontEnd is for, then most likely when they understand it will be too late.
- If your developers do not understand why FrontEnd needs knowledge of OOP, then your code can hardly be supported.
- Less expensive specialists are better than more more profitable ones.
- If you have an architect, most likely you need one more.
- If you are sawing MVP, finish it and change the project.
- If MVP has already been recorded before you, do not go to this project.
- If you gash MVP and do not want to leave, most likely you will change your mind.
- If you zapilili MVP and want your project to survive, rewrite it from scratch.
- If you show this article to a customer, you will most likely get fired.
- If you work on Agile, most likely you understand me.
You are unlikely to avoid all these problems even after reading this article. My goal is to show you that this is inevitable. And no matter how hard you try, you will never have ideal conditions. So just be prepared for it. And before dismissal, you can safely show this article to your customer. Let him be morally ready for this.
PS: Maxim, if you ever read this article, know everything that I described is completely fictitious and has no resemblance to our project) But all this is not important, because today I am going on vacation. The first vacation in a year of painstaking irregular work! (as FE lead).