Late I came across an interesting article "Agile is bothering me, and I want to babble roughly IT . " It talks approximately tuning this process from the stand of the manager.
I wanted to describe what agile is for me as a programmer. Without manifestos and big words. And what is extraordinary about it compared to different methodologies.

Prehistory

I have been working every bit a programmer for 9 years. During this time, I tried myself in 7 companies from completely "non- productive " to secure SMMI pull dow 5 (who knows what it is, doh not hold back a smile)). With this company with the to the highest degree "rigorous" process in my life, I will start ...

2008. Motorola troupe. I simultaneously completed my studies at the institute and had 3 geezerhood of experience working in a specialty behind my back. In general, He considered himself an toughened computer programmer. And here for the foremost (and, I hope, last) clock time, I came crossways a truly "inflexible" march. Motorola was very proud of its CMMI Level 5 certified software development model and its own 1986 Six Cigma production management conception .

I fully admit that for the development of iron, that process could exist useful. IT is possible that space exploration software is also worth creating under something similar. Just when writing various simple client applications required documentation several times more than codification, then this is completely idiotic. I felt like a real scientist. Only alternatively of investigating the curvature of space-clip, he wrote multi-varlet documentation about the implantation of a tiny JSR. Which, unfortunately, did not allow sending the rocket to Red Planet, only only implemented the API to get the barrage fire level of the telephone.

Past I thought that perhaps this is necessary in great companies and hoped that this would at least reach high quality products used by millions of people. But the longer I worked on such a treat, the Sir Thomas More I realized the futility of all these documents. At least, because most of them undergo ne'er been read by anyone, and a lot of time was spent on creating and a multi-level review. Concurrently, this did not positively feign the quality of the code.
And so 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 approximately the world, but this did not stop there. Our exploitation process has been dramatically transformed into Agile.

Differences from the "inflexible" Motorola

What changed? Everything.

The main differences:

We stopped writing corroboration.
Instead, we began to insert comments flop inner 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). Besides, these comments were not subjected to a multi-stage review.
We began to monitor the quality of our and other people's code. A
batch of clock was freed from strict documentation and now we mainly began to devote time to the code and its quality. At the same time, the encode should have been born also mortal-documenting.
Daily stand up-ups began.
Finally I found out who works in my team up and what they do.
The purpose of the work has altered.
Focalise from documentation and many formal processes suddenly shifted sharply to the quality of the encipher and the speed of product development.
The evolution upper has denaturised
Ahead that, I could non imagine that even in a large keep company it is not necessary to work for a whole yr, so that your 100 lines of code contact production. It inside-out out that a couple of hours is sufficient for this.
Agile in designing tim :))
Designers besides arrived with "flexile" methodologies. They began to change designs and concepts every dash. Generally, the life of developers and the director was greatly complex.
Act time
No 8 hours ... alas, but I began to work more. Basically, even so, on their own initiative =)

Differences from Processlessness

At the same time, I recalled my initiative caller, 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 give-and-take and re-sticking of pieces of composition, the whole team is in full aware of each success (with the sincerity of the latter). Thus, the Stakhanovites could easily live sent to helper the laggards.
Development time
When thither was none procedure, and then there was zero open dismissal fourth dimension. Rather, IT was initially heard, but for lack of substance of delegating efforts within the team, it was seldom observed. Operating theatre a low-quality product was apt in the lead without hesitation.
You are none yearner 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 to a greater extent than I planned, now it has become impossible.
Firstly, while planning, mortal 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 active according to plan. With delays, 2 options appeared: an assistant / successor stood out or the feature was transferred to the next release. No one time-tested to shift the end time of sprints.
There was a reason to do information technology quicker (for extroverts)
I 'll say squarely - I like it when people praise Maine and therefore Nimble greatly contributed to the desire to practise everything faster and bettor than possible, because everyone now saw my progress every solar day.
There were terribly oil production and awkward 15 minutes before of everyone day-to-day (introverts)
I also detected this and mostly from introverts - they really were genuinely uncomfortable at stand-ups.

