jueves, febrero 01, 2018

Unas notas sobre las preguntas

Por sus preguntas los conocereis
....
Las preguntas correctas nos llevan a la experimentación y al conocimiento
...
El cambio comienza con una pregunta
...
Sino te deja dormir, ten la seguridad que es la pregunta correcta

domingo, enero 28, 2018

Las métricas en contra del sistema

Algunos pensamientos sobre métricas, procesos y documentación

Hola a todos

Dejo por acá estos pensamientos que me dan vueltas

Sobre las métricas

  • Deben trabajar para mi y no al revés
  • deben buscar abundancia y no escasez, es decir, me ayudan a mejorar y dar salud a mi entorno, no son para generar presión y desgaste de los involucrados
  • Pocas métricas es mejor que muchas métricas

Sobre los métodos, procesos y mejora continua
  • Deben trabajar para mi y no yo para ellos
  • Los métodos, frameworks y procesos serán útiles hasta que se encuentre una mejor forma de hacer las cosas
  • la mejora continua debe llevarme tan lejos como yo lo visione
  • la vigilancia tecnológica es necesario para alimentar la mejora continua y saber referentes
  • los experimentos son claves para avanzar en la mejora continua
Sobre la documentación
  • La documentación trabaja para mí
  • Se documenta lo que genera valor

miércoles, enero 17, 2018

Una excelente definición de Valor

domingo, enero 14, 2018

Encontrando el MVP con un Roadmap y el Mapa de Afinidad

Hola a todos

Realizando talleres Producto Mínimo Viable - MVP (Minimun Viable Product), he encontrado que para cierto tipo de equipos les da dificultad emplear la técnica del User Story Map de Jeff Patton, para estos equipos he ideado esta técnica basada en el Roadmap y el Mapa de Afinidad, espero les guste y también les sirva con sus equipos.

Saludos Ágiles

Bienvenido el Feedback
Jorge H. Abad L.

sábado, enero 13, 2018

Unos tips y preguntas poderosas para encontrar el MVP


A continuación a compartir algunos tips y preguntas que hemos encontrado con varios Agile Coaches (Lucho Salazar @LuchoSalazarC, Pablo Mejía  @pmejia73) que te pueden ayudar a en
  • Siempre busque paretos, cual es el 20% del sistema que generaría un 80% de valor o impacto en el negocio.
  • Identifique cuál o cuáles son los criterios claves para la selección del MVP (4)
  • ¿Si me voy del proyecto qué es lo mínimo que quiero dejarle?
  • si es una migración o reconstrucción de un sistema
    •  ¿cuales son las funcionalidades que registran más uso del sistema? 
    • ¿agrega valor volver a construir lo que se dejó de usar o lo que nunca se ha usado?
  • Imagine el dinero es suyo, o que le darán un premio por invertir la menor cantidad de dinero
  • ¿Cual es la mínima funcionalidad que comienza a resolver el problema de negocio?
  • ¿Y si le recortaran el dinero al proyecto a la mitad?¿y la mitad de esa mitad?
    • ¿que sería lo mínimo que usted podría dejarle al proyecto si quiere dejar una gran impresión pero tiene esta restricción de dinero?
  • ¿Y si le recortaran el tiempo al proyecto a la mitad?¿y la mitad de esa mitad?
    • ¿que sería lo mínimo que usted podría dejarle al proyecto si quiere dejar una gran impresión pero tiene esta restricción de tiempo?


Hasta acá este pequeño compartir
Bienvenido el feedback


Saludos Ágiles
Jorge Abad


Notas, Referencias, Comentarios, Aclaraciones


  1. Minimísimo Producto Viable - PRAGMA - Pablo Mejía - Mínimo producto viable - ágil - https://es.slideshare.net/PabloMejaArbelez/minimisimo-producto-viable-pragma-pablo-meja
  2. How to Split a User Story - http://agileforall.com/resources/how-to-split-a-user-story/
  3. Sí, Mínimo Producto Viable ¿Pero en qué contexto? - http://www.lecciones-aprendidas.info/2016/10/si-minimo-producto-viable-pero-en-que.html
  4. Criterios de Selección del Mínimo Producto Viable - http://www.lecciones-aprendidas.info/2018/01/criterios-de-seleccion-del-minimo-producto-viable.html

Criterios o Patrones de Selección del Mínimo Producto Viable



