Why agile doesn't suit you

Published on November 05, 2011

Why agile doesn't suit you

    I have not heard so many negative reviews about a single topic as about Agile. They say that it’s both ineffective, and doesn’t work, and is suitable for the lazy, and is thought up for earning money at consultations, and in general, the agile does not suit us .

    I'm not going to dissuade anyone here. I want to share my thoughts on why Agile is really not suitable for most companies .

    To begin with, what is agile for a developer? Agile is first and foremost a discipline . The discipline that will allow you to work more efficiently, but by no means for nothing. Agile requires something from the developer.

    Agile is a discipline

    • In order for the information within the team to quickly spread out and any problems to get out immediately, Agile prescribes daily morning meetings - stand - ups , where everyone briefly talks about what he did yesterday, what he managed to do and what problems he encountered.
      That's a good idea, but ... this is my favorite time when I just got to work, brewed coffee for myself - it's about half an hour to go over the news and fresh jokes. And instead, should I stand in a circle and report for yesterday?

    • The code should be simple and readable so that it can be easily changed, and at any time to different people. To do this, you must constantly review and refactor your code . Those who treat their code as a brainchild perceive the requirement to constantly change the code as a personal insult. "I've tried, builds , and now - to change again ...?"

      And of course, very few people like what your code looks and change their dirty paws strangers.

    • To make sure that the project works, you have to write unit tests . That is, the code turns out twice as much, and twice as much work is hung on the developer. And for what? All the same, the tests do not give a 100% guarantee and will never find all the bugs. So let the testers look for them, they exist for this!

    • To make sure that the project works as the client wanted, one has to write acceptance tests . And there’s so much trouble with them ... They’re both slow and constantly breaking ... But what the hell, isn’t it easier to call everything with your hands? Moreover, there are testers for this.

    • To make sure that the project does not fall apart when integrating changes from different developers, Agile offers a Continuous Integration server. Here's another, come up on our head! Now a bunch of some left letters are pouring into my inbox that the build is broken. And I have to climb onto some server and figure out why the tests are red? Yes, I, perhaps, have nothing to do with it, why will I spend time!

    • In order to constantly discuss all design issues, do a continuous code review, instantly find errors and write tests to a friend, friend ordered pair programming . Undoubtedly, the developers are most afraid of this. Still would! All day some guy will be sitting next to me, who will tell me how and what to do. Poke my nose at my mistakes. Neither read your mail, nor news, nor jokes. No, fire! What if he has a different style? Should our opinions differ? If he likes to put brackets in the same row, and I - in the following? Will we argue all day? Thank you, we don’t need such kindness.

    • In order for the developer to better understand the problem area and be able to promptly offer simple solutions, direct communication with customers is necessary . Oh, oh, I prefer to talk with colleagues on the phone, but with the client ...

    So agile is a discipline that


    create a working product with high quality in a predictable time frame.
    But here's the catch. It only makes sense

    if you want to

    create a working product with high quality in a predictable time frame.

    And here we come to the most important thing: for most developers this is not the main priority. Yes, that’s the sad truth.

    Comfort zone

    It is interesting for the average developer to write some kind of complex catchy module (even if it is not needed by anyone), but it is not interesting to write a simple, ugly, but working product. I know what I'm talking about, I myself was so. I was more interested in writing my StringUtils class than using an existing library like commons-lang. Just because it is interesting. The process of creating this crap is interesting. And what about the client? Yes, nothing will happen to him, I’ve been waiting for six months and will still wait. Now I will finish my StringUtils and then deal with its problem.

    And most importantly: the average developer appreciates his comfort at the computer. My workplace is my home. Here I set everything up as I want, put my desktop, music, audio player, the programs there are different, the picture in the frame on the table. I even have my own cup here. Here I have a comfort zone . It's just me and my computer. Well, yes, sometimes bosses and testers come in, burst into my world, but this is temporary. They will talk and leave. And again peace will reign in my world.

    This is a fact: an ordinary developer does not want to let anyone into this space! What are you saying? Will pair programming increase productivity? Reduce the number of bugs? Improve code design? Hmm ... no, I don’t believe it. Yes, anyway, two separately will do twice as much. This is how conversations are born that agile does not work.

    For most developers, their own comfort is more important than working software, than the success of the company and everything else.

    Problem deeper

    Therefore, Agile is not suitable for most developers. Agile will take away your usual comfort, take away your personal desktop and make it work according to the rules. And this is only to ensure that the company was better and the client was satisfied.

    While your own comfort for developers in your company is more important than the success of the company, no agile will help you. You do not need all these expensive trainings, violent implementations of Scrum, Lean, TDD, etc. All this is no-pa-mo-zhit . The problem is deeper.

    Where to get motivation?

    In addition to the motivation that the company’s management can come up with, the agile also offers its own motivators. Believe me, when you get used to it a bit, you will realize that Agile practices can be very fun, such as ping-pong programming . As Vlad911 said ,
    Pair programming is a great way to increase motivation. You can always agree with your partner on what to do and how to do it so that it does not turn into routine work, you can dynamically change responsibility and not be engaged in the “same thing,” which you often have to do alone.

    Committing the code, being sure that it works as it should, is a great pleasure in itself.

    And finally, one of the biggest motivators is, strangely enough, lively communication with the client. Compare: when the boss comes to you and asks: “Well, have you finally finished it?”, And when the client comes to you and says: “Wow, you did it! This is what you need, thank you! ”It is easy to justify yourself before the boss: I was at the rally, held the code, fixed bugs - whatever. With a client, such a trick will not work. One must either do the work, or ... there simply is no other option.

    So if you are interested in the success of the project, use aggile. If your comfort zone is more important to you - well, make coffee and start reading the news. Agile doesn't suit you yet.