Agile: ¿Qué es y cómo surgió?

¿Qué es Ágil y cómo surgió? A continuación les comparto un video que hice para explicar lo más simple posible y en no más de 5 min.

Referencia:
https://agilemanifesto.org/

Movimiento Ágil: los 4 aspectos claves de la agilidad empresarial

Hoy en día, 'Agile' y la agilidad en general se transformó en un movimiento más allá de Ingeniería de Software y área de producción. En este sentido, el Manifiesto Ágil (textualmente) ya ha quedado algo obsoleto, pero no así su esencia, su corazón. El núcleo esencial ágil se sintetiza en cuatro aspectos claves que pueden aplicarse y guiar las prácticas de cualquier disciplina o proyecto de componente intelectual en cualquier organización empresarial o Sistema Social Empresarial. En el siguiente video esquematizo estas cuatro claves que considero conforma el espíritu del movimiento.

(video del año 2017)

Tengo que recalcar que no inventé nada nuevo. Esto es simplemente la síntesis (que cualquiera puede hacer) del Manifiesto Ágil y la literatura al respecto que fluye en el movimiento ágil. No obstante hace poco rescaté un fragmento de video de Ángel Medinilla, en un meetup de Agilidad y escala, donde sintetiza la agilidad en estos cuatro aspectos claves con los que estoy totalmente de acuerdo y que me alegra que haya alguien que profese lo mismo. Siempre consideré que el movimiento ágil, tanto en la industria de software como en cualquier ámbito empresarial, se resume a estos cuatro aspectos esenciales. El manifiesto ágil está orientado solo al desarrollo de software y por esa razón considero que está algo obsoleto, por lo que algunos intentan brindar alguna otra fórmula valorativa alternativa, como "Modern Agile" o "Heart of Agile", sin embargo pienso que esas ideas no engloban realmente la esencia ágil, no guardan el verdadero espíritu ágil. Y viendo a Ángel encontré, por fin, a alguien que resume tan bien la agilidad y que está en sintonía con algo que hace años vengo fomentando, y es que: estos cuatro aspectos valorativos pueden emplearse en cualquier sistema social empresarial y es lo que constituye el corazón del movimiento ágil.

A continuación comparto el video:

Referencias:

1. Manifiesto por el Desarrollo Ágil de Software: http://agilemanifesto.org/iso/es/manifesto.html
2. Ángel Medinilla, meetup agilidad a escala: Conversatorio con Ángel Medinilla sobre Agilidad a escala, incluyendo experiencias reales de los asistentes y perspectivas sobre los marcos de trabajo más conocidos (SAFe, LeSS, Nexus...).

Valores ágiles: Mandala Ágil

En estos días (primera semana de Mayo 2017) asistí al Agile Open Camp de Chile 2017. Es un evento diferente, con energía, buena onda y muchas conversaciones interesantes. Fue un espacio para compartir y generar semillas para nuevas ideas.

En algunas charlas interesantes sobre la vigencia del “Manifiesto Ágil” y sus posibles actualizaciones con generalizaciones y simplificaciones, surgieron debates sobre “Modern Agile”, “Heart of Agile” (de Alistair Cockburn) y como se podría mejorar la forma de presentar el Manifiesto Ágil. A mi no me convencía la propuesta de “Modern Agile”, con el agregado que hace de la seguridad como requisito (“Make Safety a Prerequisite”) ni tampoco me cerraba la simplificación propuesta con el “Heart of Agile” con dos incisos muy relacionados como la reflexión y la mejora continua, pero mostrados separados. En consecuencia pensé en hacer una síntesis.

La idea es que la agilidad se ha vuelto excesivamente decorada y el manifiesto, hasta cierto punto, tiene muchos incisos (4 valores y 12 principios) como para ser aprendido fácilmente. Además fue concebido para el desarrollo de software, específicamente, y no para cualquier organización.

Algunas preguntas que me resonaban en esos días fueron… ¿Qué podemos enfatizar para volver al corazón de la agilidad y reinterpretar al manifiesto ágil rescatando lo esencial? ¿Cómo mostrar el corazón de la agilidad de una forma didáctica y simple? 

Respondiendo a estas preguntas, pienso que es bueno tener un mandala, como un escudo, que resuma algunos conceptos claves de la agilidad, sin perder nada del manifiesto. Cuando terminaba el evento “Agile Open Camp” hice un borrador de lo que para mí podría ser un buen mandala (con forma escudo) que muestra cuatro conceptos clave, que cohesionan a los 4 valores y 12 principio. El dibujo que hice (con sharpie en hoja A4) es el siguiente:

Los conceptos clave son:

1. Collaboration
2. Delivery (Value Flow)
3. Adaptation
4. Improvement

Estos conceptos contemplan a los valores y principios ágiles como comento a continuación:

