One of the most beneficial features of agile-based development is the extremely rapid response time that short development iterations provides. When you aren’t bound by strict contractual guidelines, you can respond freely to emerging issues as the software develops. Unforeseen problems can be detected and addressed quickly and efficiently. There is one area of software development that can especially benefit from this ability to respond to new information but it is often overlooked.


Simply put, scrum masters keep the team productive. This sounds easy enough but it is actually a multifaceted role with many responsibilities.  To make the best use of scrum and to have the most effective team possible, the scrum master should only be responsible for one team on a full-time basis at any given time. However, if you scale back the extent to which the scrum master is involved with the team, and scale back his or her proactive duties, a full time scrum master could have two or even three projects working simultaneously.


As I work on agile software development projects with new clients, I am seeing firsthand just how important trust is to the success of the projects. Clients who have never engaged in an agile software development project are usually skeptical and leery about the whole business. They can’t see past doing business without a contract or control over the project. Since agile is more about engaging in an open and productive dialogue, building trust is key.


As a scrum master, I put a strong value on the Agile Manifesto’s first value:

Individuals and interactions over processes and tools.

Many development teams can do everything correctly, but if they don’t “know” the people on their development team, then they are not following Agile’s primary principle and will fail.


“If you are afraid to change something it is clearly poorly designed.”
― Marin Fowler

One of the most important steps in agile development is the refactoring. Before actually getting involved in agile methodology, we should spend some time writing the legacy architecture of the project. I do not think we should use this methodology when starting a project; I strongly believe it should be another step before the famous sprint zero. You should design your project first. I clearly understand that a well engineered code is going to help in long term for every agile project in several ways. If you don’t want to be afraid to change your code in the future, it has to be well designed and structured. This is done by people who engineer code; there is a huge difference between just programming and engineer code.


Who do you think would win this fight? Many of you might say Chuck Norris, no contest. But if I may be so blunt — you’d be wrong! Bruce Lee would win this fight, hands down! Heck, he could win with his hands tied behind his back!

The same goes for the agile method. Some people will swear up and down that agile is the reason their project failed while others feel just as strongly that this methodology was the best change they could have made to their projects.

There are many ways an agile project can fail, though. In this post I’ll explain what can be done to avoid one of the most common mistakes.

Desde mi comienzo en BDCSOFT, mi ambiente de trabajo ha sido únicamente con 3 monitores activados, hoy acepto el reto de agregar dos más. Creo que es bastante productivo tener varios monitores cuando se escribe código, en realidad todo depende del proyecto en el que estoy trabajando. Por el momento estoy más enfocado en código de servidor usando ASP.NET Web API(csharp) y manejo de datos con Microsoft SQL Server. Al mismo tiempo, rara vez tengo que realizar tareas que incluyen manejo de controles en AngularJS y de servicios con Restangular. Mi plan es tener todas las aplicaciones que uso a mi alcance sin tener que minimizar o cerrar aplicaciones. Espero que mi plan funcione!


WP_20141118_002 La Matriz vs Mi Ambiente de Trabajo

Steve McConnell, “The problem with quick and dirty, is that the dirty remains long after the quick has been forgotten” (El problema de resolver algo rápido y sucio es que lo sucio se mantiene por mucho tiempo y lo rápido se olvida, traducción mía).

Para poder comenzar y terminar exitosamente un proyecto de software usando la metodología ágil, se necesita del equipo y los programadores correctos, lo que yo llamo “los programadores ágiles de la nueva era” es lo que hace que un proyecto no fracase. ¿Quién dijo que usar la metodología ágil garantiza el éxito? Tener éxito en un proyecto ágil no es fácil, muchos pueden tener problemas usando este método, a continuación voy a compartir algunas ideas que te podrían llevar al éxito cuando estés usando esta metodología.