Tuesday, August 13, 2013

being "agile" does not means being "scatterbrained"

I am not (and I do not attempt to be) a Scrum Master or any kind of agile guru, for that I have friends like Jesús Enrique Méndez (http://agileinpills.wordpress.com and his initiative http://www.agileopenspace.org), Gustavo Bonalde (http://gbonalde.blogspot.com/) or Carlos Gabriel (https://twitter.com/CarlosGabriel_). Anyway I am a guy that has spent a lot of time researching, studying, watching in silence how people do the stuff and secretly making some experiments; so I have developed my own opinions.

First, I believe that we need to be really agiles in our process, any kind of waste should be minimized, so why should we keep doing things in the most costly way (time related)?

Second, we need to be productive, that means that expending a year to develop a new functionality is unacceptable, even if you are developing an Operating System the process should not be that long.

Third, your business model or your economical maturity level could give you an advantage over other companies but that does not mean that you are allowed to make mistakes and if you are a small company or startup you will need to use properly any piece of resource that you can get.

Thinking in those three ideas, I usually see how people start being "agile" by ignoring any kind of design or worst, they start being "agile" and they stop thinking in the problem or the possible solutions and they start doing "anything" to solve the problem. I do not want to talk about efficiency or any related aspect to that, but let's take a time to understand the situation, let's draw something, let's get to the reasons of our problem and then we can solve it looking an good/optimal solution. If you want to be "agile" you can start by using the best simple solution instead of the most complicated solution. At this point my two advices are:

remember that thinking and designing are not sins.

keep it simple, do not oversize the problem.


I also see how people try to reduce the development cycle by doing something and sending it to the production environment as soon as they finish, then everybody gets crazy because something is falling; well, when I was a young developer, I learned about a technique (almost magical) to minimize troubles, it is called TESTING, we can not be in a rush and forget about tests, we HAVE to test our codes, obviously something can change and something could fail, but that HAS to be the exception and not the rule. I have saw people that is unable to send a functionality to production without having tons of errors and then breaking everything. Today, we have tools to automate our test, we can use jenkins or any other but we have to use it.

clumsy is not agile.

lazy is not agile.

testing is important for everybody, and we know that things can fail but it should be the exceptions.  

you can be agile testing, that does not mean NO TESTING.

Finally, I have saw people that as soon as they start getting error they start blaming any single API, third party tools or even the astrological configuration of mercury. People, let's face it, usually when something goes wrong we are the responsible, if we work in an orderly way, if we document our code, splitting the problems in smaller problems could make us agiles replacing broken pieces, fixing bugs or improving functionalities.

Well my friends, if you are trying to become an agile developer then you have my bless, just do it, but do it in the right way, do not become a "scatterbrained" trying to speed up developments.


4 comments:

  1. Totally agree. Thanks for sharing!

    ReplyDelete
  2. Good post William, a lot of people have wrong ideas about be Agile, agileis not just Scrum, Lean or whatever agile trend, is more about the way you see and feel things.. thanks for the mention! keep in touch.

    ReplyDelete
    Replies
    1. Agree MY MASTER!!! :D you have been one of the good examples and inspiration to this post.

      Delete