sábado, septiembre 28, 2019

Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales


Tomado de (1)

Hola a todos


En este acompañar equipos y organizaciones hacia el mindset ágil, con frecuencia he observado a Scrum Masters, e incluso Agile Coaches, ser ingenuos respecto al entorno en el que se encuentran y creer que su iniciativa, proyecto o producto ágil va a salir adelante solo con el burndown, burnup, kanban, uno que otro tablero y compartir sus pedidos de forma verbal con el o los interesados encargados de ayudar a la gestión del entorno empresarial, en efecto, esto debería ser suficiente pero la noticia cruel es que la mayoría de nuestros proyectos ágiles se desarrollan al inicio en entornos tradicionales, no amigables con el mindset ágil, por lo que  es necesario emplear herramientas de la gestión tradicional a modo de interfaz, como lo llamaría Michael Sahota (2).


Adaptado de (2)
Adaptado de (2)

Una de las herramientas que comúnmente sugiero, y bastante poderosa en entornos tradicionales es un informe semanal o quincenal con el estado de
  • la gestión de riesgos
  • la gestión de problemas o impedimentos


Claro, claro esto se puede gestionar con dos tableros,




o incluso con uno solo, que tenga dos carriles, unos impedimentos sean problemas a resolver lo antes posible y los riesgos sean problemas a resolver en el mediano plazo




y post-it que indiquen:
  • descripción del problema o impedimento
  • fecha de identificación
  • persona a la que fue asignado
  • días que lleva sin resolverse (pueden ser solo líneas en el post-it)




Pero un informe de carácter frecuente, con esta información con seguridad pondrá en evidencia la necesidad de gestión por parte del entorno tradicional.

Igual que un tablero, un informe frecuente también es transparencia.


Informe de Problemas o Impedimentos (3)

Informe de Riesgos(3)



como lo comparto muchas veces


"hasta que el entorno y las personas no muestren indicios de mindset ágil, deberemos interactuar con ellos con las herramientas a las que están acostumbrados y ayudarles a transitar a nuestro mindset"



Adaptado de (2)


Nota importante:
Esta misma ingenuidad la he visto en proyectos de gestión tradicional.


Bienvenidos sus comentarios

Saludos Ágiles
Jorge Abad




Notas, Comentarios, Aclaraciones y Observaciones

  1. Photo on Visualhunt.com
  2. Una guía de supervivencia a la adopción y transformación ágil: trabajando con cultura organizacional. Michael Sahota-  http://www.lecciones-aprendidas.info/2017/08/una-guia-de-supervivencia-la-adopcion-y.html
  3. No dudo que estos reportes podrán tener más o menos información, deberán ser adaptados de acuerdo al contexto, pero recomiendo fuertemente:
    • tener a alguien asignado para su resolución
    • tener el tiempo de "no resolución"
    • la importancia para el "proyecto"
  4. Por lo general pongo "proyecto" (entre comillas) debido a que en el mundo ágil no se gestionan proyectos, sino productos.

martes, septiembre 24, 2019

Criterios para la Selección y el Éxito del Proyecto Piloto en Scrum

Hola a todos

Con cierta frecuencia comparto tips sobre como elegir el Proyecto Piloto en el mundo ágil, aquí va la lista de tips actualizada.


Se recomienda iniciar con proyectos que cuenten con los ciertos criterios que nos permiten tener un mayor impacto en la organización:

  • Duración estimada de máximo 8 meses
  • Contratación del proveedor bajo esquema ágil - ver más aquí -.
  • Seguimiento bajo métricas ágiles.
    • burndown chart para los sprints
    • velocidad
    • burnup chart para el Release
  • Dedicación una persona experta en el negocio de al menos el 50%, la cual esté empoderada y no denigre de la agilidad.
  • Un Scrum Master o Facilitador experto 
  • Los impedimentos identificados por el Scrum Master o Facilitador serán atendidos y tendrán prioridad
  • Las evaluaciones de desempeño de quienes participan en el proyecto no sean en cascada
  • Las áreas de soporte le den prioridad al proyecto
  • Ejecución por uno o dos equipos ágiles (15 personas máximo en total)
  • Se debe de considerar tecnologías conocidas por los equipos
  • Las personas de los equipos deben: 
    • Contar con los skill técnicos
    • Dedicación al 100%
Tomado de (1)
Si quieres conocer los post asociados a este tópico haz clic aquí - http://www.lecciones-aprendidas.info/search?q=piloto


Aclaraciones, Notas, Comentarios y Referencias

lunes, septiembre 23, 2019

Algunos ANS (Acuerdos de niveles de servicio) y Penalidades sugeridas en el Mundo del Desarrollo Ágil de Software

Hola a todos

En el pasado Ágiles 2019, presente la charla "Tips para una PMO perdida en el Mundo Ágil" - clic aquí -  y uno de los puntos en los cuales hay una constante inquietud por parte de las organizaciones tradicionales es:

¿Cuáles son las ANS (acuerdos de niveles de servicio )(1)  y penalidades aplicarían en un contrato de desarrollo ágil?