1. Factor humano (Colaboración): este concepto abarca a la priorización de "individuos e interacciones sobre procesos y herramientas" y a la "colaboración con el cliente sobre negociación contractual". Ambos valores son necesarios para lograr la colaboración. También sostiene al principio que dice que "los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.". Además para lograr mejorar la colaboración, y con ella un equipo de alto desempeño de trabajo sostenibe, es necesario lograr individuos motivados. La colaboración se da en procesos de autoorganización. Y finalmente para promover la colaboración se prioriza y fomenta la conversación cara a cara y el fortalecimiento de las relaciones humanas dentro de la organización.
2. Flujo de valor (Entrega): esta es una idea pragmática de operatibilidad. Abarca a "Software funcionando sobre documentación extensiva" donde se amplía a producto funcionando como foco principal por sobre documentación excesiva (de esta manera no se limita a solo software). Se tiene como prioridad satisfacer a nuestros clientes mediante la entrega temprana y continua de un servicio o producto con valor. Las entregas de valor deben ser frecuentes, con preferencia al periodo de tiempo más corto posible. Que las cosas funciones, nuestros productos y servicios, es la medida principal de éxito y progreso.
3. Adaptación: este abarca a la "Respuesta ante el cambio sobre seguir un plan". Los procesos Ágiles promueven el desarrollo sostenible mediante ciclos de retroalimentación y auto-regulación para manejar el cambio de requisitos y el entorno cambiante. Se busca la adaptabilidad en un proceso sostenible con procesos de auto-ajustar el comportamiento según el contexto cambiante y el continuo feedback del cliente y usuario.
4. Mejora continua: este concepto incluye la búsqueda de la excelencia, mediante la mejora contínua con etapas de reflexión y acción. También incluye a la simplicidad, como parte de la búsqueda de excelencia, además de que es parte de la ciencia y de la ingeniería.

Pienso que esta síntesis es una buena herramienta visual y conceptual para enseñar agilidad. Recordar estas cuatro ideas se hace muy simple, más si mantenemos visible el mandala en nuestro lugar de trabajo.

El equipo de participantes del AOC...

Referencias:

• The aglile mindset - BeanieTech Blog.
• HeartOfAgile by Alistair Cockburn - Blog.
• The Heart of Agile Technical Report by Alistair Cockburn - PDF.  
• AOC Chile 2017.  
• Modern Agile.
• Angel Medinilla, el corazón de la agilidad.

Agile: Pareto y los Early Adopters

Pareto y los adoptadores tempranos

En los proyectos de innovación en que se usa Scrum o algún marco ágil, se puede trabajar con MVPs, en el ciclo de vida del producto, que se orientan a "Early Adopters" siguiendo la "Lay de Pareto" y teniendo en cuenta la "Ley de difusión de la innovación"[1].

Los adoptadores tempranos

Everett Rogers define una categoría de adopción como una clasificación de individuos dentro de un sistema social sobre la base de Innovación. Para Rogers [1], los adoptadores tempranos son quienes tienen el mayor grado de opinión y liderazgo entre las categorías de los adoptantes de innovaciones y son los que están dispuestos a probar una nueva tecnología, a pesar de que tenga fallos o sea una versión de prueba. Los adoptantes tempranos suelen ser más jóvenes en edad, tienen un estatus social más alto, tienen más lucidez financiera, educación avanzada, son más socialmente avanzados que los adoptantes tardíos.

Ley de pareto en el desarrollo del producto

La ley de Pareto [6], en software y scrum, también conocida como la regla del 80/20, establece que, de forma general aproximadamente el 80% del valor proviene del 20% de features. Basándonos en ella, con Scrum, buscamos centrarnos y adelantarnos en construir el 20 % de funcionalidad más importante y core de nuestro producto, mediante diferentes MVPs que probaremos en primera instancia con los adoptadores tempranos. En otras palabras, con el 20% del esfuerzo se puede proporcionar el 80% del valor y obtener resultados anticipados (“time to market”) sacando rápido algo al mercado probando hipótesis con early adopters y obteniendo feedback temprano.

Ley de difusión de la innovación

La difusión de innovaciones es una teoría que examina cómo, por qué, y a qué ritmo las nuevas ideas y la tecnología se propagan a través de las culturas. En esta teoría se explica cómo los sucesivos grupos de consumidores adoptan la nueva tecnología a medida que pasa el tiempo. Los adoptadores tempranos son los primeros en adoptar una innovación y comprende un grupo de aproximádamente entre el 13,8% de la población total de consumidores adoptadores de la innovación o el 13,5% de la población total. En el desarrollo de software podemos apuntar a estos usuarios adoptadores tempranos para probar rápidamente nuestro producto ya que son usuarios tolerantes y motivados para adoptar nuestras innovaciones.