Muchas veces elegir o encontrar el Mínimo Producto Viable (MVP - Minimun Viable Product) no es un ejercicio fácil para el Dueño del Producto y sus interesados (o stakeholders), en ocasiones se deben revisar criterios de negocio, criterios técnicos, o tal vez se requiera de un análisis multi-objetivo que ayude a determinar cual es el valor que se quiere entregar en la primera versión del producto. A continuación les comparto algunos criterios:

  1. Validar una hipótesis de negocio con el mercado. Es la común para las startups, buscando obtener el máximo aprendizaje.
  2. Validar un pedazo riesgoso de una solución
  3. Primero lo más barato
  4. Lo que menos cuesta
  5. Lo que implique el mayor ahorro en el proceso
  6. Primero una una tecnología específica y luego el resto, ejemplo primero construir la solución para Android y luego para iPhone
  7. Automatizar una parte del proceso y luego el resto
  8. Lo que me comience a resolver el problema de negocio más rápidamente
  9. Primero ciertos roles claves y luego otros
  10. Las reglas de negocio de mayor impacto primero y luego las otras
  11. Primero el camino feliz y luego las excepciones
  12. Construir para una segmentación de datos y luego para los otros, ejemplos: compradores frecuentes y luego compradores de ciertos productos.
  13. La operación del sistema que me permita obtener mayor valor
  14. (Si el criterio es performance) Primero construir la solución con desempeño normal y luego llevarla al alto desempeño
  15. Eliminando el riesgo regulatorio o minimizando su impacto
  16. Minimizar multas o sanciones
  17. Lo que más ingresos me produzca
  18. Lo que mínimo que me permita igualar uno o varios servicios de mi competencia.
  19. En una migración: lo más usado y luego lo menos



Hasta acá este pequeño compartir, si encuentran más criterios no dudes en hacer su aporte en la zona de comentarios, los citaré respectivamente.

Bienvenido el feedback

Saludos Ágiles
Jorge Abad




Notas, Referencias, Comentarios, Aclaraciones


  1. Minimísimo Producto Viable - PRAGMA - Pablo Mejía - Mínimo producto viable - ágil - https://es.slideshare.net/PabloMejaArbelez/minimisimo-producto-viable-pragma-pablo-meja
  2. How to Split a User Story - http://agileforall.com/resources/how-to-split-a-user-story/
  3. Sí, Mínimo Producto Viable ¿Pero en qué contexto? - http://www.lecciones-aprendidas.info/2016/10/si-minimo-producto-viable-pero-en-que.html

jueves, diciembre 28, 2017

Tipos de Salida de una Retrospectiva



Hola a todos

Hace un tiempo leí un gran post de  Damian Buonamico - Retrospectivas Ágiles: No sólo Accionables - que referencio frecuentemente en mis entrenamientos de Scrum, en el Damian explica que de toda retrospectiva hay como resultado

  • Tareas (o acciones)
  • Acuerdos de equipo 
En esa misma taxonomía yo quisiera añadir, como muchos ya lo han expresado un tercer elemento que no pueden perder de vista los equipos ágiles,
  • Los experimentos
Basado en lo anterior, entremos pues en  las definiciones:

Las tareas: son acciones que tienen inicio y fin, y un resultado claramente definido, ejemplos
  • Migrar de servidor la base de datos pues su memoria se esta copando
  • Actualizar la versión del framework
  • Mover el tablero de ubicación
  • Crear un tablero kanban para mejoras
Las tareas dentro del framework de Cynefin se encontrarian en el terreno de lo Obvio (1)

Los acuerdos: son conductas, políticas, actividades o procesos que un equipo decide realizar frente a diferentes circunstancias, ejemplos:
  • De ahora en adelante después del planning los PO y los testers se reunirán a identificar cual va a ser la estrategia de pruebas del sprint.
  • Si alguien va a salir temprano por alguna razón laboral o no, deberá pedirle autorización al equipo y garantizar que el equipo queda enterado sobre los pendientes, acciones a realizar y la persona queda localizable para solucionar alguna duda.
Los acuerdos dentro del framework de Cynefin se encontrarian en el terreno de lo Obvio (1)

Los experimentos:  Aunque podrían ser tareas, su resultado no es predecible y  puede ser apropiado, inapropiado, o indiferente para el equipo.

Es recomendable que para todo experimento se tenga:
  • Responsable
  • Fecha o cuando se ejecutará
  • Resultados esperados
  • Resultados obtenidos
Algunos ejemplos de experimentos pueden ser:
  • Probar pomodoro como técnica para gestión del tiempo del equipo
  • Determinar si el uso de un determinado framework acelera o reduce la velocidad de desarrollo
  • Realizar pair programming y validar si la tecnica es adoptada por el equipo o no.
Los experimentos dentro del framework de Cynefin se encontrarian en el terreno de lo Complejo (1).

