Agile from the point of view of the programmer

I recently stumbled upon an interesting article, “Agile bothers me, and I want to talk about it . ” It tells about the tuning of this process from the point of view of the manager.
I also wanted to describe what agile is for me as a programmer. Without manifestos and big words. And what is special about it compared to other methodologies.

Prehistory

I work as a programmer for 9 years. During this time, I tried myself in 7 companies from completely “ process- free” to certified CMMI level 5 (who knows what it is, you should not hold back a smile)). With this company with the most "strict" process in my life, I will start ...

2008 Motorola company. In parallel, I finished my studies at the institute and had 3 years of professional experience behind my back. In general, I considered myself an experienced programmer. And here for the first (and, I hope, the last) time I ran into a truly “inflexible” process. Motorola was very proud of its CMMI Level 5 certified software development model and its own production management concept from 1986 Six Cigma .
')


I fully admit that for the development of iron that process could be useful. It is possible that software for the conquest of space, too, should be created under something similar. But when writing simple client applications required documentation several times more than the code, then this is completely absurd. I felt like a real scientist. Only instead of researching the curvature of space-time, I wrote multipage documentation about the implication of a tiny JSR. Which, unfortunately, did not allow to send a rocket to Mars, but only implemented an API to get the battery level of the phone.

Then I thought that perhaps it was necessary in large companies and hoped that at least this would attain the high quality of products that millions of people use. But the longer I worked on such a process, the more I realized the futility of all these documentation. At a minimum, because most of them have never been read by anyone, and a lot of time was spent on creating and multi-level review. At the same time, this did not have a positive effect on the quality of the code.
And here Motorola ran out of money and it was cost saving. The bosses told us how much finance was saved by removing disposable spoons from company canteens around the world, but this did not stop there. Our development process has been dramatically transformed into Agile.

Differences from the "inflexible" Motorola

What changed? Everything.

The main differences:

• We stopped writing documentation.
  Instead, they began to insert comments right inside the code and Javadoc for classes and public methods. At the same time, it became clear for whom we are writing this (for our team). Also, these comments are not subjected to multi-stage review.
• We began to monitor the quality of our and someone else's code.
  A lot of time was freed from strict documentation and now they mostly began to devote time to the code and its quality. In this case, the code should have been born also self-documented.
• Started daily stand-ups
  Finally, I found out who works in my team and what they do.
• The purpose of the work has changed
  The focus from documentation and a variety of formal processes suddenly shifted dramatically to the quality of the code and the speed of product development.
• Changed development speed
  Before that, I could not imagine that even in a large company it was not necessary to work for a whole year, so that your production would reach 100 lines of code. It turned out that a couple of hours is enough for this.
• Agile in design tim :))
  The designers have also come "flexible" methodology. They began to change the designs and concepts of each sprint. In general, they have greatly complicated the lives of developers and managers.
• Working hours
  No 8 hours ... alas, but I began to work more. Basically, however, on their own initiative =)

Differences from processlessness

At the same time, I recalled my first company, which did not have a process at all.
She, too, had many differences:

• The means of distribution of effort within the team
  I liked that with daily discussion and gluing pieces of paper, the whole team is fully aware of the successes of each (with the sincerity of the latter). Thus, the Stakhanovists could easily be sent to the aid of the laggards.
• Development time
  When there was no process, then there was no clear release time. Rather, it was originally delivered, but for the lack of means for delegating efforts within the team, it was rarely respected. Or upward without any constraint, a poor-quality product was issued.
• You are no longer the master of your feature.
  If earlier I said that I would make such and such functionality in a product and dealt with it, sometimes Pi times more than I planned, now it has become impossible.
  First, even when planning, someone could now say that he would make this functionality faster and then I would lose the opportunity to do it.
  Secondly, even with the “winning” features, I was engaged in it only as long as everything went according to plan. In case of delays, there were 2 options: the assistant / successor or feature was highlighted and was transferred to the next release. The end of the sprints no one tried not to move.
• There was a sense to do faster (for extroverts)
  Frankly speaking, I like it when they praise me and therefore Agile has greatly contributed to the desire to do everything faster and better than possible, because everyone now saw my progress every day.
• There were terribly tedious and awkward 15 minutes in front of everyone every day (introverts)
  This I also heard, and mostly from introverts - they really were really not at ease on the stand-ups.