Referencias:

[1] [Everett Rogers, 1962] Diffusion of Innovations, Everett Rogers, 1962.
[2] Simon Sinek, Cómo los grandes líderes inspiran la acción, TED 2009.
[3] Difusión de innovaciones, wiki.
[4] Ley de la Difusión de la Innovación, Fabiola Martinez, Youtube 2011.
[5] Article on Trans-cultural diffusion or Roland Burrage Dixon (1928): The Building of Cultures.
[6] Bousquet, G.H. (1999). «Vilfredo Pareto (1848–1923): Biographical Notes on the Occasion of the Publication of his Letters to Pantaleoni». En: John Cunningham Wood y Michael McLure (Eds.). Vilfredo Pareto. Critical Assessments of Leading Economist (Londres y Nueva York: Routledge) 1: 197-. ISBN 0-415-18500-9.
[7] Scrum, un proceso de trabajo 2.0.

DevOps: Qué es DevOps

Se ha desarrollado el primer evento de Latam para DevOps, “Dev Ops Journey Latam” y mi equipo ha participado en este gran espacio para compartir conocimientos y experiencias.

 

¿De qué se trató el evento? ...compartir conocimientos relacionados a DevOps. Pero, para entenderlo hay que saber de qué se habla cuando se dice DevOps:

¿Qué es DevOps?

La integración a escala para que una Software Factory sea ágil y lleve adelante uno de sus principios, el Continuous Delivery, es lo que se denomina DevOps. DevOps es la integración de Ingeniería de Desarrollo de Software con la Ingeniería de Operaciones, que es todo el soporte IT y de plataforma para posibilitar que el proceso de desarrollo sea ágil, haciendo entregas frecuentes de calidad y logrando la colaboración entre el personal de desarrollo y el personal de operaciones a lo largo de todas las etapas del ciclo de vida de producción de software. DevOps es una parte central del agilismo en la entrega de software eficiente.

En palabras de James Betteley:

 “DevOps para mí es sobre la forma en que los equipos trabajan juntos colaborando para extraer un mayor valor de negocio y producir una solución de mayor calidad, trabajando como un equipo capacitado, y sin culpar a otros...” (James Betteley, What Is DevOpScrum?, DZone, 2016)

Una manera de integrar Operaciones con Desarrollo es mediante el uso de herramientas compartidas, misma cultura, comunidades en común, procesos ágiles compartidos, comunicación estandarizada, etcétera. Algo crucial en una organización madura es la automatización máxima en procesos de Continuous Integration, Continuous Delivery gestión del conocimiento y comunicación. En esta vía la gestión de riesgos y de impedimentos es importante herramienta de integración y cohesión para agilizar los procesos y detectar problemas en forma colaborativa.


Referencias:

• Implementación: http://agilismoeningenieriadesoftware.blogspot.com.ar/2016/12/scrum-gestion-agil-de-riesgos.html
• Modelo: http://agilismoeningenieriadesoftware.blogspot.com.ar/2016/10/scrum-gestion-agil-de-riesgos.html
• Encontrarás toda la información de las charlas en el sitio https://devopsjourney.it.lan.com
• What Is DevOpScrum?, DZone, 2016: https://dzone.com/users/912573/jamesbetteley.html.

Agile: La adopción del Agilismo y sus resultados

La adopción del Agilismo y sus resultados

Existen diversos estudios y reportes que muestran cómo el agilismo impulsa el desempeño financiero y la mejora organizacional. Algunos resultados de aplicar agilidad en las empresas son los siguientes:

1) BTM Business Agility Index: Los resultados generales del estudio de índice de agilidad empresarial BTM 2010 [1], muestran que las empresas con características de agilidad empresarial (Líderes de agilidad empresarial) exhibieron un rendimiento financiero superior:

• 13% a 38% de ventaja de rendimiento en eficiencia de capital y valor.
• 10% a 15% de ventaja de rendimiento en el margen.
• Hasta un 5% de ventaja en rendimiento en crecimiento de ingresos y ganancias.
• Hasta un tercio menos de la volatilidad de los precios de las acciones en comparación con las acciones cotizadas públicamente de Organizaciones no ágiles.
• La ventaja de rendimiento de la agilidad era sostenible en la perspectiva de un año como la de 5 años.

2) CHAOS Report: El informe Chaos [2] deja claro la superioridad de las metodologías ágiles de desarrollo de Software sobre las tradicionales en cascada y confirma la creciente adopción en la última década. Según el informe, la combinación de "personas competentes", "proyectos pequeños" y "metodologías ágiles" es una fórmula de éxito [2].

Referencias:

[1] BTM Research Report: The Characteristics of an Agile Enterprise and How They Drive Superior Financial Performance by Converging Business and Technology Management, BTM Business Agility Index, May 2010.

