Agile from the point of view of the programmer
Recently I came across an interesting article "Agile is bothering me, and I want to talk about it . " It talks about tuning this process from the point of view of the manager.
I 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 have been working as a programmer for 9 years. During this time, I tried myself in 7 companies from completely “non- productive ” to certified SMMI level 5 (who knows what it is, do not hold back a smile)). With this company with the most “rigorous” process in my life, I will start ...
2008. Motorola company. I simultaneously completed my studies at the institute and had 3 years of experience working in a specialty behind my back. In general, he considered himself an experienced programmer. And here for the first (and, I hope, last) time, I came across a truly “inflexible” process. Motorola was very proud of its CMMI Level 5 certified software development model and its own 1986 Six Cigma production management concept .
I fully admit that for the development of iron, that process could be useful. It is possible that space exploration software is also worth creating under something similar. But when writing several simple client applications required documentation several times more than code, then this is completely absurd. I felt like a real scientist. Only instead of investigating the curvature of space-time, he wrote multi-page documentation about the implantation of a tiny JSR. Which, unfortunately, did not allow sending the rocket to Mars, but only implemented the API to get the battery level of the phone.
Then I thought that perhaps this is necessary in large companies and hoped that this would at least achieve high quality products used by millions of people. But the longer I worked on such a process, the more I realized the futility of all these documents. At least, because most of them have never been read by anyone, and a lot of time was spent on creating and a multi-level review. At the same time, this did not positively affect the quality of the code.
And then Motorola ran out of money and it came cost saving. The authorities reported to us how much money they managed to save 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, we 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 were not subjected to a multi-stage review. - We began to monitor the quality of our and other people's code. A
lot of time was freed from strict documentation and now we mainly began to devote time to the code and its quality. At the same time, the code should have been born also self-documenting. - Daily stand-ups began.
Finally I found out who works in my team and what they do. - The purpose of the work has changed.
Focus from documentation and many formal processes suddenly shifted sharply to the quality of the code and the speed of product development. - The development speed has changed
Before that, I could not imagine that even in a large company it is not necessary to work for a whole year, so that your 100 lines of code reach production. It turned out that a couple of hours is enough for this. - Agile in design tim :))
Designers also arrived with “flexible” methodologies. They began to change designs and concepts every sprint. In general, the life of developers and the manager was greatly complicated. - Work time
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.
There were many differences with her too:
- Means of distributing efforts within the team
I liked that with daily discussion and re-sticking of pieces of paper, the whole team is fully aware of each success (with the sincerity of the latter). Thus, the Stakhanovites could easily be sent to help the laggards. - Development time
When there was no process, then there was no clear release time. Rather, it was initially heard, but for lack of means of delegating efforts within the team, it was rarely observed. Or a low-quality product was given up without hesitation. - You are no longer the master of your feature.
If I said earlier that I would do such and such functionality in a product and deal with it, sometimes, Pi more than I planned, now it has become impossible.
Firstly, while planning, someone could now say that he will make this functionality faster and then I lost the opportunity to do it.
Secondly, even with the feature “winning”, I worked on it only while everything was going according to plan. With delays, 2 options appeared: an assistant / successor stood out or the feature was transferred to the next release. No one tried to shift the end time of sprints. - There was a reason to do it faster (for extroverts)
I ’ll say straightforwardly - I like it when people praise me and therefore Agile greatly contributed to the desire to do everything faster and better than possible, because everyone now saw my progress every day. - There were terribly boring and awkward 15 minutes in front of everyone every day (introverts)
I also heard this and mostly from introverts - they really were really uncomfortable at stand-ups.
The result of the transition to Agile
Our team developed the myFaves application . It must be implemented for each phone platform that the company wants to sell through the T-Mobile mobile operator. Thus, this application was developed dozens of times within the walls of Motorola. But it was our team that managed to meet the shortest time in the history of the company. The quality was also at the highest level, as a result of which the operator accepted our product at the first test cycle. At the same time, the development was carried out by a team learning this system in the process of creating the product. Yes, and Android was still very raw then. In addition, some like me learned Java itself.
Further thoughts
After that, I had the opportunity to learn different types of processes, working in Korea in Samsung, then in domestic and American companies. But for now, everything has returned again to Agile in my current Netflix company.
Agile Pros
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 indispensable advantages of this process:
- Motivation
Sometimes it’s hard to get 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 the stand-up comes to the rescue!
As Freud said: "all our actions originate in two motives: in sexual desire and the desire to be great." It is this desire that makes me seriously prepare for every stand-up. I even noticed that in the days when there will be no stand-up, it’s 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’s very good when the process allows you to exclude some tasks from this sprint right in the course of its implementation or to redistribute resources if it turns out that there was an error in the initial estimates. - Intra-
team synchronization I like that the team gathers every day and finds out who is doing what now, plans to do what problems have been resolved and which ones are. Before my eyes, often deadlock problems were resolved in a few minutes, when the whole team after the stand-up (or sometimes right in time in violation of ideology) got together and thought about the problem alone. - Quality of the code
When the engineering person of the product is not some documentation, but the code itself, then the attitude to it is formed much more serious. I agree that in many methodologies, code is given very great importance, but few in which code is almost the only result of the work of an engineer. And git blame him then a judge. - Review
I like that the reviews in this process are quite informal and really allow you to concentrate on improving the code. At the same time, I personally am most impressed with the interpretation of Agile, in which the code review is conducted 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 with it, then it is much easier to catch errors in reasoning or see ideas for improvement.
Cons
Also striking is the imperfection of this process:
- Changing requirements
With constantly changing requirements, it is difficult to comply with the initial terms for the implementation of the product. And sometimes it may even turn out that it’s not possible to complete everything in the allotted time and that something else needs to be urgently changed. - Canceled features
When a programmer is told that your efforts were in vain and the realized feature was decided not to be included in an upcoming release, this rarely encourages him ... - Design Tim
A flexible process for designers often becomes a hell for programmers. Often you have to rewrite the code, to explain that this will not work quickly, and this change generally makes all the previous work in vain. IMHO, it is better for them to have a red light before starting to implement features. - Loss of time during stand-ups
It is rarely possible to keep within 15 minutes and most of the time is sometimes useless for many participants in standing. - Bad code alone can do much harm
. Unfortunately, Agile is very sensitive to the quality of employees and their code. In this process, careless programmers can make life difficult for the whole team. - Personal life
Work time usually also becomes "flexible." And under the hour it is very difficult to clearly predict what time it will be possible to free oneself and whether you will have to finish something urgently on the weekend. - Unit test driving development
IMHO, Agile has a number of ideas that seem utopian to me. Spend a lot of time developing unit tests and then write code so that they complete successfully? Perhaps there are projects where this makes sense. But what I met usually required months of programmer work to develop unit tests that did not cover 5 minutes of real testing by a professional. Some minimal set of automatic tests is probably necessary, but developing the whole product from them, IMHO, carries a lot more time than benefits. - Pair programming ...
This method really helped me 3 times in my life. But this should be really demanded by this task (from experience, usually with some kind of complex bug), and not used as a method for the sake of the method.
In conclusion, I recall Winston Churchill’s famous phrase about democracy, which can also be applied to Agile:
“Democracy is the worst form of government, with the exception of all the others that have been tried from time to time.”