Unas últimas sugerencias

  • Es importante recalcar que por lo genera toda mejora se da en el plano de la personas, procesos o herramientas (2)
  • Y aunque algunas mejoras sean tareas o acuerdos, es bueno redactarlas a nivel de experimentos para validar si su uso fue fructífero o no



Este es la taxonomía que hasta el momento he identificado, bienvenido el feedback.


Saludos ágiles y un exitoso 2018

Jorge Abad


Notas, Referencias, Comentarios, Aclaraciones

  1. Hablemos de la Complejidad, la Gestión de Proyectos y Cynefin - clic aquí para ver- 
  2. Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo  -clic aquí para ver-.

El Cambio en la Guía de Scrum: Asegurando que el Equipo Mejore



Hola a todos

Este año vimos cambios en la guía de Scrum que se enumeran en este post: Revisión a la Guía de Scrum 2017 de Lucho Salazar. pero dentro de los cambios que más me gustan es que se evidencie la necesidad de priorizar la mejora como un elemento clave del Sprint Backlog, de forma que el equipo no lo pierda de vista y logre mejorar sprint tras sprint.


El texto de la guía reza de la siguiente forma:

"Para asegurar el mejoramiento continuo, la Lista de Pendientes del Sprint incluye al menos una mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente anterior" - La Guía de Scrum

Este texto se podría ilustrar como


De esta forma se observa que:
  1. Se garantiza que los equipos realmente mejoren, antes aunque esta practica era conocida como "Scrumming the Scrum" - Propuesta por Jeff Sutherland -(1), no era manejada por todos los Scrum Master.
  2. Se obtiene que en los equipos sprint tras sprint "algo" cambiará, algo mejorará, logrando que las prácticas, acuerdos, accionables sean completamente diferentes entre el sprint 5 y el 25
  3. Que se destine tiempo efectivo dentro del sprint a la mejora, lo que implica que una o varias personas durante el sprint tomaran tiempo laboral y harán algo que esperan que mejore los resultados del equipo, aclaro:
"La mejora debe hacerse en horario laboral, no es un trabajo extra, y bien realizada le agrega calidad, velocidad, felicidad y desempeño al equipo"

Ahora respecto a esto unos consejos
  1. No priorice demasiadas acciones de mejora, mi consejo es que sea entre 1 y 3 acciones de mejora, (las más importantes) de forma que identifiques que acciones fueron las que cambiaron la dinámica del equipo.
  2. La(s) mejora(s) debe tener la máxima prioridad dentro del sprint backlog, sino se diluirá en el día a día. El Scrum Master debe cerciorarse que estas mejoras se realicen sprint tras sprint. 
  3. Las mejoras pueden darse dentro del campo de los procesos, las personas o herramientas (2). Estas mejoras realizadas de forma priorizada, sistemática y orientada por el scrum master puede llevar al equipo a realizar un salto cuántico en su desempeño, resultados y generación de valor.
  4. Es una buena práctica que las mejoras tengan 
    • Responsable(s)
    • Fecha o cuando se realizarán durante el sprint
    • Resultado Esperado
    • Resultado Obtenido

Hasta acá este compartir

Saludos ágiles

Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias

  1.  Seis (6) estrategias para lograr mayor velocidad de los equipos en Scrum - clic aquí para ver- 
  2.  Scrum Master: Cómo Continuar la Mejora Continua de tu Equipo  -clic aquí para ver-.



domingo, diciembre 10, 2017

Un Cuarto Método para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning





Hola a todos

Hoy quisiera compartir un cuarto método de los tres anteriormente compartidos en el post "Tres Métodos para Estimar la Velocidad (capacidad) de un Equipo Scrum en el Primer Planning" - (clic aquí para leerlo).

Es muy parecido al ojo de buen cubero.

El proceso es sencillo


  1. Se toma una historia de usuario que todo el esfuerzo (1) requerido para construirse tome entre uno y dos  días-persona (o sea, si sumas todas las horas usadas para construir la historia de usuario sin considerar tiempos muertos tome entre uno y dos días) - Consejo: entre más cercano a un día de esfuerzo es mejor - de ahora en adelante esa será la historia pivote (2) y tendrá el tamaño de un punto
  2. Luego pregúntale al equipo. ¿cuántas historias pivote o de un punto son capaces de hacer en un sprint?
  3. El equipo hará su estimación y dirá por ejemplo somos capaces de hacer 20 de esas.
  4. Ok, acabas de tener la capacidad de tu equipo
  5. Ahora si, con esta información comienza el planning y compara todas las historias con respecto a la historia de usuario pivote, preguntando por ejemplo ¿esta nueva historia es 1,2,3,5,8 veces la historia pivote?, El equipo realizará planning póker y sumaras los puntos hasta que llegues a un número cercano a 20.