[2] 2015 CHAOS Report, CHAOS Database 2011 to 2015, Standish Group Store. https://jeronimopalacios.com/2015/09/agile-tiene-cuatro-veces-mas-posibilidades-de-exito-que-waterfall/
(Para elaborar este informe, Standish ha utilizado la base de datos CHAOS con los datos de los años 2011 a 2015, durante el año fiscal estadounidense).

SCRUM: Gestión Ágil de Riesgos - Implementación

En estos días di una charla en el evento DevOps Journey LATAM 2016 y quería compartir algunos de los conceptos e ideas que traté.

DevOps Journey LATAM, 02 de Diciembre de 2016, Hotel Atton el bosque. Agile Risk Management in devops Context.

¿Por qué ser ágiles?

Pomo dicen las fraces...
“El Software se está comiendo al mundo” (Marc Andreessen) y “La capacidad de aprender con mayor rapidez que los competidores, será la única ventaja competitiva sostenible" (Peter Senge).

¿Por qué usar herramientas?

Buscamos priorizar a “Individuos e interacciones sobre procesos y herramientas”, pero nunca descartamos el uso de herramientas. Solo buscamos hacerlo de una manera ágil siempre que la herramienta ayude a aportar valor y facilite el trabajo.

Para implementar alguna gestión de riesgos con alguna herramienta de Administración Ágil de Proyectos como Jira hay que tener en cuenta que:

• La herramienta es solo un medio de comunicación que posibilita las conversaciones referente a un issue. No debe ser nunca un fin ni un medio de freno o limitación burocrática. Se debe privilegiar siempre el cara a cara.
• La herramienta es un medio para lograr una “Organización Inteligente”, una organización con memoria, que aprende  continuamente, tanto ella, como sus miembros [Senge 2012]. Así posibilita la transparencia organizacional y la toma de decisiones basadas en datos.
• Siempre se debe privilegiar la simplicidad. Centralizar la información ayuda a generar reportes automáticos y no tener dispersión de información ni tareas recurrentes de relevamiento de datos en forma manual. Eso agiliza las tareas de irradiación de información.
• La herramienta debe ayudar a la “facilitación de procesos” para lograr un “flujo de trabajo eficiente”. Ayuda a la facilitación siendo un soporte al manejo de impedimentos y al análisis de causa raíces para descubrir soluciones transversales.

Modelo de implementación con Jira, Confluence y Google Sheet

Podemos implementar un modelo de Gestión Ágil de Riesgos basado en ticket de Jira (Risk) y Hojas de cálculo de Google Sheets como se muestra en el siguiente modelo:

La gestión de riesgos puede incluir o juntarse con la gestión de impedimentos y bloqueos usando tickets jira tipo Problem y Blocker. Se puede usar un proyecto transversal para impedimentos transversales reportados por diferentes equipos o los equipos que reportan problemas de otros equipos pueden engancharse en los ticket de otros equipos.

SM=Scrum Master; AM: Agile Manager, Release Train Engineer o Delivery Manager.

La idea es usar Jira lo más simple posible y que ofrezca soluciones transversales a DevOps. Tips Jira:

• Para los riesgos se pueden usar dashboards por equipo. Y en un proyecto transversal se pueden recolectar los riesgos transversales o recurrentes de diferentes equipos mediante consultas JQL.
• También se puede usar un proyecto Jira para tener un tablero de riesgos e impedimentos transversales. A lo cual también se deberían crear issueType en Jira de tipo Risk y/o Impediment.
• En caso de necesitar reportes o cálculos que no se puedan hacer con Jira se puede usar las Sheets de Google Drive. Todo dependerá de la creatividad y necesidad de cada organización. Siempre buscando la simplicidad y siguiendo a la agilidad.
• Propuesta de usar los link “blocks“ para indicar dependencias y usar un label 'ExternalDependency' para indicar dependencias externas.
• Se pueden hacer consultas de dependencias con un filtro. Por ejemplo: issuelinktype in ("blocks") and project="OPDIST" and labels="ExternalDependency" and NOT status="Done" and NOT status="Closed" and NOT status="In Production"

También se puede usar Confluence. Algunos tips:

• Propuesta de usar riesgos como páginas de Confluence con label de página 'riesgo’. Cada riesgo es una página.
• Cada página de riesgo debería tener un título con el formato RiskWord-ProjectCode-Index. Por ejemplo ‘Risk-ProjectA-1'. 
• Se pueden concentrar los riesgos en una página Confluence. Los riesgos se pueden desplegar en una tabla con la macro:  ‘Page Properties Report’ filtrando por label 'riesgo’ (o risk).
• Se pueden desplegar dependencias de Jira en Confluence con un filtro (como se hace en Jira).

