martes, 27 de diciembre de 2016

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:

miércoles, 21 de diciembre de 2016

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).


martes, 6 de diciembre de 2016

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).