Otro punto importante a tener en cuenta, también determina cual es tamaño máximo que el equipo puede aceptar de historia de usuario, es decir
  • Si el sprint es de 2 semanas, es decir 10 días hábiles, y 8 de ejecución quitando las reuniones de planning, dailys, refinamiento, review, retrospectiva
    • si la historia es de aproximadamente 1 día, el tamaño máximo deberá ser 8 puntos, 13 puntos sería imposible de lograr
    • si la historia es de aproximadamente 2 días, el tamaño máximo deberá ser 5 puntos (y eso con un alto riesgo de no lograrse)
Y recuerda una buena práctica es que tu sprint backlog tenga entre 6 a 10 historias de usuario de similar tamaño

Hasta acá este corto compartir.

Saludos Ágiles 

Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias

  1. Esfuerzo es diferente a Duración, algo te puede tomar 2 días de esfuerzo pero la duración puede ser 3 pues hay tiempos muertos entre una tarea y otra hasta completar la historia de usuario
  2. Hace un tiempo realice una tabla de tamaño de historias de usuario de acuerdo al tamaño del sprint (http://www.lecciones-aprendidas.info/2017/05/Tamanos-sugeridos-de-historias-de-usuario.html ), cada vez me convenzo más que deben ser lo más pequeñas posibles. 

viernes, noviembre 17, 2017

martes, noviembre 07, 2017

Leído y Recomendado: Revisión a la Guía de Scrum 2017

Hola a todos

Les comparto esta interesante reseña sobre la actualización a la Guía de Scrum, publicada hoy el 7 de noviembre de 2017 elaborada por Lucho Salazar en su famoso blog Gazafatonario IT:

Este es el link de webinar de los autores: Scrum Guide Revision Webinar
Este es el link de las diapositivas de los autores: View or Download the Scrum Guide Revision Slides


Link de artículo original: http://www.gazafatonarioit.com/2017/11/revision-la-guia-de-scrum-2017_7.html

Revisión a la Guía de Scrum 2017



Cambios entre las Guías Scrum de 2016 y 2017


1. Adicionada sección sobre los Usos de Scrum:

Scrum fue desarrollado inicialmente para gestionar y desarrollar productos. Desde principios de los años 90 Scrum se ha usado ampliamente en todo el mundo para:
1.       Investigar e identificar mercados viables, tecnologías y capacidades de productos;
2.       Desarrollar productos y mejoras;
3.       Liberar productos y mejoras tantas veces como sea posible durante el día;
4.       Desarrollar y mantener ambientes en la Nube (en línea, seguros, bajo demanda) y otros entornos operacionales para el uso de productos; y
5.       Mantener y renovar productos.

Scrum se ha usado para desarrollar software, hardware, software embebido, redes de funciones interactivas, vehículos autónomos, escuelas, gobiernos, mercadeo, también para gestionar la operación de organizaciones y casi todo lo que usamos en nuestra vida diaria, como individuo y como sociedad.

Dado que la complejidad de la tecnología, el mercado y del entorno y sus interacciones aumentan rápidamente, la utilidad de Scrum para tratar con la complejidad está a prueba diariamente.
Scrum demostró ser especialmente efectivo en la transferencia iterativa e incremental de conocimiento. Scrum se usa ahora ampliamente para productos, servicios y gestión de la organización matriz.

La esencia de Scrum es un pequeño equipo de personas. El equipo individual es altamente flexible y adaptativo. Estas fortalezas continúan operando en un equipo, en varios, en muchos y en redes de equipos que desarrollan, liberan, operan y mantienen el trabajo y los productos de trabajo de miles de personas. Ellos colaboran e interoperan a través de arquitecturas de desarrollo sofisticadas y ambientes finales de liberación.
Cuando las palabras “desarrollar” y “desarrollo” se usan en la Guía de Scrum, se refieren a trabajo complejo, tales como estos identificados anteriormente.


2. Modificada la redacción en la sección El Scrum Master para proporcionar una mayor claridad al rol. El texto ahora dice:

El Scrum Master es responsable de promover y apoyar Scrum como se define en la Guía de Scrum. Los Scrum Masters hacen esto ayudando a todos a entender la teoría, prácticas, reglas y valores de Scrum.

El Scrum Master es un líder que está al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser útiles y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.


3. Adicionado a la sección El Scrum Master al Servicio del Dueño de Producto

Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo Scrum de la mejor manera posible


4. Actualizado el primer párrafo de la sección Scrum Diario para que se lea:

El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo. El Scrum Diario se lleva a cabo cada día del sprint. En él, el Equipo de Desarrollo planea el trabajo para las siguientes 24 horas. Esto optimiza la colaboración y el desempeño del equipo inspeccionando el trabajo avanzado desde el último Scrum Diario y haciendo una proyección del trabajo del Sprint a realizar a continuación. El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad.


5. Actualizada la sección Scrum Diario para proporcionar claridad sobre los objetivos del Scrum Diario incluyendo este texto:

El Equipo de Desarrollo es el encargado de establecer la estructura de la reunión y esta se puede conducir de diferentes maneras si se enfoca en el progreso hacia la Meta de Sprint. Algunos Equipos de Desarrollo usarán preguntas, algunos se basarán más en discusiones. Aquí hay un ejemplo de lo que podría usarse:

·         ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
·         ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
·         ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?


6. Adicionada claridad sobre los bloques de tiempo (time-boxes)

Usando las palabras “a lo sumo” para eliminar cualquier pregunta relacionada con que los Eventos tengan que ser de cierta duración y, en cambio, esos son los tiempos máximos asignados.


7. Adicionado a la sección Lista de Pendientes del Sprint (Sprint Backlog):

Para asegurar el mejoramiento continuo, la Lista de Pendientes del Sprint incluye al menos una mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente anterior.


Adicionada claridad a la sección Incremento:

Un incremento es un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo al final del Sprint. El incremento es un paso hacia una visión o meta.



Descarga la guía actualizada en Español:

Puedes hacerlo directamente de:

http://www.scrumguides.org/download.html

viernes, noviembre 03, 2017

Un Horrendo y Horroroso Scrum



Hola a todos

Reciente pasamos el Hallowen y quisiera compartir algo que me asusta de muchas implementaciones y adopciones de Scrum.

Comencemos

Durante mucho tiempo en mis entrenamientos de Fundamentos de Scrum comparto el siguiente texto de Tobias Mayer (https://agileanarchy.wordpress.com/scrum-a-new-way-of-thinking/) con los asistentes:



"Imaginen si nuestros días en el trabajo estuviesen llenos de sonrisas y sentimientos de compañerismo y llenos de emoción. Imaginen un espacio de trabajo que se remontan a patios de la infancia, donde la invención  y la innovación eran una parte natural de cada interacción. Imaginen que es responsable de su propio entorno, su propio ritmo y su propia carga de trabajo.  E imaginen entregar con frecuencia un trabajo de calidad con  a unos clientes encantados y relajados. Se puede convertir esa imaginación en realidad. Existe un mecanismo simple y bien entendido para ir desde donde estás ahora a donde le gustaría estar, y no, ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes." Tobias Mayer

Y la verdad cuando lo comenzamos a leerlo, todos creemos que vamos a terminar diciendo "sí, si es Scrum, es la bala de plata que siempre habías buscado y que va a solucionar todos tus problemas" y el texto termina muy clara y contundentemente "ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes."

somos nosotros y no el framework los encargados de cambiar nuestra forma de trabajo, el framework ayuda, pero podemos aún teniendo Scrum como forma de trabajo situaciones que dan espanto:
  • Product Owners o Scrum Masters que son los jefes de los equipos y los presionan y exprimen y los tratan como "recursos"
  • Scrum Master que solo se preocupan de agendar reuniones y no se ocupan de la mejora continua de su equipo, ni de su PO
  • Equipos en los que no se entienden (para ser sincero, realmente no son equipos)
  • Equipos con deuda técnica creciente y sin herramientas adecuadas
  • Equipos que no tienen buenas herramientas y no están orientados a la excelencia técnica
  • Equipos con muchos sprints encima y sin salir a producción
  • Equipos sin retrospectivas
  • Equipos con dailys de seguimiento estricto y no de sincronización
  • Equipos Scrum donde se gestionan las horas y las estimaciones y en los que "toca reponer el tiempo si se falla una estimación"
  • Equipos Scrum trabajando bajo un contrato de alcance fijo, tiempo fijo y costo fijo (todo fijo)
  • Metricas de cascada aplicadas a proyectos ágiles
  • Product Backlog al cual se le hacen frecuentes controles de cambio
  • Planning asignadas previamente por el PO (y posiblemente un líder técnico)  y no estimadas por el equipo
  • y muchas más
Lo anterior muy coincidente con la frase de Ken Schawber
“En Scrum, un grupo en el que se lleven mal entre ellos, no comprendan el negocio del cliente y trabajen con malas herramientas... también producirán incrementos periódicos... de basura.(1) ” Ken Schawber




Da pavor ver estas situaciones, y es nuestra labor como Scrum Masters como Agile Coaches trabajar con la organización y los equipos para generar entornos de trabajo diferentes, y cierro como dice Tobias "ese mecanismo no es Scrum. Eres tú. Son ustedes. Cada uno de ustedes." 

Bienvenido el feedback, los comentarios y las historias de terror.


Saludos Ágiles

Jorge Abad

Notas

1. Creo que Ken hubiera querido terminar esta frase con una palabra más contundente

viernes, octubre 27, 2017

Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.(parte 2)


Imagen de la película: ¿Dónde está el piloto? - Idea de mi amigo Wilmar Hincapie



Hola a todos

En el pasado Ágiles 2017 en Chile, hablando con Leonardo Agudelo (@sweepnoise) sobre los proyectos piloto, me hacía ver que no solo eran importantes los puntos del artículo anterior (mira la primera parte de este artículo - Clic aquí):
  • 3 a 4 meses de duración
  • Con 1 a 4 equpos de trabajo
  • Importante para la organizaicón
  • Patrocinio ejecutivo
  • La gente correcta
  • Dominio de la tecnología
Sino que era necesario revisar el manifiesto ágil buscando los elementos para cumplirlo y para generar el ambiente propicio para que germine la agilidad, a continuación les comparto este análisis y algo de mi experiencia:
  • Crear un contrato que permita la agilidad, seamos sensatos un contrato con todo fijo -alcance, tiempo y costo fijo- no nos permitirá tener éxito. (ver sobre contratos agiles - clic aquí- )
  • No usar las tipicas métricas de cascada (CPI, SPI) para medir el proyecto (es un desastre tratar de acomodar ágil a esto - se los digo por experiencia)
  • Permitir el cambio como parte natural del proceso (he observado que en proyectos que quieren hacer ágil, siguen con la política de control de cambios --¡¡OMG!! NO SE IMAGINAN EL DOLOR DE CABEZA. es necesario archivar este proceso para poder hacer el piloto)
  • Cambiar las métricas de la evaluación de desempeño de las personas que participaran (es decir, en cascada a un analista le daban una buena calificación si tenía pocos controles de cambio, si este analista se va para el piloto de ágil, las historias de usuario las grabará sobre piedra - y me ha pasado -)
  • Requerir que el negocio este involucrado y contar con su participación al 100% (con el ROL de Product Owner o de Interesado clave)
  • Que exista la comunicación cara a cara (todos en el mismo sitio , co-location)
  • Crear las excepciones - válidas a los procesos organizaciónales - que permitan la agilidad
    • Prioridad en los despliegues
    • Prioridad en los controles de cambio de ambiente
    • Prioridad en las autorizaciones
    • etc

Cerrando

Ya hemos perdido mucho tiempo y dinero haciendo proyectos en cascada, démosle la oportunidad a ágil, pero bajo las condiciones para que este tenga éxito, sino no tiene sentido.



Alguna otra recomendación

No dudes en compartirla en la zona de comentarios.

Bienvenido el feedback




Saludos ágiles
Jorge Abad




jueves, septiembre 28, 2017

¿Dónde está el problema?¿Por qué mi equipo Scrum falla continuamente sprint tras sprint?





Hola a todos

Muchas veces al visitar equipos de trabajo me encuentro con Scrum Masters en los que su equipo lleva continuamente fallando con los puntos comprometidos sprint tras sprint, y por lo general corresponden a ciertas sintomatologías.

A continuación voy a presentar algunas de las posibles causas raíz y posibles formas de solución, espero esta lista te sea útil al momento de diagnosticar a tu equipo si está atravesando por la misma situación:



Posibles razones Consecuencia y Posible Soluciones

  • Equipos Inestables
  • Cambio frecuente de team members
  • Continua renuncia de team members
Consecuencia: Pérdida constante de conocimiento y reinicio de la dinámica del equipo.

Posible(s) Solución(es):
  • Hablar con los líderes de la organización buscando remover la causa del constante cambio de personas, esto muy probablemente se debe a creer que el equipo esta compuesto por recursos que pueden remover e ingresar sin ningún problema e impacto.
  • Solicitarle al equipo confíe ante la crisis que se está presentando, que se va a remover la causa raíz que esta generando la renuncia continua de los miembros del equipo, y cumplir lo prometido al equipo.

  • Team members a tiempo parcial
Consecuencia: Pérdida de foco de los team members generando desgaste en tiempo para volver a entender el contexto del proyecto.(Esto sucede cuando las organizaciones creen que hacer muchas cosas al tiempo es mejor que hacer una cosa bien hecha a la vez. Es mejor llevar proyectos a los equipos que armar equipos para los proyectos)

Posible(s) Solución(es):
  • Hablar con la organización y solicitar la estabilización de los miembros del equipo donde al menos el 80% este a dedicación a tiempo completo. 

  • La tecnología es desconocida o nueva para el equipo
Consecuencia: Por más buena intención que tenga el equipo no se cumplen los compromisos pues no sabe como solucionar los diferentes tipos de retos que implica la tecnología.

Posible(s) Solución(es):
  • Entrenar correctamente al equipo en la tecnología y darles el suficiente tiempo para que la dominen y maduren.
  • Traer team member expertos para que hagan programación por pares con ellos y haga transferencia de conocimiento.
  • cambiar de tecnología por una que domine el equipo

  • Estamos en un entorno de completa incertidumbre con la tecnología, aunque la dominamos estamos haciendo cosas completamente innovadoras. (Común en equipos de investigación)
Consecuencia: Las estimaciones no se cumplen pues no se sabe con certeza si se logrará el resultado esperado.

Posible(s) Solución(es):
  • No presionar al equipo, proveerles un entorno de aprendizaje, olvidándose si se logra o no los puntos comprometidos y tener metas pequeñas alcanzables (al menos en teoría), y permitirles fallar.

  • Hay presión por parte del cliente, product owner o el scrum master (en el peor de los casos) en el planning y el equipo debido a esta presión  se sobrecompromete
Consecuencia: El equipo se sobrecompromete por temor a los "jefes"

Posible(s) Solución(es):
  • Es muy probable que ni el cliente, ni el Product Owner, y con mayor razón el Scrum Master, no entiendan que Scrum es: "Tiempo fijo - Alcance Variable" y que la presión sobre lo entregado solo va a generar una continua fatiga de todos por tener expectativas irreales. Recomiendo este post: [Scrum] Ritmo Sostenible sobre Ritmo Insostenible (clic aquí)

  • El equipo está constituido por novatos o son demasiado optimistas al hacer las estimaciones
Consecuencia: El equipo se sobrecompromete ignorando muchos elementos técnicos debido a su baja experiencia en el producto o en la(s) tecnología(s) involucrada(s).

Posible(s) Solución(es):
  • Sugiero que los equipos estén constituidos al menos con la mitad de las personas con experiencia, de manera que les enseñen (haya transferencia de conocimiento) y ellos permitan ver aspectos ignorados por los novatos o aprendices.

  • Infraestructura inestable
Consecuencia: Los compromisos hechos se vienen al suelo por los impedimentos de la infraestructura.

Posible(s) Solución(es):
  • Estabilizar cuanto antes la infraestructura, si es posible destinar tiempo del equipo a hacerlo.

  • El tamaño del sprint es demasiado pequeño para generar valor.
Consecuencia: Las historias de usuario continuamente no alcanzan la Definition of Done (DoD).

Posible(s) Solución(es):
Muchas veces cuando la tecnología tiene muchas capas es costoso alcanzar la DoD en un Sprint, para esto sugiero, las siguientes soluciones


  • Impedimentos y/o desenfoques excesivos en el sprint
Consecuencia: Los frecuentes problemas frecuentes no permiten lograr el foco en el sprint.

Posible(s) Solución(es):
  • Dividir el equipo, o tener otro adicional enfocado en los "desenfoques"
  • Estabilizar el entorno 
  • Detener el proyecto hasta que el entorno esté estabilizado

  • Un producto con mucha deuda técnica
Consecuencia: Cualquier estimación es dañada por la mala calidad del producto en la que se está trabajando. (Recomiendo este post : Hablemos de Deuda Técnica - clic aquí-)

Posible(s) Solución(es):
  • Identificar y remover la deuda técnica y constituir este esfuerzo como trabajo a realizar durante el sprint.
  • Liberar al equipo de las estimaciones de forma que pueda construir producto y a la par remueve la deuda mínima necesaria que les permita trabajar.

  • Las historias de usuario son demasiado grandes
Consecuencia: El equipo falla constantemente sus estimaciones, impidiendo encontrar la Definition of Done (DoD) al final del Sprint

Posible(s) Solución(es):

  • Las historias de usuario no están cumpliendo la Definition of Ready (DoR), es decir son aceptadas por el equipo aun sin tener sus definiciones y dependencias resueltas
Consecuencia: Las historias de usuario tiene demasiadas sorpresas y trabas en el camino, implicando que no se cumpla el compromiso.

Posible(s) Solución(es):

  • El equipo acepta historias de usuario que no tienen sus dependencias construidas. 
Consecuencia: Las historias de usuario tiene demasiadas sorpresas y trabas en el camino, implicando que no se cumpla el compromiso.

Posible(s) Solución(es):
Esto sucede cuando existen otros equipos que proporcionarán insumos y estos no son entregados a tiempo al equipo.

  • El Product Owner cambia las historias de usuario durante el sprint aumentándoles el tamaño asociado a las mismas
Consecuencia: Las historias de usuario tiene demasiadas sorpresas  implicando que no se cumpla el compromiso.

Posible(s) Solución(es):
  • Educar al Product Owner y no aceptar estos cambios en las historias, postergándolos para el siguiente sprint.

  • El Product Owner esta cambiando las prioridades durante el Sprint
Consecuencia: No es posible cumplir un compromiso si las prioridades cambian constantemente.

Posible(s) Solución(es):
  • Educar al Product Owner y no aceptar estos cambios en las historias, postergándolos para el siguiente sprint.
  • No usar Scrum como forma de trabajo, tal vez sea mejor Kanban.

"Cualquier parecido con la coincidencia es pura realidad"


Ahora para ser sincero, la no identificación oportuna de estas causas es responsabilidad del Scrum Master.(les recomiendo este post: El Paciente se Enferma de lo que el Médico Sabe. Una Invitación a no Detenerse en el Proceso de Aprendizaje -clic aquí-)


Si tienen más razones y posibles soluciones, bienvenidas sean en la zona de comentarios.

Comos siempre, bienvenido el feedack.

Saludos Ágiles

Jorge Abad

jueves, septiembre 14, 2017

Es inútil, no trates de uniformizar tus equipos Scrum

Hola a todos

Algunos de nosotros hemos tenido la experiencia de empezar en un equipo Scrum desde cero, ya sea como Product Owner, Scrum Master o Team Member, y hemos intentado traer prácticas que hemos aprendido (y que nos han funcionado muy bien) en otros equipos pero en este:
  • no son acogidas, 
  • las usas pero no tienen el mismo impacto.
  • las usan y pronto las desechan

Lo cierto, es que cada equipo es un universo único de relaciones únicas entre sus integrantes y aunque empezaramos dos equipos con el mismo scrum master el mismo día y para el mismo producto, es muy probable que pronto (al segundo sprint - tal vez-) comiencen a existir diferencias entre las prácticas adoptadas, pues cada equipo (de acuerdo a su inteligencia colectiva) en las retrospectivas o en el avanzar de los sprints encuentra:
  • accionables
  • acuerdos
  • experimentos y 
  • prácticas
Que le son útiles en su contexto único, para esos integrantes en ese momento del tiempo y para nadie más.

Por lo tanto, y cerrando rápido esta corta reflexión
  • lo que le sirve a un equipo, no tiene necesariamente por que servirle a otro
  • (igual en las organizaciones) lo que le sirve a una organización no tiene necesariamente por que servirle a otra
  • cada equipo es un mundo diferente
  • los equipos van encontrando su propia forma particular de responder al contexto y es deber del Scrum Master guiarlos en este reto.
  • es necesario hacer inspección y adaptación para ir respondiendo al entorno complejo
y la obvia
  • es inútil tratar de uniformizar tus equipos scrum.

Hasta acá esta corta reflexión, bienvenido el feedback y tus experiencias en la zona de comentarios.

Saludos ágiles
Jorge Abad


Notas


  • Me he encontrado con equipos a los cuales les funciona bien el burdown y otros no, se contentan con el kanban.
  • Este post no va en contra de las prácticas definidas por la organización, en ese caso los equipos trabajan con los artefactos, y herramientas asignadas por la organización, es más dirigido a nuestro es fuerzo de copiar y pegar indiscriminadamente sin ningún contexto.


martes, agosto 29, 2017

Datos reales comparativos entre un proyecto construido en Cascada y otro con Scrum

Hola a todos

Uno de los datos que más carecemos en nuestra industria es datos comparativos entre Cascada y Scrum basados en el mismo proyecto, tal vez por que transparentan ineficiencias de un modo de trabajo que por años defendimos todos (yo el primero) y que va de salida en el mundo del desarrollo de software a la medida.

A continuación les comparto datos de un proyecto real, correspondiente a una empresa radicada en Colombia, espero poder en un futuro cercano contar con las autorizaciones poder publicar las referencias exactas.


Espero les sea de utilidad.


Saludos ágiles

Jorge Abad