The result of the transition to Agile
Our team developed the application myFaves . It must be implemented for each platform of the phone that the company wants to sell through the mobile operator T-Mobile. Thus, this application has been developed dozens of times within the walls of Motorola. But it was our team that managed to meet the shortest possible time in the entire history of the company. The quality also turned out to be at the highest level, as a result of which the operator accepted our product on the first test cycle. In this case, the development was carried out by a team who studied this system in the course of product creation. Yes, and Android was still very raw. In addition, some people like me were trained in Java itself.

Further thoughts

After that, I happened to learn more about different types of processes, working in Korea in Samsung, then in domestic and American companies. But for now, everything has returned to Agile at my current company Netflix.

Pros Agile
At the same time, I fully understand why the whole world is switching to flexible methodologies. And for me as an engineer there are a number of irreplaceable advantages of this process:

• Motivation
  Sometimes it is hard to force yourself to work. I know that no one is following me, everyone is happy with me and therefore there is a great temptation to suffer garbage, reading useless news or hanging out on social networks. And here stand-up comes to the rescue!
  In the words of Freud: "All our actions originate in two motives: in the sexual attraction and the desire to be great." It is this desire that makes me seriously prepare for each stand-up. I even noticed that in the days when the stand would not be, it is more difficult for me to get together and do the planned amount of work.
• Flexibility
  Unfortunately, in programming it is sometimes difficult to accurately predict how long a particular task will take. And it is very good when the process allows to exclude some tasks from a given sprint right along the course of its execution or to reallocate resources if it turns out that there was an error in the initial estimates.
• Command synchronization
  I like the fact that the team meets every day and finds out who is doing what now, what it plans to do, which problems have been solved and which are. Before my eyes, often dead-end problems were solved in a few minutes, when the whole team after the stand-up (or sometimes right during the violation of ideology) got together and thought about the problem of one.
• Quality code
  When the product’s engineering face is not some kind of documentation, but the code itself, then the attitude towards it is much more serious. I agree that in many methodologies code is given a very great importance, but little in which code is practically the only result of the work of an engineer. And git blame him then judge.
• Review
  I like the fact that the review in this process is rather informal and really allows you to concentrate on improving the code. At the same time, I am personally most impressed with the interpretation of Agile, in which code review is carried out in person. I understand that this is not modern and not always possible (especially when some work remotely). But if you analyze not just the code, but also hear the opinion of the author: why he did just that and what he wanted to achieve, it is much easier to catch mistakes in reasoning or to see ideas for improvement.

Minuses
Also, the imperfection of this process is striking:

• Changing requirements
  With constantly changing requirements, it is difficult to comply with the initial terms of implementation of the product itself. And sometimes it may even turn out that it is not possible to accomplish everything in the allotted time frame and there is still something urgently needed.
  
• Canceled features
  When a programmer is told that your efforts were in vain and it was decided not to include the implemented feature in the upcoming release - this rarely contributes to his enthusiasm ...
  
• Tim Design
  The “flexible” process for designers often becomes a hell for programmers. Often it is necessary to rewrite the code, to explain that this will not be done quickly, and this change generally makes all previous work in vain. IMHO, it is better for them to have a red light before starting the implementation of features.
  
• Loss of time during stand-ups
  Rarely it is possible to keep within 15 minutes and most of the time sometimes it turns out to be useless for many participants of standing.
  
• Bad one code can hurt a lot
  Unfortunately, Agile is very sensitive to the quality of workers and their code. In this process, careless programmers can make life too difficult for the whole team.
  
• Personal life
  Hours usually also becomes "flexible." And under the hour, it is very difficult to clearly predict how much time you will be able to free yourself and whether you will have to finish something urgently at the weekend.
  
• Unit test driving development
  IMHO, there are a number of ideas in Agile that seem utopian to me. Spend a lot of time developing unit tests and then writing code to complete successfully? Perhaps there are projects where this makes sense. But what I encountered usually required months of work as a programmer for developing unit tests that did not cover and 5 minutes of real testing by a professional. Some kind of minimal set of automatic tests is probably necessary, but to develop an entire product for them, IMHO, is much more time consuming than good.
• Pair programming ...
  This method really helped me 3 times in my life. But this should really be claimed by this task (by experience, usually by some complex bug), and not used as a method for the sake of a method.

In conclusion, Winston Churchill's famous phrase about democracy comes to mind, which can also be applied to Agile:
“Democracy is the worst form of government, with the exception of all others who have been tried from time to time.”