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.

providers, providers, providers.. do not kill me, help me!

when you have a business, it is important to be careful with every aspect, but there are two that are really important to me:

1. People that you are hiring
2. Services providers

I use that order because i believe that it is the correct, at the end an organization (company, enterprise or however you want to call it) is a structure with people giving meaning to that structure and the most important element IS THE PEOPLE. 

the second point is related to service providers, that is because many of the business we are building today rely on services that we are hiring. History teach us that some providers could fail, for example having a blog in wordpress.com, maybe they could suffer a outage and take our blog down, that is bad but imagine having your core business app hosted in a place that goes down (in that point you could start crying). If you do not want to cry, what you will need are really reliable providers.

talking about providers, we expect help from them, having a cleaning company that leaves more trash than the one that is collected is not a good deal. Let's face it, we need more help than problems, that my friends is a good indicator of the quality of the provider (problems over help, it have to be almost zero).

Being very honest, problems happen, and we will have to deal with them, but what we do not need (want) is the same problems over and over.

I will give you two examples:

• AWS, they are the first provider of cloud computing services, they have (in my personal opinion) one of the most amazing stacks of cloud oriented services. Obviously, they will charge you for breathing if they have a chance. They have premium support that could be something really expensive, for my it could be like USD 2000 monthly (OUCH). If you are not a member of the premium group then you are screwed!! You can open a ticket and pray for a solution in less 2-3 days or post something in the AWS forum and again pray for a solution. For example, they showed me in the AWS Management Console that I have a pending "EVENT", it was an Instance that was running in a "DEGRADED HARDWARE", one of the AWS solutions is Stop/Start the instance, well, i did that... the instance was stuck in stopping state for 5 hours. Thankfully it was not a really important server, otherwise that would mean a downtime of 5 hours, obviously, i reported the issue after 5 minutes but the solution arrived a "little bit" later. 
• Time Warner Cable (TWC), do i need to say more?? Anyway, I will do it.. Imagine you have an Internet based product, so you will need a reliable connection, well, TWC offers connections of 30Mbps/3Mbps, 30Mbps/5Mbps, 50Mbps/3Mbps and 50Mbps/5Mbps (something like that). Usually, if you have the 50% of that, you are really lucky, and the trace routes could vary from 20ms per hop to 1200ms per hop in a five minutes period. By the way, if you call to support, they will give you reasons like "it is related to solar flares (really, they told me that once and my connection is coaxial)", "it could be a problem with the AMPLIFIERS (OMG, do i have to plug a headphone to the router??, where are the speakers)". Whatever they say the final sentences is the same.. "It should be fixed in a while, wait for a couple of hours", in real life, that means something like "stop bothering us because we are busy playing solitaire".

Did those examples sound like reliable providers??

I can give you some personal keys:

• try to build your apps over disposable servers, so you could get over any kind of situation like the "DEGRADED HARDWARE" case. Volatile is key!
• If you could not make it volatile, make it easy to recover, maybe with amazon AMI or any kind of machine images, backups with fast recovery and fast deploys. Chef is awesome, but having a recipe that takes 1 hour to run is a really BAD option, speed it up.
• get redundancy, do not put all the eggs in one basket. For example, if you are in AWS, use multiple regions and availability zones in each region.
• if you could combine multiple providers, DO IT!!

Simple, Standard and Open

Today, i was at Google NYC attending to the Meetup about the Crisis Response project, I learned a couple of stuff there that i would like to share with you, I also remembered some old concepts, let's start recognizing that some people in Google is using their knowledge and some cool tools to help people, if you want to know a little bit more about that check the google.org site. GOOD JOB PEOPLE!!

Then, at the beginning of the tech talk the presenter showed a slide with this 3 words:

SIMPLE

STANDARD

OPEN

Reading that, I came with the idea of sharing my opinion about those words.

Talking about SIMPLE, we usually start to building stuff, coding, developing and we walk around many options or solutions, well, I will tell you something, you should be trying the simplest one, you do not need to create a time machine to get the current system time... please KEEP IT SIMPLE!!

In second place, let's be standard, if you have a proven solution please use it, after having your product up and running you will have the chance to invent stuff just to replace those that could work better, but the secret is here.. USE THE STANDARDS, if the specification of a product says that you have to do X, then why are you trying to do 1/X, if the language is object oriented why are you trying to create a procedural code. Be STANDARD

Openness, do not refer only to open source products, it refers to be open to collaboration and be open to collaborate, if you have a problem ASK, if you found a solution PUBLISH it. Also remember that most of the time you are working with other people, so please be gentle and comment the code, create READMEs, etc.