Reference:
Blog agilismo en ingenieria de software: SCRUM: Gestión Ágil de Riesgos.
[Senge 2012] Las 5 Disciplinas de la Organización Inteligente.
DevOps Journey LATAM, 02 de Diciembre de 2016, Hotel Atton el bosque. Agile Risk Management in devops Context. https://devopsjourney.it.lan.com/
 

Agile: Modern Agile

Modern Agile

Agile moderno es una comunidad de personas interesadas en descubrir mejores maneras de conseguir resultados impresionantes y de esa manera impulsar una nueva ola de agilismo.
Desde una perspectiva ágil, no es otra cosa que un marco de principios bajo la agilidad, que aprovecha la sabiduría de muchas industrias, orientado por principios y un marco libre. 

fig. 1: En la figura se puede ver la afinidad entre valores y principios por colores.

Al definir un subconjunto de valores y principios o principios alineados al agilismo, lo que se obtiene es un marco de agilismo que refleja nuestras prioridades. Los principios de Modern Agile son:

• Haz que las personas sean geniales: este se desprende de priorizar a los "individuos e interacciones" y a la búsqueda de la "excelencia". El desafío aquí es cómo lograr que la gente en nuestro ecosistema sea impresionante o extraordinaria.
• Experimenta y aprende rápido: este en algún sentido deriva de buscar "respuesta ante el cambio". Si prestamos atención a los principios ágiles como buscar "aprovechar el cambio" para proporcionar ventaja competitiva al cliente y "buscar la entrega temprana y continua de software con valor" en procesos de reflexión recurrente que nos permite aprender rápidamente llegamos a esa idea de la agilidad y Scrum de "trabajo empírico". Aprendemos rápidamente mediante la experimentación con frecuencia.
• Entrega valor continuamente: deriva de priorizar el "software funcionando" y la "entrega continua de valor". Aquí el desafío es dividir grandes cantidades de valor en piezas más pequeñas que se pueden entregar de forma segura en forma temprana.
• Haz de la seguridad un prerequisito: aquí es donde se prioriza un principio más novedoso que considera a la seguridad tanto una necesidad humana básica y una clave para desbloquear un alto rendimiento. Si bien se puede desprender del agilismo de priorizar a las personas e interacciones y al principio de motivación, por los cuales se busca lograr ambientes de trabajo "psicológicamente seguros" que promuevan personas altamente motivadas. Desde esta perspectiva nos esforzamos para que nuestros equipos sean resilientes y nuestras colaboraciones, productos y servicios sean resistentes y seguros. Se buscan personas libres y motivadas que no le tengan miedo a la culpa. Estimo que también se puede incluir a la seguridad informática.

Al parecer, con Modern Agile, se busca una marco de agilidad ultraligero y tomando algunos aspectos del "Manifiesto por el desarrollo ágil del software", haciendo énfasis en el aspecto humano (por eso agrega lo de la seguridad aunque es redundante) y simplifica la mejora continua y la adaptación en "experimenta y mejora". No se inventa nada nuevo, es solo un emblema de valores basado parcialmente en el manifiesto ágil. Aunque puede ser de utilidad para educar la agilidad en un ámbito donde es necesario hacer hincapié en formar entornos de seguridad psicológica para potenciar a las personas y la colaboración. Como apreciación personal, espero no se transforme en una moda sobrevalorada.



Referencias:

http://modernagile.org/
InfoQ: An Introduction to Modern Agile.
Agile 2016: Modern Agile.

Libro: Scrum en las organizaciones

Comparto por este medio el libro que escribí sobre “Scrum en las Organizaciones”. Con este libro comparto una guía para trabajar bajo el marco de trabajo Scrum y para gestionar proyectos de Ingeniería de Software en forma ágil.

Este libro ofrece una guía para el conocimiento e implementación de una manera de trabajar y de gestionar proyectos de Ingeniería de Software, permitiendo encontrar prácticas emergentes en dominios complejos. En él se explica el sistema Scrum de un modo integrador desde diferentes perspectivas y fuentes de conocimiento, proporcionando un marco integral que incluye a los principios filosóficos, estructura, procesos y aspectos complementarios. 

Con este libro se busca ayudar a los equipos a avanzar de intentar emplear Scrum a ejecutarlo correctamente para lograr alcanzar los resultados que aún no se han logrado.

También busca ser una guía y ayuda para quienes se desenvuelven como Scrum Master de equipos de desarrollo de software.

Referencias:

• Amazon en papel pasta blanda.
• Amazon Kindle.

SCRUM: Gestión Ágil de Riesgos - Modelo

Este post fue origen de datos para que pudiera dar una charla de gestión de riesgos y quería compartirlo con ustedes...

 DevOps Journey LATAM, 02/12/2016, Hotel Atton el bosque. Agile Risk Management in devops Context.

