How to stop catching eggs in a hurry, incidentally dropping deadlines? Which toolchain to choose to destroy several tasks at a time? We will reveal all this in our article.

Trying to catch all the eggs

In those days, when our company was only born in the sun-filled glass womb of the office, and there were only three people in the team (a manager and two developers) full of enthusiasm and coffee, we had absolutely no project management methodology and approaching the work on the principle of “one person - one project”. At the same time, it was not even the case that the developers, interacting within the same task, merged separate pieces of code among themselves, and the entire landscape of the developer environment hung on the developer’s own machine. As a repository and version control system, we then used SVN , which at that time looked more like a folder with zip archivers. Despite the fact that SVN is one of the largest version control systems and has a corresponding community, its functionality suited us only in terms of saving the code, otherwise everything was somehow a bit poor: there was no local version and no possibility to merge the code. Therefore, we began to look for something more suitable for our appetites - the development of a working process began. The first thing that needed to be addressed was the issue of planning and setting tasks, as well as their distribution relative to each other, in order to move away from monoprojectness to joint development and maintaining deadlines. At that time, the only planning was the meeting with notebooks. With this approach, to the efficiency and efficiency was like to the moon on the Cossacks, someone had time to note everything, someone scored or forgotten. As a result, people left the meeting without a clear understanding of what and how to do it, with a lot of information in their head and with a pair of scrawl in a notebook.

We select the tulchain

The first step in reducing the workflow entropy was to create a normal repository, to collaborate on projects and connect individual parts of the code. We threw out an old SVN and raised GIT on our CEO’s local machine. To view and connect the code using simple console utilities. It was not very convenient, but at least allowed to maintain order and transparency of changes in the project.
')
We still had problems with planning, and as a result, with keeping the deadlines. For this, it was necessary to find a means of decomposing tasks and displaying the status of their execution. An attempt to solve this issue was the use of the application for project management RedMine, from which the active benchmarking of the toolchain began. The utility was well suited for developers (project management capabilities, forums, error tracking), but unfortunately, it was very hard for managers. Developers constantly had to process all the information (merqurequests, pullrequests, etc.) from WOS, and enter it into the RedMine program, so that managers could track the degree of completion of the task. In addition to this, there were not enough additional project management functions, so we began to glance in the direction of FengOffice .

The tool had a fairly wide range of functionality, making it possible to dream up about combining communication and planning tools like the Gantt chart into a single working system. However, with all the equipment of this product, developers had to manually close tasks, simultaneously keeping statistics on themselves, since there was no automatic synchronization of tasks performed. In addition, the implementation of the internal chat, was more like the similarity of the old version of ICQ, than the normal corporate chat, but for us this moment was very important.

We understood that in order for the whole mechanism to work smoothly, simple meetings are clearly not enough. It became necessary to select operational tools for establishing short communications that were needed even for people sitting next to each other in the same room. There are two points: the first - if you hold short conversations in the usual format, they will take too much working time, which is hello to the collapse of all deadlines and a hard time schedule, and the second - if you make a minimum of short interactions, this will lead to loss close communication between team members, inconsistency of their actions, duplication of code and other troubles. Therefore, we came to a simple solution - to translate micro-meetings into a team chat, which allows you to constantly communicate without distracting from the workflow, coordinate the actions of developers and avoid re-performing the same tasks, as well as disputes about who performed the task better. The solution may seem obvious and trivial, but the point is not in the means of interaction, but in the approach and quality of using the tool. The question was how to turn chat from a place for flooding and intoxication, into a partial replacement for meetings and personal conversations.

Meanwhile, the usual GIT was not enough, there was a strong shortage of the web interface. In the menu, we had two options: a private repository on GitHub and a repository on GitLab. GitLab is free - and they took it. In addition, he has a cool, friendly community. In addition, GitLab already had a built-in task scheduling system and provided a convenient interface for all the rediscovers. If you worked in a team, you probably know how important it is to quickly get approved merzhrekvest. Eventually, we buried FengOffice and settled on GitLab. Especially at that time, we already used Slack as a command chat, and given the fact that GitLab had planned for mutual integration with Slack, and all this stuff was also free, the choice for us became more obvious than ever.

Books did not lie

