📜 ⬆️ ⬇️

Un-FuckUp-able Development Protocol (UDP)

Recently, after the next Team Building, I received from one Colleagues-Graphomane a parable about the big button “to make everything good”. He had previously indulged in the invention of bicycles, but this time the design seemed to me to be extremely successful. To whom it is interesting - I ask, I invite under the cat. With his permission, literally:

In this siesta on the veranda almost no one smoked, because everyone went to the next two-day SCRUM- training. Johnny looked tiredly at the audience: Demo and Varya. They, too, were not thrilled by what was happening, it was too hot and stuffy, summer in the Valley was in full swing, and it seemed that it was even hotter on the street than in Task Tracker.



')
Things were not so hot, all three knew it. They all, in solving their problems, depended on those people who had gone to learn how to organize the development process. The real work that had to be done yesterday, today was postponed to that invisible moment in the future, when the rest of the “fighters” return from the front of the struggle for the elimination of illiteracy.

- Do you guys want me to tell you a fairy tale about programmer's Paradise? - asked Johnny, shaking off the ashes after another puff.

Varya and Dema nodded sadly, but tried to smile. Then Johnny pulled his pipe out of his pocket, and, explaining that it would be a Long Run Story, began to slowly dive into the clubs of Balkan Delight (a sort of tobacco).

Of course, no good fairy tale can do without prehistory. To any worthwhile movie sometime prequel will be removed. And, of course, Johnny, like any good storyteller, could not begin the story without the introduction.

The BIOS initialization gave the listeners information about the hardware:


Well, and other IO and peripherals, such as "third-party" testers, layout makers and designers, with which everyone agreed. Still, they agreed that the display is a SCRUM board, and the operating system is Linux, that is, the Open Source movement is concrete and breakthrough innovations in the IT sphere in particular.

Management, of course, attributed to the application software - Task Tracker and Cron . Power supply, for obvious reasons, was replaced by the concept of Cash Flow from Customers and Clients. After all, the computer doesn’t matter where the energy comes from, it’s just important to make calculations, so the reality of the presence of energy and the source of its occurrence is not disputed either. The case, in their case, of course, was a custom one, with water cooling (pool and sauna) unlocked by a clock frequency generator (any nishtyaki, from a hookah and beer on the veranda, where it was not forbidden to take a laptop, to the gym in the basement of their mansion). UPS in the form of ugarshie corporate parties and other significant indulgences in the presence of the time schedule as well, of course, was designated as an integral and very necessary device.

Having missed the remaining irrelevant moments of the description, Johnny summarized:

- So, we have 50+ people who have been breathing this or that development methodology for a couple of years, but at the same time, some FuckUp happens regularly! We started with self-organized chaos, then we were 10. Then we became 20, and 30, and 40, and our “ Waterfall Model ” (development) came. And, when suddenly everything turned out differently, as we used to, we began to make SCRUM. And, it seems, everything is fine with us, stable salary, excellent management, satisfied users regularly make a lot of money, but still see problems? - fired Johnny.

There really were a lot of problems. Starting from the banal context switch, despite all the cautionary limitations of all the mentioned methodologies, and ending, stupidly, the lack of general communication coherence.

Everyone knew that each of the developers regularly receives not only bonuses, but also “one cap” for the packs. What testers do not “test,” and the junas are not juniors. The designers didn’t have enough “food”, since the designers were overloaded with micromanagement, they were flooded so that the developers had to wait for them. About the support - these brave guys - the mighty Vikings headed by Thor himself could only be pleased to write to panigiriki and obituaries. And the first association to the management of all was unanimously the morning alarm clock, always ringing at the wrong time. Perhaps, we will not continue, you yourself know everything about everything, it is everywhere, not only in IT.

- Still, they understand that regardless of the methodology of the development process, our tasks will not go anywhere? Their quantity and quality will remain unchanged?

Everyone still understood that neither Scrum nor Waterfall, and nothing in this universe would cancel common sense. What if there is a fire in the production - it must be extinguished. That if something is missed and it is urgently needed - there will be an interruption and a fallout from the context, this is natural. That it is impossible to refuse unreasonable communication with the management, and no SCRUM will save you from a sudden “miracle idea”. That technical debt is not going anywhere, and maintenance tasks will be more and more, as long as the number of users grows. Namely, ensuring this growth is the key task, no less important than the development of new product features. And that neither scrum, nor kanban, nothing will save from all this mess, since the system cannot be closed, it breathes, it is a living organism.

- Thus, we all want to grow, develop, write code , but so that all this will continue to be as interesting as now, do we need some new “paradise”?

Everyone nodded. Johnny lit up his long-gone pipe again.

“We own a team that needs Re-Engineering !”

Having approved this meaningless thesis, Johnny looked down upon others, there were more of them, and Denis and Vasily, as usual, drank at dinner, joined in. (No one, of course, remembered how to really magnify him, a genius from the east, a cross between a Hindu and a Chinese, with kripova hair - what else can you say - Vasya, he, of course, was not offended).

- Still remember the difference between TCP and UDP ? - Johnny explained that this is metaphorical in the context of a fairy tale, and everyone agreed that UDP is better for streaming, but does not guarantee delivery.