Gestión Ágil de Riesgos

Si bien la gestión de riesgos no es parte de scrum y un facilitador no se encarga de la gestión al modo tradicional como la gestión de riesgos, sí debería velar por mitigar los problemas que surjan en el proyecto y apoyar, en consecuencia, a la gestión de riesgos. En este sentido, no solo se encargaría de ayudar a desbloquear issues y reducir impedimentos para que el sistema de trabajo fluya en el procesamiento de PBIs (Product Backlog Items), sino que también puede preocuparse de prever issues para anticiparse a los problemas y controlar así, de antemano y en la medida de lo posible, los riesgos asociados a bloqueos del flujo de trabajo que atentan contra los objetivos del proyecto.

fig.1: Diagrama riesgos vs problemas.

Lo difícil es lograr una gestión de riesgos ágil en vez de una gestión pesada, dificultosa y que demande mucho esfuerzo de gestión. En esta vía, es preferible mantener un simple registro de riesgos con información concisa. Los datos principales a registrar de un riesgo, además de su nombre, pueden ser: descripción, probabilidad (probability), impacto (severity), criticidad (criticality), acciones de mitigación, dueño y estado.

fig.2: estado de riesgos.

Algo simple que se puede lograr trabajando con criticidad es usar tres valores en la probabilidad de ocurrencia y en el impacto (1, 2 y 3). El impacto representa la severidad de la ocurrencia de un problema asociado al riesgo o el tiempo perdido (size of loss). Por otro lado, la criticidad representa la prioridad del riesgo o el grado en que ese riesgo afecta negativamente al proyecto (exposure). El mismo será resultado del producto entre la probabilidad y el impacto. En consecuencia, la criticidad podría ser: 1, 2, 3, 4, 6, 9.

Las herramientas gráficas que se pueden usar para dar visibilidad de los riesgos son: a) la “matriz de riesgos”; b) el “histórico de criticidad”; c) o el gráfico de curva de riesgo quemado (Risk Burn-down Chart).

La gestión de riesgos no es independiente de la gestión de impedimento o de problemas o “issues”. Muchos de los problemas surgidos en el proyecto están asociados a riesgos identificados. Por tal motivo, la gestión de riesgos es útil, porque podemos mitigar los problemas de antemano. Por dicha razón, puede ser valioso llevar un registro de los issues y su relación con los riesgos. Siempre sin perder de vista no caer en el énfasis de la documentación ni en el afán de reportar. Se debe buscar la simplicidad y el foco en el flujo de trabajo sin impedimentos.

Las herramientas gráficas útiles para dicha gestión son: “Tablero de Obstáculos” (obstacle board) o el calendario de issues (Issues calendars).

Referencia:

Risk Management in Agile, Satheesh Thekku Veethil, Scrum Alliance Org., 3 May 2013

https://www.scrumalliance.org/community/articles/2013/2013-may/risk-management-in-agile

Managing Risk on Agile Projects with the Risk Burndown Chart by Mike Cohn. Mountain goat software, April 8, 2010.

http://www.mountaingoatsoftware.com/blog/managing-risk-on-agile-projects-with-the-risk-burndown-chart

Agilismo: Presentaciones ágiles

¿Cómo dictar una presentación ágil?

Podemos hacer que nuestras presentaciones orales, demostraciones de productos o resultados, sprint review, show cases, exposiciones educativas, informes de noticias, capacitaciones, etc., sean ágiles. Para lograrlo tenemos que tener en cuenta los valores ágiles en su desarrollo.

Pueden haber muchas maneras de hacer una presentación en el marco de la agilidad. Aquí se muestra una forma basada principalmente en tres valores ágiles y un principio.

A continuación ofrezco 6 aspectos a tener en cuenta dentro de este marco de agilidad:

1. Tiempo: la atención ronda entre 5 y 18 minutos. Es recomendable no superar los 20 minutos de una presentación (principalmente si las personas están de pié) y en actividades largas fraccionar en tramos de 20 min. [1] [2]. No superar los siete segundos de silencio [6]. Y por último, respetar un time-box.
2. Útil: Dar valor al público espectador con lo que se presenta [2] [7]. Debes poder presentar tu premisa en una o dos oraciones y hacerla interesante [2].
3. Emoción:  Motivar con emociones, sensaciones o dinámica ágil por medio del lenguaje textual y corporal [6] [7]. Conoce a las personas a las que les hablarás [2] [3]. El ponente también puede ponerse en un rol de amigo o de igual [6].
4. Interacción: Hacer preguntas y hacer pensar interactuando con los demás. Romper la barrera con el público y capturarlo [2] [6]. Puedes solicitar feedback para poder mejorar.
5. Simple: Buscar ser claro, conciso y concreto presentando poca información y siendo visual y minimalista, “Keep it simple” [2] [4].
6. Cambio: Orientarse a inspirar y/o generar un cambio en el oyente. Para ello ser desafiante, innovador, buscar impactar o generar nuevas ideas o reflexiones. Tu conclusión debe ser algo que deje a tu público con una sensación positiva sobre tu idea y cómo les afectará si la deciden implementar, que los motive al cambio [2] [3]. El ponente también debe estar abierto al cambio y a salir de su zona de confort [6].

