Skip to main content

Difference between agile and Agile

    The Agile manifesto was the common ground found by a (heterogeneous) group of 17 software development experts (who now call themselves The Agile Alliance) with different backgrounds that included Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming. They all agreed, in spite of their dramatically different points of view,  on a list of 12 base principles of how software development should be managed. This 12 point list is now known as the Manifesto for Agile Software Development.

    1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    1. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
    1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    1. Business people and developers must work together daily throughout the project.
    1. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    1. Working software is the primary measure of progress.
    1. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    1. Continuous attention to technical excellence and good design enhances agility.
    2. Simplicity--the art of maximizing the amount of work not done--is essential.
    3. The best architectures, requirements, and designs emerge from self-organizing teams.
    4. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

    These 12 principles are based on 4 essential guidelines:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    Please note that this guidelines are presented as a dichotomy (which is by itself controversial), this means that all Agile project must mainly align to the left side of this list (the Light side of the Force you might say?).
    So in simple words; you are not on an Agile project if you value documentation over working software or you value more your plan that responding to change. Now let me clear something up before some of you start rising an eyebrow in disapproval... It’s perfectly ok to value comprehensive documentation over working software or processes and tools over individuals and interactions, some projects have to work that way, it all depends on the nature of the project, which brings up the question:

    Is Agile the approach the best someone could have on a software developments nowadays?
    The answer: NO!!, it depends on the nature of the project, Agile is not going to work on all projects.

    Why agile is not the same as Agile.

    There has been a lot of confusion lately caused by the abuse and misuse of the term Agile. So let’s clear out what is strictly Agile and what isn't.  Just remember the essential principles and why the manifesto was created for in the first place. People can call their approach agile (notice the lower case "a") which can mean whatever they want, this is the main source of all the confusion regarding Agile Development. Agile is by itself an adjective that describes something flexible that reacts fast. That fact plus all the buzz Agile Development (notice the capital “A”) has generated recently has caused people to indiscriminately use it to describe their project, design, coding, management, testing and even documentation techniques or methodologies as "agile" when they believe that they are "fast" or "faster than..." by whatever arbitrary standard they can think of, so you can  append "agile" to anything you want to, just to make it sound trendy and cooler;

    The "agile" incremental beer drinking technique (I know a couple of guys I work with how are experts on this).

     Agile is just a set or principles that are open to interpretation. There is no methodology set on stone you can follow or any set of tools you could use. This is a good thing if you think about how flexible it can be. You can hypothetically allocate virtually any kind of project within this frame and improve is greatly, but the down side is that you can easily get lost in the path that doesn’t have any barriers on the sides that delimit it clearly. This explains why you can buy 2 different Agile books and still get contradicting opinions on the same subjects.

    So just to wrap things up;

    • Agile: Is a set of 12 principles for software development aimed to increase productivity by prioritizing activities that add real value to the project and to the deliverables. Agile is leveraged by an incremental and iterative approach.  It is a great way to manage projects in which the requirements are not completely defined by the start (like most of the projects we engage on at DMT). It can be risky to follow it on project that demand requirements to be perfectly defined upfront or that requires a very detailed change process (basically any project that by nature requires you to value any of the guidelines right side).
    • “agile”: Anything that moves quickly.

Popular posts from this blog

Java - Getting the memory size of an object.

Because the way Java language and the way JVMs are implemented, this apparently trivial task is more complex than it may seem specially when compared to C++ where all objects have a size() method. Java memory architecture is built to abstract the developer from direct manipulation of memory so that the developer can focus on more relevant tasks, this comes with a price.

There are 3 basic approaches you can take in order to do this all with their pros and cons:
Memory guess (Heap Size prior object creation - Heap Size after object creation = Object Size)Java Instrumenting QuerySerialization
Memory Guess
This is the simplest approach because of the fact that you have a pretty easy access to the Heap Size via:

The issue with this approach is that you cannot control what is being thrown into the heap at a given time, JVM is shared by a lot of processes that run in a given machine so this is a error prone approach that is not recommended.

Java Instrumenti…

Crítica a "10 Ideas Erróneas sobre PHP"

Hace algún tiempo me encontré con un post que hablaba sobre las 10 ideas erroneas sobre PHP. Me pareció interesante la idea de hacer un arquetípico post de 10 puntos defendiendo un lenguaje de programación, situacion que por si misma me parece un tanto chusca.

Antes de empezar quisiera aclarar algo. He sido desarrollador de PHP por más de 6 años (de hecho siempre me he considerado un PHPer en recuperación). Dada esa experiencia puedo decir sin temor a equivocarme que PHP es una excelente herramienta para el 95% de los proyectos Web (pequeños), es accesible y tiene una comunidad bastante extensa y heterogénea (esto puede ser un problema en ocasiones). También desarrollo en Java desde hace 7 años y he hecho algunos proyectos en C Sharp con .NET, Flex y actualmente me encuentro en un desarrollo que utiliza Grails (Groovy on Rails) y Griffon por lo que he tenido algo de experiencia con tecnologías muy distintas y filosofías casi opuestas.

Puedo decir con mucha seguridad que PHP defini…

¿Que tienen los cuchillos de obsidiana y el Nearshore en común?

Aparicion en Campus Night Jalisco Nov 2016
Como siempre me gustaría empezar esta noche con una historia, disculpen uds la insistencia, pero esto es lo que los cuenta cuentos hacemos. Al terminar les prometo que la historia es bastante relevante con lo el tema que queremos tratar.
Este es parte de una historia es solo un fragmento plasmado en el Códice Boturini conocido también como la Tira de la Peregrinación que narra la migración de los Chichimecas de su lugar de origen, Aztlán,  hacia su destino final, la tierra prometida de Teoculhuacan.
El viaje inicia como muchos viajes conocidos, con un personaje misterioso y muy poderoso que convence a un grupo de aventureros a embarcarse en una aventura, en ese caso éste personaje no es otro que el mismísimo Huitzilopozchtli, el dios de la guerra, el sol y los sacrificios humanos, nuestro Gandalf mesoamericano. Nuestra historia comienza pasados más de 2 siglos dentro de este viaje tras muchas peripecias y percances los Chichimecas…