Then it became clear to all that the management wants us to combine both UDP and TCP, that is, to guarantee delivery for high speed delivery of new features.

- We have a team of developers, which, so it happened, shared on the team. Each team is led by Team Lead, and almost always is one of our Senior Developer. We have a CEO and CTO. Also here we have all the other incomprehensible people who constantly interrupt the process and make their own adjustments. And, here, it seems that all developers seem to be constantly busy with development, but someone always stands idle or overloaded and / or simultaneously busy with solving any type of interruption: from management, from support, from technical debt. That is, we are constantly dealing with some kind of FuckUp, which is happening because everything just happened. We seem to have a process, but it doesn’t solve the problem that when you want to write code, you don’t, and when you can, you don’t want, because you are tired, not yet, and you can solve other “important” tasks . Someone went to the rally, some went for tea, and the pilaf would not be cooked to the desired condition.

- Well, what do you suggest? - Finally, the most inexperienced and impatient Vasily finally voiced the long-ringing question in the sultry air.

- I propose to combine the teams in a different way. Team Lead cannot lead a team. That is, everything will be as before, only the team will be managed not by Senior Developer, but by someone more or less competent from Middle or even promising Jun'ov.

What is it?

And so: we are rebuilding the management process to other areas. See for yourself, the performance of any generator is much higher than the performance of the middle or joon. It is clear that not all seniors are eager to write code, but, anyway, then the conversation is not about those, but about the general mass. Normal seigneur, which we, thank God, lacks - always wants to issue a code every day. Just because the more he has time for today, the more bonus will receive tomorrow. But almost no senor can afford it, since at least half of the time he is busy with all this micromanagement, from communication with team members, to communication with suppliers of requirements.

For example, we have a pool of highly qualified and competent specialists, let's review Senior Developer this way. Then we have less competent people who really want to “grow” and become more competent. But they constantly lack the time of the “elder” brothers, nor the respect of the management, nor, all the more, the understanding of the processes.

Of course, you shouldn’t neglect common sense, Senior - he’s also a Senior, who can lift a fallen server himself, whenever and in what condition You don’t wake him up. But he should not lead the development. He must develop, make decisions and take responsibility for their implementation. But Middle or experienced Jun should manage the process, simply because they can:


And then, in a year we will have not 8 Seniors, but at least twice as many. We haven't changed our perspectives for two years now. We are hiring seemingly excellent seniors, and the junas in the midles almost do not grow, and the middle ones almost do not grow in the seniors.

Remember! All the midles have their eyes burning when they come to us, and then they go a little different, and everything flows into this swamp. Tired seniors hang on them none of them are not clear tasks, and that in the end - the process barely crawls.

- Imagine, Dyoma, that you could work, namely, Work, write code, and not just sit on Skype, hourly on “Kodets” coming off, not 20+, but 30-40 + hours a week? You already work for 60+ hours just because somebody constantly pulls in your brain. And the work is worth it, but we need to do it today, the code is not waiting, you are responsible!

Of course, Dema could not disagree, for two weeks he had only seen his wife and daughter sleeping. He really wanted to somehow go home on time, sentimentality.

- Imagine, Vasya, that you would be the head of Dema, and not vice versa? You would all have argued, Maybe Anita from the accounts, finally you would have noticed? And there, you see, you would see the code of Dema from behind, and you would understand that there is no special signer's “magic” in it.

Of course Vasya's eyes lit up. He could not imagine it in the most optimistic dreams, lead the department! He knew exactly how to arrange everything, if he only had such subordinates as Dema, he would have decided everything for a long time.

- Varya, imagine that you could finally understand how all our technical process is organized, and your Testers would finally receive a quality code, and an increase in salary, because at the end of the week there would not be any new bugs released into production, but old, finally, could be corrected in time?

Varya beamed, as she understood what the problem was. She mainly worked with Aristarkh, the other hipster: “commander” of Front-End players. He was a very impressive personality, and his code was excellent. The problem was that he had no time to write it, and most of the problems were solved by his subordinates, and he didn’t even have time for a Code Review . Since he was almost the only person who understood the process of creating beautiful things “in the complex,” sometimes even the sales department contacted him directly, bypassing the entire process chain. It was the only person in the company who could understand the designer immediately, without asking again, and without specifying. Of course, his entire team prayed for him, but Varia suffered. She understood that half of his subordinates were waiting for him to pay attention to her, Varya, the bugs found.

Of course, that night, no one of them could sleep a wink, despite fatigue.
In the morning they met on the veranda and identified the desired new subordination and recaps.

By evening, the “memorandum” was ready, which they secretly pasted on the SCRUM board.
The memorandum was only the following:

Un-FuckUp-able Development Protocol (UDP)




And the QR code on the “quick” prepared document outlining the basic principles of yesterday's PR-company of John’s ideas.

***

Do you like my Story, man?

Of course, they had everything, and performance metrics, and Grades, and SMART, and so on, so important, that we all love so much. But we still understand what we want, right?

Sincerely Yours John ...

Source: https://habr.com/ru/post/307134/


All Articles