Referencias:

[1] ¿Cuánto debe durar una presentación? por Roger Prat, febrero 25, 2013

URL: http://www.presentable.es/consejos-practicos/cuanto-debe-durar-una-presentacion/

[2] TED Speaker Guide by TED.com.

URL: http://storage.ted.com/tedx/manuals/tedx_speaker_guide.pdf

[3] Manifesto for Agile Software Development by Agilemanifesto.org

[4] Principles behind the Agile Manifesto by Agilemanifesto.org

URL: http://www.agilemanifesto.org/principles.html

[5] Cómo dictar una charla TED

URL: http://es.wikihow.com/dictar-una-charla-TED

[6] Presentaciones efectivas: Técnicas para la exposición oral de trabajos y proyectos académicos. Por Iñaki Bustínduy. Editorial UOC, 11-03-2014.

URL: https://books.google.cl/books?id=s-sKAwAAQBAJ&pg=PT81&hl=es&source=gbs_selected_pages&cad=2#v=onepage&q&f=false

[7] Neuro Presentaciones efectivas, Miguel Figueroa, Youtube, Published on Dec 3, 2015

URL: https://www.youtube.com/watch?v=GD1QosoeRtY

Scrum: Scrum es ágil

¿Por qué Scrum es ágil?

Ser ágil es, en un sentido, ser ágiles tomando decisiones mientras nos adaptamos constantemente en la acción sin paralizarnos en la duda, pues:

"Dudar es mortal. Observa, oriéntate, decide y actúa. Determina donde estás, evalúa tus opciones, toma una decisión ¡y actúa!" Jeff Sutherland [1].

Para ello Jeff Sutherland creó un sistema como marco de trabajo que llamó Scrum.

Desde esta perspectiva, Scrum es un marco ágil porque fue creado para practicar los valores ágiles.

"Personas antes que procesos, productos que funcionen antes que documentar lo que se supone que debe hacer, colaborar con los clientes antes que negociar con ellos y responder al cambio antes que seguir un plan. Scrum es el marco que yo creé para poner en práctica esos valores." Jeff Sutherland [1].

Referencias:
[1] Scrum: The Art of Doing Twice the Work in Half the Time. Jeff Sutherland.

Scrum, Desarrollo Agil: Desarrollo mediante MVP

Bajo un marco de trabajo ágil, como SCRUM, el desarrollo de software se hará de forma evolutiva con entregas frecuentes de valor para el usuario. Una técnica complementaria es el uso de MVP para entregar valor que sirva de hipótesis de prueba de nuestro producto.

¿Qué es un MVP? 

El MVP (Minimum Viable Product) es la "Versión Mínima de un Producto"[1], características mínimas y necesarias para hacer foco y que el producto salga al mercado, de tal manera que nos permite obtener feedback rápido del comportamiento con el mercado y clientes [1]. El MVP tiene solamente las funcionalidades que permiten que el producto sea lanzado sólo a un segmento de clientes, tales como a los "early adopters" [1] o es un release dirigido a entusiastas "early adopters" [5]. Con el MVP lo que buscamos es testear nuestras hipótesis sobre nuestra visión del producto, es decir, tratamos de comprobar que hemos encontrado un problema que los early adopters están dispuestos a probar para determinar que nuestro producto es una solución adecuada [3].

MVP es una estrategia para el aprendizaje de forma iterativa sobre sus clientes para poner a prueba las hipótesis fundamentales del negocio. [11][4]

El o los MVPs son resultados del desarrollo iterativo en ciclos cortos con entrega o release de funcionalidad mínima, usable por el cliente. Un release o entregable no necesariamente es un MVP, sin embargo, un MVP es un entregable del producto mínimo tan pequeño como lo mínimo para probar la viabilidad de nuestro producto final [3], commodity o "end game". 

Como muestra la figura, cualquier entregable no es un MVP. Por ejemplo, un paso 1 de una aplicación dividida en pasos no es un MVP de un desarrollo evolutivo. Sí lo es un entregable que representa conceptualmente al producto completo (todos los pasos), aunque no lo sea. En el dibujo, la rueda es un entregable de valor, pero no es un MVP.

En concepto proviene de "Lean Startup" y en esta metodología el conocimiento se obtene de forma empírica a través del lanzamiento de diversas iteraciones del MVP [3].