Responsabilidades en el Desarrollo Ágil

Para empezar, establezcamos responsabilidades bajo el esquema ágil
  • el cliente es responsable del producto que esta requiriendo, o seá,
    • tener claro el ¿para qué?
    • ¿el Qué? 
    • y que sea el producto correcto
  • el equipo (que puede ser un proveedor externo) es responsable de la calidad técnica y funcional del producto que esta construyendo, es decir:
    •  ¿Cómo esta construido? o
    • ¿Construir el producto de forma correcta?
  • el facilitador, líder, coach, Scrum Master, Agile Coach, que acompaña a cliente y equipo es responsable de la mejora continua de ambos y de lograr la mayor fluencia, es decir, la menor fricción entre cliente, equipo, y el entorno para ser exitosos, es decir:
    • ¿Cómo interactuamos mejor?
    • ¿Cómo podemos dar mejor resultado, y más rápido?

Los ANS Sugeridos y Deseables

Con este contexto, y habiendo clarificado que la responsabilidad del equipo es sobre "como construye el producto" les comparto algunos ANS, que se sugieren y que son deseables para el mundo ágil:


Tomado de (2)

Sugeridas
  • Nivel de cumplimiento de los sprint (historias finalizadas/ historias de usuario acordadas). Valor sugerido>=80% (suponiendo que el marco de desarrollo sea Scrum)
  • Calidad de los entregables (Defectos encontrados en Producción/Pruebas unitarias y de aceptación). Valor sugerido<=10%
  • Efectividad de las pruebas (defectos encontrados en Producción/Cantidad de defectos). Valor sugerido<=10% 
  • Deuda técnica (validación estática de código). Valor a acordar 


DescripciónObjetivoFormula Medición
Unidad
Medición
Valores Aceptación
Peso
Nivel de cumplimiento en los SprintsControlar que las historias de usuario acordadas en cada sprint sean finalizadas por cada uno de los equipos(Historias de Usuario finalizadas por en cada sprint / total de Historias de Usuario comprometidas por en cada sprint) *100
%
sprint 
>= 80%
xx%
Calidad de los entregablesPromover la calidad general del producto

Cantidad de defectos encontrados en producción una vez se instale funcionalidades de un sprint 
(Cantidad de defectos encontrados / Casos de pruebas unitarias + aceptación)*100
%
sprint
<=10%
xx%
Efectividad de las pruebas  Promover la calidad general del producto

Porcentaje de defectos identificados en producción sobre el total de defectos encontrados
(Número de defectos en producción / Total de defectos en fase de pruebas (Incluido unitarias, aceptación Y Producción))*100
%
sprint
<=10%
xx%
Deuda TécnicaPromover la calidad técnica del producto

% de deuda técnica identificada por el validador estático de código
%
sprint
Valor a acordar (depende del producto)
xx%


Deseables (Depende de la madurez en DevOps de la organización contratante y el equipo de desarrollo) 
  • % de cobertura de pruebas unitarias. Valor a acordar 
  • % de cobertura de pruebas funcionales automatizadas. Valor a acordar


DescripciónObjetivoFormula Medición
Unidad
Medición
Valores Aceptación
Peso
Cobertura de pruebas unitariasPromover la calidad técnica del producto del productoCobertura de pruebas unitarias al código en %
%
sprint
>= 80%
xx%
Cobertura de pruebas funcionales automatizadasPromover la calidad técnica y funcional del producto(Total de casos de pruebas funcionales automatizados/ Total de casos de pruebas funcionales) *100
%
sprint
>=70%
xx%


Y las Penalidades

Las dejo a su consideración, realmente no estoy de acuerdo con el DPS (o Desarrollo Punitivo de Software) donde en el esquema de desarrollo tradicional o cascada se activan cantidades y cantidades de penalidades, tantas que como proveedor puedes terminar pagando económicamente al cliente cuando debería ser al contrario. Nadie se mete a hacer desarrollo de software (o a cualquier negocio) para terminar pagándole a su cliente.

Soy mas partidario de lo que comparto en la charla de contratos ágiles(3), tener esquemas de finalización anticipada, y si el cliente o el proveedor no dan la talla (el tema es mutuo), simplemente terminar la relación comercial sin penalidad alguna, con la ventaja que en el mundo ágil y específicamente con Scrum siempre tienes software de valor funcionando cada mes o menos (por lo general cada dos semanas).



Hasta acá este compartir

Saludos Ágiles

Jorge Abad


Aclaraciones, Notas, Comentarios y Referencias

  1. También conocidos como SLA - Service Level Agreement, por sus siglas en inglés.
  2. "Tips para una PMO perdida en el Mundo Ágil" - clic aquí - 
  3. Hablemos de contratos ágiles - http://www.lecciones-aprendidas.info/2019/03/contratos-agiles-reoladed.html

Un tipo de Contrato que te permitirá trabajar en mundo Ágil - Contratos Ágiles

Hola a todos