Then came the moment when it was necessary to choose the methodology most suited to our realities for flexible project management. We stopped at the two most developed and popular approaches: Kanban and Scrum. The initiative came entirely from our CEO, Ilya Bykoni, who spoke with promethean fire in the eyes of the team about the upcoming changes. But to his great surprise, the team, at first, met the innovations, as the Spartans met Xerxes, with the fierce persistence of conservative copies. What can you do, illusions, illusions, because in the books they warned ... An interesting fact was immediately noticed that a negative attitude to new approaches does not correlate with the adequacy and ability of people to work. Even the young djunas, who should, in theory, easily pick it all up, resisted, arguing that: “they'd better program 15 minutes than spend this time on the next daily”, “why planning at all, if deadlines they are not executed or are executed, but with deviations ”,“ why should a front end developer listen to about the backend ”, etc. The fact is that the Agile-approaches methodology implies a style of work that doesn’t work in the old manner on Atlanta’s shoulders of a strong development and get to the project on his skills, and in fact many people are used to working, therefore such changes become painful.


When we began to introduce Agile into work, we fully felt the value of short and high-quality communications. It often happens that when the input of an RnD department receives similar tasks from several sources, project managers cannot catch duplicates. And it is here that short-term interactions and online meetings, which completely protect against such problems, begin to play a large role, by identifying points of contact between the developers of different teams. There is another interesting point - most programmers are introverts, that is, any communication is a microstress, especially when it comes to meetings in large teams, where a person has to speak to a wide audience of diverse professionals. And many people, under the fear of such discomfort, do not realize that the alternative for such short meetings may be even more unpleasant than the Daily. This will be replaced by constant communications throughout the day, in attempts to bring work to a manageable process. For ourselves, we concluded that Agile takes into account the introversion of developers and reduces the discomfort associated with the need to communicate to a minimum. Of course, for young employees of the company, in any case, this will be stressful for a while, until he delves into the specifics of his work and becomes more familiar with the team, so the more friendly and more efficiently built the Agile culture in the company, the faster the adaptation process will end.

One stick - painful, many sticks - deadly

One of the key motivational aspects of the flexible approach is that people get used to minimize their problems and bugs. The fact is that if you take a standard vertical management structure, the developer is responsible for his shoals in front of the immediate superior, who punishes and “strikes the head with a stick” if the employee is facacit or “strokes the head” if everything is done clearly. That is, in a vertical structure, a person has the option of rebounding at the expense of personal relationships or “delicious cookies”. In Agile, teamwork is built horizontally, which means a person has to report to the entire team at daily rallies. He just stupidly does not have enough money for such a number of "cookies". So you have to get used to the fact that your mistakes will be reviewed by your colleagues, and either you will be on a horse and they will strew rose petals on you from the praise of your professionalism, or you will be under a horse ... In any case, this is a strong pumping of the person’s personal skills, and if the atmosphere in the firm is warm enough, then the person begins to slowly open up, making an increasing contribution to the ecosystem of his department and the company as a whole. We also experienced the filtering effect of Agile on personal experience, more than once confronted with a situation where objectively weak developers do not withstand constant analysis of their mistakes, and ultimately simply merge if they realize that they lack internal motivation and strength. to go from the status of bagodela to the status of bogakoda.

Summarize

It should be noted that the process of launching Agile machines was quite long and very tense, “it was not without violence” - initially the people had to be driven to meetings and deeds with a stick, so that people somehow began to designate their position on the tasks they were solving. Although we constantly have to “crawl under the hood” and fiddling with the “engine”, wiping our hands in fuel oil, but it is worth the feeling when the team is gaining momentum and rushing forward, collecting checkpoint for checkpoint. We do not stop our evolution for a second, we are always in the status of eternal freight forwarders, we are constantly exploring new and refining existing management models and interactions between employees. One thing we understand for sure - where there is no movement and struggle, there is no life. As the Zen monks say: “Reached the top, continue climbing ...” Good luck to everyone in your ascents and let everyone go towards their summit, no matter what!

PS:

Here is a sample list and timing of the stages that we have passed:

1. Planning formation ~ 4 months
2. Work with short communications ~ 1 month
3. Finding the right toolchain and working out the workflow ~ 2 months
4. Methodology selection ~ 2 months
5. Scrum introduction to workflow ~ 8 months

And here is a small selection from our CEO:

1. “Comprehending Agile” - Andrew Stellman and Jennifer Green
2. “The Way of the Scrum Master” - Zuzana Shokhov
3. Scrum Revolutionary Project Management Method - Jeff Sutherland
4. “Kanban Alternative Path to Agile” - David Anderson
5. “At the head of the transformation. Applying Agile and DevOps principles across the company. ”- Harry Grover and Tommy Mouser