Un MVP incluye entregables de valor y puede incluir al o los MMF (Minimum Marketable Features)[10] (este concepto se originó en Kanban y Lean). El MMF es un entregable con "el conjunto más pequeño posible de funcionalidades o features que, por sí mismas, tienen valor en el mercado"[1] [9]. Esta es una característica mínima, ya que cualquiera más pequeña no sería comercializable [10].

¿Cuántos MVPs?

Aquí surge una pregunta… ¿Hay solo un MVP o varios? La respuesta depende del autor y del criterio del equipo que decida conceptualizar sus entregables. Algunos prefieren tener muchos entregables de valor que prueban hipótesis hasta alcanzar un MVP que prueba las hipótesis principales de producto en forma iterativa. En Scrum parece que se maneja más esta idea: 

El verdadero objetivo de scrum es conseguir un MVP en manos de los futuros clientes cuan rápido sea posible y obtener sus comentarios. [12]

Aunque es común referirse a que pueden haber varios MVPs [8], en forma evolutiva, hasta alcanzar un mínimo producto que se lanza al mercado como tal. A este producto se lo puede identificar de otra manera, como MMP [6].

¿Qué es un MMP?

El MMP (Minimal Marketable Product) es el producto con el más pequeño posible conjunto de features y que crea la experiencia del usuario deseada, y por lo tanto puede ser comercializado y vendido, tempranamente, con éxito [6][11][13]. La clave para crear una exitoso MMP es desarrollar el producto para unos pocos usuarios [6].

Evolución iterativa e incremental de un producto

Resumidamente, un producto puede evolucionar mediante una secuencia de releases, de los cuales algunos pueden ser MMFs sin alcanzar a ser MVPs. Después de una etapa de creatividad y prototipado (si e producto es nuevo y/o novedoso), tendremos uno o una secuencia de MVPs hasta llegar a un MMP, que será el mínimo producto que se lanza al mercado como tal. De allí en adelante comienza el crecimiento en escalamiento (Growth) e incremento de funcionalidad hasta alcanzar una madurez (maturity), para finalmente constituir un producto final estable o commodity (ver siguiente figura [5]).

Finalmente, hay que tener en cuenta que sobre esto no hay nada tallado en piedra. La demarcación de estos conceptos dependen de cada autor y de la interpretación que haga quien los use. No hay ningún diccionario único y referencia única. Por lo tanto, cómo se los use será subjetivo al equipo y contexto particular. Lo importante es que el equipo se ponga de acuerdo en una manera y todos estén en la misma página.


Referencias:


[1] Book: Proyectos Ágiles con Scrum: flexibilidad, aprendizaje, innovación y colaboración en contextos complejos, Martín Alaimo, 2014.

[2] Wikipedia 2016: https://es.wikipedia.org/wiki/Producto_viable_m%C3%ADnimo

[3] Artículo: ¿QUÉ ES EL PRODUCTO MÍNIMO VIABLE? Por Xavi Sanchez sobre Creación de empresas, Metodologías Lean  http://www.emprenderalia.com/que-es-el-mvp-producto-viable-minimo/

[4] Book: The Lean Startup by Eric Ries.

[5] Book: Build It Like A Startup: Lean Product Innovation By Greg Gehrich.

[6] Article: The Minimal Marketable Product by Written by Roman Pichler on Wednesday 31st August 2011.

[7] Book: “El Equilibrio Dinámico entre Costo, Cronograma, Características y Calidad en el desarrollo de Software” Willian Junk, 2000 (Willian, S. Junk. (2000) The Dynamic Balance Between Cost, Schedule, Features, and Quality in Software Development Projects, Computer Science Dept., University of Idaho, SEPM-001).

[8] Book: Directo al Punto, Una guía para la creación de productos Lean. Paulo Caroli, María Fernanda Escudero and Freddy Coronel, 2016.

[9] Article: The Agile Alphabet, Scrum Alliance, Koti Reddy Bhavanam, 31 August 2012. URL: https://www.scrumalliance.org/community/articles/2012/august/the-agile-alphabet#sthash.WtiurBp3.dpuf

[10] Article: Agile Methods The various implementations of Agile, Scrum Alliance, Shri Naveen Kumar, 2 March 2015. URL: https://www.scrumalliance.org/community/articles/2015/march/agile-methodologies#sthash.uawtNykK.dpuf

[11] Article: What is an MVP? By David Lowe | April 15, 2014 URL: http://scrumandkanban.co.uk/what-is-an-mvp

[12] Book: Summary: Scrum - Jeff Sutherland: The Art of Doing Twice the Work in Half the time, by BusinessNews Publishing.

[13] Book: The art of agile development by James Shore. (Tools and techniques - value based priorization.)