Considerando que frecuentemente me preguntan cual es el tipo de contrato que mejor se lleva con la agilidad, y le es natural al cliente trabajar con el, les comparto estos slides de mi presentación de Contratos Ágiles (clic aquí):



----

---

---



Tomado de: http://www.lecciones-aprendidas.info/2019/03/contratos-agiles-reoladed.html

Más sobre contratos ágiles en: http://www.lecciones-aprendidas.info/search/label/contratos%20agiles

Algunas definiciones de Valor


En el mundo ágil con frecuencia hablamos de:

  • Software de valor
  • Generar valor
  • productos con valor
  • generarle valor a los usuairos
A continuación les comparto algunas definiciones de Valor que he encontrado:


El Valor se define como un beneficio financiero que una organización recibe por la inversión realizada.
https://www.scrum.org/resources/blog/agile-value

Valor es la capacidad de generar beneficio económico. Para organizaciones sin ánimo de lucro es: la capacidad de generar un beneficio para la sociedad

Valor es contribuir a los objetivos de negocio 
Adaptado de https://www.linkedin.com/posts/juanandres-ochoa_agilismo-transformaciondigital-agile-activity-6576961629420863488-ycwX/

Valor es cualquier cosa que:
  • Incrementa el conocimiento 
  • Reduce el riesgo 
  • Genera retroalimentación valiosa 

Valor es cualquier cosa que:
  • Incrementa el valor del mercado 
  • Reduce el riesgo
  • Genera más capacidad de construcción 



Hasta acá este corto compartir

Saludos ágiles

Jorge Abad


lunes, septiembre 09, 2019

Tratar a las personas como personas


"In real life, the most practical advice for leaders is not to treat pawns like pawns, nor princes like princes, but all persons like persons"
- James MacGregor Burns

"En la vida real, el consejo más práctico para los líderes no es tratar a los peones como peones, ni a los príncipes como príncipes, sino a todas las personas como personas" 
. -James MacGregor Burns
---
Somos personas, no recursos.

martes, septiembre 03, 2019

Una Reflexión sobre el Costo del Retraso, DevOps y la Curva de Maersk

Hola a todos

Desde hace un tiempo vengo trabajando, e incluyendo en mis entrenamientos el concepto de Costo del Retraso (Cost of Delay), el cual desarrolló magistralmente Donald Reinertsen  en su libro The Principles of Product Development Flow, y una de sus frases más famosas es:





"Si solo puede cuantificar una cosa, cuantifique el Costo del Retraso" -Donald Reinertsen

Algunas definiciones de este concepto son:

Costo del retraso:
  • El costo del retraso es "una forma de comunicar el impacto del tiempo en los resultados que esperamos lograr". (1)
  • "¿Cuánto nos costaría si esto se retrasara 1 mes?"(1)
    • "¿Qué valdría para nosotros si pudiéramos obtener esto 1 mes antes?"(1)
    •  ¿Cuánto dejamos de ganar si nos atrasamos un mes?
    • ¿Cuánto le cuesta a la compañía por unidad de tiempo no tener una funcionalidad liberada oportunamente?



    Y justo con esta aproximación me encontré en el reporte de DevOps elaborado por DORA en https://devops-research.com/, en este informe, se observa la gráfica elaborada en Maersk por el equipo de desarrollo de un proyecto en donde se representa el costo del retraso/semana vs la cantidad de requisitos liberados en esa unidad de tiempo (del cual se infiere el Lead Time promedio del requisito). 

    En esta gráfica se visualiza el costo del retraso generado por liberar tres requisitos por semana, sumando aproximadamente 7 millones de dólares, a liberar más de 23 requisitos en ese mismo periodo de tiempo y reduciendo este costo casi a cero.


    Esta curva es asombrosa, pues genera consciencia de varios aspectos:

    • la importancia de estar generando valor de forma continua
    • el impacto en los ingresos de la organización de una estrategia de liberación pausada o continua
    • cualquier esfuerzo de mejora en el ciclo de desarrollo de software y en su proceso de liberación, conlleva a un impacto económico que puede llegar a ser exponencial.
    • la importancia de liberar continuamente para validar hipótesis y adaptarse rápidamente al mercado.
    • la capacidad de validar hipótesis en un escenario de alto rendimiento es exponencial


    Bajo este panorama surgen varias preguntas

    • ¿Su organización mide el costo del retraso de sus proyectos?¿de uno solo? ¿de todo su portafolio?¿la PMO lo hace?
    • ¿Como sería la curva costo del retraso por semana para los requisitos de tu organización o de tu proyecto?
    • La discusión sobre si Ágil-DevOps es barato desaparece, la pregunta que aparece es 


    ¿qué tan costoso te esta saliendo no ser Ágil-DevOps (Agile-DevOps)?


    • ¿cómo será la curva en los de alto performance, es decir, Google, Facebook, Amazon, Netflix, etc?


    Hasta acá este compartir

    Saludos Ágiles


    Jorge Abad

    Referencias, Comentarios, Notas y Aclaraciones


    1. https://en.wikipedia.org/wiki/Cost_of_delay