Etiqueta: agile values

  • Agile Value / Valores de Agile
    Administración / Management / Administración de Proyectos / Project Management / Agile / IT / Scrum

    Agile’s origins and values
    flashw

    Agile Value / Valores de Agile

    Winds of Change

    Much is heard about Agile, Agile project management or the “Agile methodology” as something from the 21st century, but actually, the origin and Agile values began to take shape a little earlier. The 90s were a very interesting decade, MTV had its best moment, the Grunge music invaded the radio and the Internet came to the life of the masses. Along with the Internet boom, the way of making software changed completely, companies began to learn how to create software on a large scale and for interconnected users all over the world, which brought new demands. In the search for success, many of these companies began to import “good practices” from other industries expecting good results, which in the end were mixed in many cases (see Waterfall Model).

    Many electromechanical systems were already beginning to be replaced by electronic systems, and sometime later the software began to have more and more relevance, but the development and interaction of these elements were trapped in predictive models that tried to know all elements involved in a system of beforehand, which were (and still are) very difficult to establish at the beginning of software projects with high levels of uncertainty, which has since caused very long development periods with hard-to-predict end dates. This situation led to the frustration of many leaders, who despite the situation were creating and adapting their own techniques, methods, and frameworks to the traditional models of development, which eventually gave rise to the first winks of Agile thinking.

    Agile is born

    After several previous meetings, in February of 2001, a group of professionals had a new and now famous meeting whose main contribution was The Agile Manifesto. This manifesto was written and signed by seventeen software development leaders (now known as the Agile Community). Their document gave a name to how this group was developing software and provided a list of Agile value statements:

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

    That is, while there is value in the items on the right, we value the items on the left more.

    You can know more about history and the original manifesto at agilemanifesto.org

    In particular, these opinion leaders looked for ways to quickly build functional software and put it in the hands of end users. This quick delivery approach provided a couple of important benefits. First, it allowed users to get some of the business benefits of the new software faster. Second, it allowed the software team to obtain quick feedback on the scope and direction of software projects on a regular basis. In other words, the Agile approach was born.

    Behind the Agile Value Statements

    You already know the list of value statements, but let’s see what are the reasons behind them:

    Value people and interactions over processes and tools. Those of us who have a path in the development world know that a team with great people works well even using mediocre tools also these teams always overcome other dysfunctional teams with mediocre people who have excellent tools and processes. If people are treated as disposable pieces there will be no process, tool or methodology capable of saving their projects from failing. Good development processes recognize the strengths (and weaknesses) of individuals and take advantage of it instead of trying to make everyone homogeneous.

    Value software that works over the comprehensive documentation. Because it leads us to have incrementally improved versions of the product at the end of each iteration. This allows us to collect early and often, some feedback about the product, and the process allows us to know if we should correct the course of action, make adjustments or move forward with the same vision. As the developed software grows with each iteration, it can be shown to the probable or real users. All this facilitates the relationship with customers and improves the chances of success.

    Value the collaboration with the customers over contracts negotiation. Because in order to create Agile teams we must seek that all parties involved in the project work to achieve the same set of goals. Contract negotiation sometimes conflicts with the development team and the customer from the beginning. I think the multiplayer online battle arena games are a great example, personally, I like games like Heroes of the Storm o League of Legends. These are cooperative games where teams with five members are formed, the objective is that the team must destroy the base of the enemy by working together. All players win, or all players lose. These matches are surprisingly fun, and what we would like, for software development teams and customers, is to come together with this same attitude of collaboration and shared goals. Yes, contracts are often necessary, but the terms and details of a contract can exert a great negative influence on the different parties involved, and turn a collaborative environment into an inner competitive one.

    Value responding to change over following a plan. Because the main objective is to provide the greatest possible amount of value to the project’s customers and users. In large and/or complex projects, you will find that it is very difficult even for users and/or customers, to know every detail of each feature they want. It is inevitable that users come with new ideas, or that they decide that some critical features initially are no longer so. For an Agile team, a plan is a vision of the future, but many points of view are possible and environmental factors can change over the time. As a team gains knowledge and experience about a project, the plan should be updated accordingly.

    With the four Agile Values Statements from the Agile Manifesto in mind, I think you can begin to understand what it means to have an Agile approach to estimating and planning.

    Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve 🙂 ).

    Related links:

    To agility and beyond: The history—and legacy—of agile development

    What Is Agile?

    What Scrum Master Certification to Choose?

    These are some books to know more:

    No Comment
  • Agile Value / Valores de Agile
    Administración / Management / Administración de Proyectos / Project Management / Agile / IT / Scrum

    El Origen Y Los Valores De Agile
    flashw

    Agile Value / Valores de Agile

    Vientos de Cambio

    Mucho se oye de Agile, de Agile project management o de la “Agile methodology” como algo propio del siglo XXI, pero en realidad el origen y los valores Agile comezaron a gestarse un poco antes. Los 90s fueron una década muy interesante, MTV tuvo su mejor momento, la música Grunge invadió la radio y la Internet llegó a la vida de las masas. Junto con todo el boom de Internet la manera de hacer software cambió por completo, las empresas comenzaron a aprender cómo hacer software a gran escala y para usuarios interconectados en todo el mundo, lo que trajo nuevas exigencias. En la búsqueda del éxito muchas de esas compañías comenzaron a importar las “buenas prácticas” de otras industrias esperando buenos resultados, los cuales al final fueron mixtos en muchos casos (vea Waterfall Model).

    Muchos sistemas electromecánicos ya comenzaban a ser sustituidos por electrónica, y un tiempo después el software comenzó a tener cada vez más relevancia, pero el desarrollo y la interacción de estos elementos se vieron atrapados por modelos predictivos que intentaban saber todos elementos involucrados en un sistema de antemano, lo cual resultaba (y aún resulta) muy difícil de establecer al comienzo de un proyecto de software con altos niveles de incertidumbre, lo que causa desde entonces periodos de tiempo de desarrollo muy largos con fechas de término difíciles de predecir. Esta situación llevó a la frustración a muchos líderes, quienes a pesar de la situación fueron creando y adaptando sus propias técnicas, métodos y marcos de trabajo a los modelos tradicionalistas de desarrollo, lo que eventualmente dio pie a los primeros guiños del pensamiento Agile.

    Nace Agile

    Después de varias reuniones previas, en Febrero del 2001 un grupo de profesionales tuvieron una nueva y ahora famosa reunión cuyo mayor aporte fue el Manifiesto Agile (The Agile Manifesto). Este manifiesto fue escrito y firmado por diecisiete líderes del desarrollo de software (hoy conocidos como la Comunidad Agile). Su documento dio un nombre a cómo este grupo estaba desarrollando software y proporcionó una lista de declaraciones de valor Agile:

    • Individuos e interacciones sobre procesos y herramientas
    • Software trabajando sobre documentación completa
    • Colaboración del cliente sobre la negociación del contrato
    • Responder al cambio sobre seguir un plan
    Y el grupo añadió:
    Esto es, mientras que hay valor en los elementos en la derecha, valoramos más los elementos de la izquierda.

    Puede ver la historia y el manifiesto original en agilemanifesto.org

    En particular, estos líderes de opinión buscaron formas de construir rápidamente un software en funcionamiento y ponerlo en manos de los usuarios finales. Este enfoque de entrega rápida proporcionó un par de beneficios importantes. Primero, permitió a los usuarios obtener algunos de los beneficios comerciales del nuevo software más rápido. En segundo lugar, permitió que el equipo de software obtuviera retroalimentación rápida sobre el alcance y la dirección de los proyectos de software de forma periódica. En otros palabras el enfoque Agile había nacido.

    Detrás de las Declaraciones de Valor Agile.

    Ya conoce la lista de declaraciones de valor, pero veamos cuales son las razones detrás de ellas:

    Valorar las personas y las interacciones sobre los procesos y herramientas. Los que tenemos un camino en recorrido en el mundo de desarrollo sabemos que un equipo con grandiosas personas funciona bien aun utilizando mediocres herramientas y que estos equipos siempre superan a otros equipos disfuncionales con personas mediocres que tienen excelentes herramientas y procesos. Si se trata a las personas como piezas desechables no habrá proceso, herramienta o metodología que salve a sus proyectos de fallar. Los buenos procesos de desarrollo reconocen las fortalezas (y debilidades) de los individuos y sacan provecho de ello en lugar de intentar que todos sean homogéneos.

    Valorar el software que funciona sobre la documentación completa. Porque nos lleva a tener versiones incrementalmente mejoradas del producto al final de cada iteración. Esto hace posible recolectar temprana y frecuentemente algo de retroalimentación sobre el producto y el proceso nos permite saber si deberemos corregir el rumbo, hacer ajustes o seguir adelante con la misma visión. A medida que el software desarrollado crece con cada iteración, se puede mostrar a los usuarios probables o reales. Todo esto facilita la relación con los clientes y mejora las probabilidades de éxito.

    Valorar la colaboración con el cliente sobre la negociación de contratos. Porque para crear equipos ágiles debemos buscar que todas las partes involucradas en el proyecto trabajen para lograr el mismo conjunto de metas. La negociación de contratos a veces pone en conflicto al equipo de desarrollo y al cliente desde el principio. Creo que los juegos multiplayer online battle arena son un gran ejemplo, personalmente me gustan juegos como Heroes of the Storm o League of Legends. Estos son juegos cooperativos donde se forma un equipo de 5 miembros, el objetivo es que el equipo debe destruir la base del enemigo trabajando juntos. Todos los jugadores ganan, o todos los jugadores pierden. Estos juegos son sorprendentemente divertidos, y lo que nos gustaría es que los equipos de desarrollo de software y los clientes se acercaran con esta misma actitud de colaboración y objetivos compartidos. Sí, los contratos a menudo son necesarios, pero los términos y detalles en un contrato puede ejercer una gran influencia sobre las diferentes partes involucradas, y convertir un ambiente colaborativo a uno competitivo.

    Valorar responder a los cambios sobre seguir un plan. Porque el objetivo principal es aportar la mayor cantidad de valor posible al cliente del proyecto y usuarios. En proyectos grandes y/o complejos, encontrará que es muy difícil incluso para los usuarios y/o clientes, conocer cada detalle de cada característica que desean. Es inevitable que los usuarios vengan con nuevas ideas, o bien que decidan que algunas características críticas inicialmente ya no lo son tanto. Para un equipo ágil, un el plan es una visión del futuro, pero muchos puntos de vista son posibles y los factores ambientales pueden cambiar con el tiempo. A medida que un equipo gana conocimiento y experiencia sobre un proyecto, el plan debe ser actualizado de acuerdo a ello.

    Con las cuatro declaraciones de valores del Manifiesto Ágil en mente creo que puede comenzar a comprender que significa tener un enfoque ágil para estimar y planificar.

    Enlaces relacionados:

    To agility and beyond: The history—and legacy—of agile development
    What Is Agile?
    Planeación, Cono de Incertidumbre y Estimaciones en IT

    Estos son alguno libros recomendables para saber más:

    No Comment