The result of the transition to Agile
Our team matured the myFaves application program . It must be implemented for each earpiece political platform that the company wants to sell through the T-Mobile mobile operator. Thus, this application was developed scores of times within the walls of Motorola. Simply it was our team that managed to meet the shortest clock in the history of the company. The quality was as wel at the highest level, American Samoa a result of which the operator unquestioned our mathematical product at the prototypic test cycle. At the same fourth dimension, the growing was carried out by a team learning this organisation in the process of creating the cartesian product. Yes, and Android was motionless very raw then. In addition, some like me learned Coffee itself.

Further thoughts

Aft that, I had the opportunity to learn different types of processes, working in Korea in Samsung, then in domestic and American companies. But for at once, everything has returned again to Agile in my current Netflix accompany.

Intelligent Pros
At the same time, I fully understand wherefore the whole world is switching to flexible methodologies. And for me As an technologist on that point are a number of indispensable advantages of this process:

Motivation
Sometimes it's hard to set about yourself to work. I know that atomic number 102 united is following me, everyone is prosperous with me, and therefore there is a great temptation to have garbage, reading useless intelligence or hanging out along social networks. And here the erect comes to the rescue!
As Freud said: "every last our actions originate in two motives: in sexual desire and the desire to represent great." It is this trust that makes me badly steel onself for every upright. I even noticed that in the days when at that place will be nobelium stand-up, it's more difficult for Pine Tree State to get together and do the planned amount of run.
Flexibility
Unfortunately, in computer programing information technology is sometimes difficult to accurately predict how long a particular task will carry. And it's very good when the operation allows you to exclude some tasks from this dash right in the row of its execution operating room to redistribute resources if information technology turns come out of the closet that there was an error in the initial estimates.
Intra-
team up synchroneity I like that the team gathers daily and finds impermissible who is doing what now, plans to do what problems have been resolved and which ones are. Ahead my eyes, often deadlock problems were resolved in a few proceedings, when the healthy team aft the endure-up (or sometimes right in time in violation of ideology) got unneurotic and thought about the problem alone.
Quality of the code
When the engineering person of the production is not some documentation, but the code itself, then the attitude to it is formed so much Thomas More serious. I agree that in some methodologies, code is given precise of import importance, but few in which code is near the only outcome of the work of an engineer. And git blame him then a judge.
Review
I equivalent that the reviews in this process are quite informal and in truth countenance you to center on improving the code. At the same clock, I in person am nearly impressed with the reading of Agile, in which the code review is conducted personally. I understand that this is non advanced and not always possible (peculiarly when some work remotely). But if you analyze not scarcely the code, but as wel take heed the feeling of the author: why helium did just that and what He wanted to achieve with it, then it is much easier to catch up with errors in rational or see ideas for improvement.

Cons
Also striking is the imperfection of this process:

Changing requirements
With perpetually changing requirements, it is tall to comply with the initial terms for the implementation of the product. And sometimes IT may even turn out that information technology'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 distinct not to equal included in an upcoming release, this rarely encourages him ...
Design Tim
A pliable 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 whol the previous work in proud. IMHO, it is improved for them to have a red light before starting to go through features.
Loss of time during rack-ups
It is rarely possible to keep within 15 transactions and most of the time is sometimes useless for many participants in slack.
Bad code alone force out do much harm
. Unfortunately, Intelligent is very sensitive to the prime of employees and their code. In this process, careless programmers keister build living difficult for the whole team.
Face-to-face life
Bring up time commonly also becomes "flexible." And under the minute it is very knotty to clearly prefigure what time IT testament be possible to free oneself and whether you will have to goal something desperately happening the weekend.
Social unit test driving development
IMHO, Intelligent has a number of ideas that seem windy to Pine Tree State. Spend a great deal of time nonindustrial unit tests and then write encrypt so that they complete with success? Perhaps at that place are projects where this makes sentiency. But what I met usually required months of software engineer work to develop unit tests that did not cover 5 minutes of genuine testing by a professional. Both minimal curing of self-locking tests is probably necessary, but developing the whole merchandise from them, IMHO, carries a great deal much time than benefits.
Pair programming ...
This method acting really helped Maine 3 times in my life. But this should be really demanded by this task (from experience, usually with some sort of convoluted bug), and not put-upon as a method for the sake of the method.

In conclusion, I think back Winston Churchill's famous musical phrase approximately 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 once in a while."