miércoles, noviembre 30, 2016

Tengo un proyecto en cascada y quisiera agilizarlo (1)



Hola a todos

Muchas veces cuando comparto en entrenamientos sobre Scrum o Agile, o en conversaciones con gerentes, gerentes de proyecto, sale la siguiente pregunta a relucir:

- [Cliente] Ok, genial, podemos adoptar esto de ÁGIL o SCRUM en el siguiente proyecto, pero 

¿que hacemos para agilizar los proyectos existentes que tenemos en cascada?

Lo que recomiendo es ensayar AGILIDAD ORGÁNICA (http://www.lecciones-aprendidas.info/2015/08/scrum-organico.html), que consiste en promover la agilidad de una forma natural y con feedback del entorno en que se encuentra inmerso el equipo o el proyecto.

Una posible secuencia de pasos a seguir para la agilidad orgánica sería:
  1. Existe un agente de cambio ágil - facilitador(2) - (que luego será el scrum master, o como deseen llamarlo)
  2. Propone al equipo hacer retrospectivas semanales o máximo cada 2 semanas (ver acá una guía de como realizar un retrospectiva - http://www.lecciones-aprendidas.info/2016/11/agenda-scrum-pasos-para-realizar-la.html - )
  3. En la retrospectiva el facilitador se enfoca en lo que más le duele al equipo (este enfoque se basa en encontrar dolores e ir sanándolos - Pain Driven Facilitator) y proponer un cambio, un experimento, y en la siguiente retrospectiva revisar el resultado del experimento.
  4. Un ejemplo, el facilitador en un momento apropiado propone como experimento para el próximo ciclo incorporar el Daily, y pregunta en luego del ciclo beneficios que observaron en este.
  5. Luego se preguntan sobre más dolores y se van incorporando prácticas, procesos o acuerdos  que el equipo las va "amando" pues fueron soluciones a sus problemas, que ellos mismos encontraron.
luego me dicen

- [Cliente] Perfecto, ¿y que hacemos con las entregas y los entregables?

mi propuesta ante esta situación es:
  1. Reprioricen las funcionalidades que están solicitando o esperando (3) en orden del valor que le pueden dar al negocio
  2. Hagan cascada de máximo dos meses, es decir, traten de generar u obtener valor lo antes posible de forma que se minimice el riesgo, esto lo logran reduciendo los tiempos de entrega de software con valor (software en el ambiente que será entregado el producto, ya sea en ambiente de calidad o preproducción, según el caso) al menor tiempo posible, 1 mes, 2 meses (exagerando 3 meses), de forma que ustedes puedan dar o recibir feedback sobre el producto y reaccionar sobre el mismo.
  3. Identifiquen si es obligatorio seguir con ciertos documentos y entregables que solicitan, o tienen la alternativa de volver el proceso más liviano, enfocándose en los que les generan más valor al proyecto. Es importante negociar este aspecto con la contraparte.

y la última pregunta

- [Cliente] ¿y los proyectos que tenemos muy adelantados?

respondo
  1. El punto final anterior se conserva igual: Identifiquen si es obligatorio seguir con ciertos documentos y entregables que solicitan, o tienen la alternativa de volver el proceso más liviano, enfocándose en los que les generan más valor al proyecto. Es importante negociar este aspecto con la contraparte.
  2. Realicen agilidad orgánica, pues la retrospectiva siempre será el motor de la mejora continua sin importar en que punto estemos del proyecto
  3. Y dentro de la agilidad orgánica habiliten el Daily que es valioso para dejar de trabajar como islas y comenzar a ser equipo.
Hasta acá este pequeño compartir, bienvenido el feedback.


Saludos ágiles

Jorge Abad



Notas, Referencias, Comentarios y Aclaraciones

  1. Este post podría llamarse también: "AGILIZANDO PROYECTOS EN CASCADA"
  2. Es importante que este facilitador conozca de prácticas ágiles para ir orientando al equipo en su proceso de agilización, recordemos El Paciente se Enferma de lo que el Médico Sabe
  3. Esto es, dependiendo si es cliente o proveedor quien hace la pregunta.

sábado, noviembre 26, 2016

¿Vale la pena ser precisos a la hora de escribir una historia de usuario?

Hola a todos 

Este tema es un pendiente a resolver de los entrenamientos y equipos a que he tenido la fortuna de acompañar.

En los entrenamientos de ágil se insiste en la necesidad de la conversación cara a cara, tanto cuando se explica el manifiesto agil, como cuando se "juega" la construcción del requisito especificado y el colaborativo (1).

Y los creadores del concepto de historias del usuario invitan a maximizar el contacto entre el usuario (o Product Owner,  en el caso de Scrum) y el equipo teniendo la excusa de una "necesidad" mal especificada.

Algunas frases de estos referentes son.
  • No sigamos especificando historias y comencemos a explicarlas (Jeff Patton) 
  • Prefiero una historia ambigua que una bien especificada,  la primera requerirá explicación mientras la segunda no. (debo la referencia) 
  • Una historia de usuario debe ser tan pequeña que requiera ser explicada (debo la referencia) 
  • Si una historia de usuario no cabe en media hoja,  trata de escribirla en un papel más pequeño. (debo la referencia) 
  • Debe ser suficiente con un título y un wireframe explicado (Jeff Patton) 
  • No entiendo por qué insisten en usar un formato (uno de los creadores de XP al referirse al formato propuesto por Mike Cohn: YO COMO ROL,  DESEO FUNCIONALIDAD, PARA UN BENEFICIO DE NEGOCIO)
  • son más bien una carta de intención de lo que queremos que haga el sistema, son recordatorios para conversaciones que tendremos más adelante, (debo la referencia)

La verdad en mis entrenamientos enseño las 4 formas que conozco  de trabajar historias de usuario:
  • un solo titulo 
  • un título más un wireframe o boceto 
  • el formato de MIke Cohn: YO COMO ROL,  DESEO FUNCIONALIDAD, PARA UN BENEFICIO DE NEGOCIO; más los criterios de aceptación,
  • o la anterior forma pero con los criterios de aceptación escritos en formato Gerkin (Given, When, Then - Dado, Cuando, Entonces), propuesto por Dann North.

Con los consabidos tips:
  • que la historia de usuario tome de 3 a 5 días en lograr la definición de terminado (o  de DONE)
  • que tenga máximo 6 criterios de aceptación (tendiendo a menos no a más) 
  • un buen Sprint Backlog debe contar entre 6 y 10 historias de usuario,  tendiendo al número mayor o más y todas en lo posible de tamaño uniforme.


Por último,  recordemos que las historias de usuario buscan maximizar la comunicación,  independientemente de  lo que usemos como formato desde que estás sean explicadas por el cliente o Product Owner y el equipo las comprenda logrando una confirmación de ellas (PRINCIPIO DE LAS CCC: CARDS CONVERSACIÓN Y CONFIRMACIÓN (2)) la tarea estará bien hecha y habremos logrado el propósito de esta práctica.

Lo que funcione será lo mejor,  hagamos inspección y adaptación, y no nos detengamos de buscar mejores formas de hacer las cosas y de hacer software.

Saludos ágiles
Jorge Abad


Notas, aclaraciones, comentarios y referencias

  1. Juego en el que los participantes se dividen en parejas y unos son los especificadores y los otros los artistas,  y los especificadores durante un timebox de 10 minutos describen de forma escrita (y aislada) un dibujo,  luego esta especificación se le entrega a los artistas y durante un tiempo igual construyen lo especificado (los resultados no son muy satisfactorios en algunos casos,  o la mayoría dependiendo del dibujo o la habilidad de las personas para escribir o interpretar),  y luego durante un tiempo igual de 10 (luego de intercambiar los roles)  los nuevos especificadores de forma colaborativa (y conjunta) le dictan un dibujo más complejo sin dejarlo ver a los artistas,  los resultados son asombrosos: menos tiempo, mayor calidad del dibujo y por ende mayor satisfacción.
  2. Adicional el criterio INVEST

lunes, noviembre 21, 2016

El Paciente se Enferma de lo que el Médico Sabe. Una Invitación a no Detenerse en el Proceso de Aprendizaje




Hola a todos

Hace poco le escuche a un médico amigo de la familia la siguiente frase:

 “El paciente se enferma de lo que el médico sabe”  

y él me explicaba que era necesario que los médicos estén repasando lo aprendido y estudiando sobre lo nuevo, pues cuando llega un paciente con unos síntomas determinados, si ellos poco “saben” o “conocen” de esos síntomas, diagnosticarán mal al paciente y por ende le recetarán un tratamiento inadecuado (obvio, no se puede recetar sobre lo que no se conoce, por eso ellos envían a especialistas, pero si fueron muy livianos en su diagnóstico no identificarán correctamente la enfermedad, padecimiento o problema de su paciente).

En esta misma línea va este post, y es animar principalmente a los Scrum Master(1), y en segundo lugar a los Product Owner y Team Members, a que estén actualizándose, leyendo, buscando blogs, siguiendo en Twitter a los referentes de la industria, buscando nuevos enfoques o visiones más profundas que puedan enriquecer su experiencia con nuevas teorías o hallazgos, de manera que al momento que alguien se les acerque tengan argumentos para:

  • saber cómo enfrentar el problema
  • saber cuándo aplica la máxima de la gestión empírica:“inspección y adaptación”, y cuando no (2)
  • comprender que experimentos se pueden proponer o un posible espacio de solución
  • realizar las preguntas correctas que orienten y ayuden al coachee, al equipo, o a quienes se les acerque 
  • entre muchas otras situaciones

y de esa manera puedan brindar una mejor ayuda a los “síntomas” que se están observando.

Un Poco de Remedio

Como parte del remedio, les comparto algunos blogs y cuentas de twitter que sigo:


Un llamado a la Acción

Por ultimo quisiera hacerles un llamado a la acción (adicional al del propósito de este post que es invitarlos a que estudien y se actualicen constantemente), y es que compartan lo que aprendan y comprendan, sus experiencias y reflexiones son valiosísimas, creen un blog, pero si les resulta pesado tener un blog pues muchos me dicen que no se sienten con la confianza o el tiempo para escribir, compartan por twitter, pues lo que ustedes saben es útil para toda la comunidad(3), es una buena forma de generar conocimiento y de salir del anonimato, cosa por demás útil en el mundo de la agilidad.

Hasta acá esta corta reflexión.

Saludos Ágiles
Jorge Abad

_

Notas, Aclaraciones, Comentarios y Referencias

  1. Los Agile Coach también (y cualquier persona que tenga el rol de experto o consultor), pero la verdad un Agile Coach no requeriría este tipo de mensaje, pues sabe de la urgencia de estar aprendiendo y comprendiendo sobre como se mueve el entorno técnico, de equipos, de las personas, del coaching, de los frameworks, de las buenas prácticas, el empresarial entre otros.
  2. Les recomiendo leer este post: Por qué losagilistas como los gatos caemos parados
  3. Una frase que le digo a mis amigos "no sabemos todo lo que sabemos y creemos que lo nuestro es poco", en general somos inseguros acerca de nuestras experiencias, las creemos de poco valor, pero estoy seguro que son valiosas para alguien que se encuentre en una situación similar a ellas y esté buscando respuestas en la red.


viernes, noviembre 18, 2016

¿Por qué Los Agilistas como los Gatos Siempre Caemos Parados?



Hola a todos

Dentro de mi trabajo de acompañamiento a equipos y proyectos ágiles tengo dos frases acuñadas que repito con cierta frecuencia, que van por lo general una después de la otra:


<<es que los agilistas somos como los gatos "siempre caemos parados">>
 ----

<<y la verdad no se que hacer en este caso, nos toca tomar una decisión, hacer un experimento y realizar  "inspección y adaptación"(1)(2) para determinar si fue lo mejor o no.>>


Y la verdad no es que no tenga respuesta y use "inspección y adaptación" como muletilla de mi lenguaje o como escape ante una pregunta difícil, lo cierto es que estamos en la mayoría de las veces en los proyectos de software en entornos de incertidumbre donde no tenemos la seguridad de como será el resultado ante una práctica o solución propuesta, y tal como lo expone Cynefin (3), debemos revisar el resultado en retrospectiva y la respuesta será una práctica emergente que solo es útil en el contexto de ese proyecto en específico.

Obvio es necesario saber de métodos, frameworks, prácticas ágiles, el por que están allí, para que sirven, que tipo de problema quieren resolver para recomendar que hacer, que no hacer o simple y humildemente decir:

"La verdad no sé que hacer en este caso, nos toca elegir un camino y hacer luego inspección y adaptación


pues quienes hemos recorrido un poco de este camino hemos aprendido otra máxima universal:

"Lo que aplica para un equipo - o contexto - no necesariamente aplica para otro"


Saludos ágiles

Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias

  1. Tengo un amigo coach que me dice, "Jorge no conozco a nadie que use tanto esa frase como vos"
  2. La gestión empírica de proyectos esta basada en los pilares de inspección y adaptación.
  3. Te recomiendo este post a cerca de Cynefin: Diatriba: Una salida a la sobresimplificación de nuestros problemas en proyectos- clic aquí)

miércoles, noviembre 16, 2016

Demostrando el Valor Económico de Ejecutar Proyectos de Manera Ágil (Datos Hipotéticos)





Hola a todos


Hace poco alguien me preguntaba como demuestro el valor económico de ejecutar un proyecto en ágil versus uno tradicional. Dado este reto me dí a la tarea de crear este ejemplo hipotético basado en la experiencia de muchos proyectos ejecutados en ágil y en tradicional.

Datos de entrada


  • Proyecto Tradicional (fila 1 a la 10 de la tabla)
    • Tiempo formulado: 10 meses 
    • Costo inicial: $500
    • Tiempo adicional: 10 meses (por lo general los proyectos grandes fallan en grande y toman el doble del tiempo y del costo)
    • Costo adicional : $500 (en color rojo)
    • Valor total proyecto $1.000.
    • Salida a producción: Mes 21
    • Luego de estar el proyecto en producción alguien determinó que el beneficio era por 80 mensual
  • Proyecto Ágil (fila 13 a la 24 de la tabla)
    • Tiempo formulado: 10 meses
    • Costo inicial: $500
    • Tiempo adicional: 4 meses 
    • Costo adicional : $200(en color rojo) (se decide ir un poco más allá del presupuesto para hallar todo el valor de negocio esperado)
    • Valor total proyecto $700
    • Salida a producción Release 1: mes 5. Beneficio producido 30
    • Salida a producción Release 2: mes 8. Beneficio producido y acumulado 50 
    • Salida a producción Release 3: mes 15. Beneficio producido y acumulado 80



Descargar Excel - Clic Aquí


Resultados obtenidos


  • Los indicadores de TIR, Punto de Equilibrio, Ingresos netos en tres años, son mucho más favorables en Ágil que en Tradicional.
  • En ágil se puede generar el mismo impacto con menos valor en producción debido a que el alcance construido en ágil se enfoca en solucionar un problema de forma incremental y no en resolver el problema con un alcance definido al inicio que no se sabe si cumplirá con las expectativas del cliente.


Aclaraciones


Es importante aclarar que he estado en proyectos donde:

  • El valor de negocio se ha encontrado antes del presupuesto y fecha esperada, y para esto es clave un excelente Product Owner orientado por el valor de negocio, el ROI y no por satisfacer un alcance.
  • Y tambien he fallado haciendo ágil en escenarios donde:
    •  el cliente no entendía la metodología 
    • y donde bajo un proyecto con alcance, tiempo y costo fijo y un contrato desventajoso, montamos ágil para mitigar riesgos pero aun así no logramos cerrarlos


En conclusión


  • El éxito de un proyecto ágil esta dado por la estrategia para construcción del producto definida por el Product Owner, (Sin descuidar la excelencia técnica -Sin excelencia técnica no hay agilidad).
  • Aunque este solo fue un ejercicio académico, el resultado de hacer ágil no es solo económico, existen entre otros:


10th State of Agile 2015 - Versionone


Y para cerrar una idea

Ya le hemos dado muchas oportunidades a la forma tradicional - o cascada-  de hacer proyectos de software y hemos perdido, tiempo, dinero, clientes, amigos, trasnochos, ingenieros que han renunciado y familias que se han desintegrado(1), entonces ¿qué te impide hacer tu próximo proyecto de forma ágil?

Aclaraciones


  1. Este dato lo he comprobado en dos ocasiones, en los que el ingeniero desarrollador me compartió que no estuvo por más de un año en su hogar, pues trabajaba de continuo sábados, domingos y festivos  en un proyecto, siendo esta  una de las causas raíces para que se generara el divorcio y por ende la desintegración de su familia.





miércoles, noviembre 02, 2016

[Agenda Scrum] Pasos para Realizar el Refinamiento

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para el Refinamiento(2), actividad que se sugiere realizar en la mitad del sprint:


  1. El Scrum Master (SM) comparte el propósito, dinámica y timebox de la sesión
  2. El Product Owner (PO) comparte el objetivo del siguiente o subsiguientes sprints
  3. El PO comparte cada una de las historias de usuario con el Team
  4. El Team hace preguntas buscando que las historias estén en Ready (3) para el planning correspondiente ( requisitos claros, tecnología y herramientas claras, dependencias externas resueltas)
  5. El PO responde las preguntas
  6. En caso de que el PO no pueda responder una pregunta, toma nota para resolverla para el planning en que está programada
  7. El Team puede realizar sugerencias sobre estrategias de construcción del proximo Sprint Backlog, el PO decide si las acoge o no.
  8. Cuando se terminen las historias planeadas a compartir se termina la reunión.
  9. Actualizar las herramientas de gestión.


Bienvenido el feedback

Saludos ágiles
Jorge Abad


Notas, Referencias, Comentarios y Aclaraciones

  1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo
  2. Esta reunión no tiene como objetivo escribir las historias de usuario, aunque algunas pueden ser escritas, divididas o fusionadas.
  3. Recomiendo este post - La Definición de “Ready” es tan importante como la Definición de “Done”

[Agenda Scrum] Pasos para Realizar la Retrospectiva

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para la Retrospectiva:


  • Antes del Review identifique que retrospectiva quiere realizar con su equipo  y que objetivo quiere lograr, una buena herramienta para planear una retrospectiva es Retromat (http://plans-for-retrospectives.com/)
  • En la retrospectiva siga los siguientes pasos
    1. El Scrum Master (SM) Explique el propósito de la sesión y el Timebox que se tiene para ella y los pasos a seguir.
    2. Arme el escenario (identifique como entran las personas a la retrospectiva)(3)
    3. Recolecte y presente datos
      • ¿Se cumplió el objetivo del sprint?
      • ¿cuántos puntos e historias se lograron?
      • ¿cuál fue la calificación del Product Owner (PO) para el Sprint?
      • ¿cómo estuvo la calidad y la deuda técnica?
      • ¿funcionó o no la mejora planeada para este sprint?¿que resultados se obtuvieron?
      • use una activdad para obtener temas de sensaciones, efectividad como equipo, efectividad tecnica (3)
    4. Indagar y logre un entendimiento profundo  de que fué lo que pasó, por que les fue bien o no tan bien como lo esperaban(3)
    5. Decidir que hacer, (3)
      • elijan los siguientes pasos a seguir 2 o 3 mejoras a realizar
      • cree un plan evidenciando
        • quien
        • que (experimento)
        • cuando
        • resultado esperado
        • resultado obtenido (util para el punto 3)
    6. Cerrar o culmilar la retrospectiva (3)
    7. Actualizar las herramientas de gestión.


Bienvenido el feedback

Saludos ágiles
Jorge Abad


Notas, Referencias, Comentarios y Aclaraciones

  1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo
  2. Este post esta basado en las sugerencias de Ester Derby y Diana Larsen - Agile Retrospectives  
  3. Puede usar una activdad de Retromat (http://plans-for-retrospectives.com/)

[Agenda Scrum] Pasos para Realizar el Review o Revisión

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para la Revisión o Review:

Forma 1: El equipo entrega el producto al Product Owner (PO)
  1. El Scrum Master (SM) comparte el propósito de la reunión, timebox y pasos a seguir.
  2. El SM invita a que el equipo muestre el incremento al PO y los interesados
  3. El Equipo muestra cada una de las historias planificadas que fueron terminadas en un orden que sea coherente para el PO y los interesados
  4. El PO puede solictar que muestre algún caso o funcionamiento en especial (recordar que no es una reunión de testing, sino de muestra de lo logrado)
  5. El PO acepta o rechaza la historia de suario, y se retorna al paso 3 hasta que se completan todas las historias de usuario
  6. El SM solicita al PO la calificación del Sprint (ver más en - http://www.lecciones-aprendidas.info/2016/09/tip-de-scrum-la-calificacion-del-po-al.html)
  7. El SM solicita a los interesados, developers y PO retroalimentación hacia el product backlog (cambios, eleminaciones, repriorizaciones)
  8. Se actualizan las herramientas de gestión.

Forma 2: Como lo propone la Guía de Scrum (http://scrumguides.org/)
  1. El Dueño de Producto explica as los interesados qué elementos de la Lista de Producto se han “Terminado” y cuales no se han “Terminado”;
  2. El Equipo de Desarrollo habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecieron y cómo fueron resueltos esos problemas;
  3.  El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” (increments) y responde preguntas acerca del Incremento;
  4. El Dueño de Producto habla acerca de la Lista de Producto en su estado actual. Proyecta fechas de finalización probables en el tiempo basándose en el progreso obtenido hasta la fecha (si es necesario);
  5. El grupo completo colabora acerca de qué hacer a continuación, de modo que la Revisión del Sprint proporcione información de entrada valiosa para reuniones de Planificación de Sprints subsiguientes (retroalimentación al product backlog).
  6. Revisión de cómo el mercado o el uso potencial del producto podría haber cambiado lo que es de más valor para hacer a continuación; y,
  7. Revisión de la línea de tiempo, presupuesto, capacidades potenciales y mercado para la próxima entrega prevista del producto.

Bienvenido el feedback

Saludos ágiles
Jorge Abad


Notas, Referencias, Comentarios y Aclaraciones

  1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo

[Agenda Scrum] Pasos para Realizar un Daily

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para el Daily:


  1. El Scrum Master (SM) comparte el propósito de la reunión, timebox y pasos a seguir
  2. El SM invita a que alguien tome la palabra y pone a contar el cronómetro
  3. Un team member toma la palabra y contesta las tres preguntas que pueden ser
    • Opción 1: las preguntas populares
      • ¿Qué hice ayer?
      • ¿Qué voy a hacer hoy
      • ¿Qué impedimientos tengo?
    • Opción 2: las preguntas de la guía de scrum -(http://scrumguides.org/)
      • ¿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?
    • Opción 3: Enseñadas por Carlos Gil - @cafegifo
      • ¿Qué logré ayer?
      • ¿Qué voy a lograr hoy?
      • ¿Qué me lo está impidiendo?
    • Opción 4: Guía Scrum 2020
      • ¿Cómo son mis tareas de hoy?¿si creo que vamos a lograr el objetivo del sprint?¿y cómo podemos hacerlo?
  4. A la par el SM toma nota de los impedimentos
  5. Luego le da la palabra a otro team member, retornando al paso 3 hasta que todos los team members del equipo de desarrollo del producto hayan contestado el daily
  6. El SM comparte cuanto tiempo fue invertido en el daily
  7. El SM dice fin del daily
  8. El SM realiza una invitación similar a la siguiente: "quien requiera solucionar temas con sus compañeros o pueda solucionar temas lo invito a quedarse para resolverlos, de resto pueden retornar a sus actividades"
  9. Se actualizan las herramientas de gestión


Bienvenido el feedback

Saludos ágiles
Jorge Abad


Notas, Referencias, Comentarios y Aclaraciones

  1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo

[Agenda Scrum] Pasos para Realizar un Planning

Hola a todos

Bajo esta etiqueta, quiero compartirles los pasos que he encontrado para realizar las diferentes reuniones, ceremonias o conversaciones de Scrum, no son estrictos, no son obligatorios, cada Scrum Master y Equipo encontrarán la forma de hacerlo - no dudo que mejores -, he aquí una propuesta para cada una de las sesiones.

Quiero compartirles en este post los pasos sugeridos para el Planning

Forma 1: A cada historia se estiman sus puntos y tareas a la vez
  1. Preparar la reunión
  2. El Scrum Master(SM) comparte el propósito de la reunión, timebox y los pasos a seguir
  3. Se establecen las reglas y los acuerdos entre los asistentes para hacer efectiva la reunión
  4. El Produt Owner(PO) comparte el objetivo del Sprint
  5. El SM comparte la capacidad o velocidad del equipo en puntos (o en algun sistema equivalente) considerando la presencia o no de team members, o reuniones citadas.
  6. El PO lee la historia de usuario
  7. El equipo hace preguntas
  8. El SM invita a que el equipo estima historia de usuario estimen en puntos (se puede usar la serie de Fibonacci u otra serie)
  9. Con la facilitación del SM se llega a un acuerdo sobre cuantos puntos tiene la historia
  10. Se identifican las tareas técnicas para realizar la historia de usuario (ej: crear tabla, crear pantalla, modificar SQL, armar webservice, probar, desplegar, etc)
  11. (opcional) a las tareas se les asigna horas por parte del equipo llegando a acuerdos ayudados por el SM
  12. Se valida si la capacidad del equipo es alcanzada en horas y en puntos por la historia de usuario estimada, si la respuesta es NO, se retorna al punto 6 con la siguiente historia de usuario
  13. Si la capacidad en horas o puntos es alcanzada se finaliza el Planning
  14. El SM comunica entonces:
    1. Cual es el objetivo,o se actualiza con la retroalimentación de todos
    2. las historias planeadas
    3. las fechas para refinamiento, review, retrospectiva.
  15. Se actualizan las herramientas de gestión

Forma 2: A todas las historias se les estiman sus puntos y luego sus tareas
  1. Preparar la reunión
  2. El Scrum Master(SM) comparte el propósito de la reunión, timebox y los pasos a seguir
  3. Se establecen las reglas y los acuerdos entre los asistentes para hacer efectiva la reunión
  4. El Produt Owner(PO) comparte el objetivo del Sprint
  5. El SM comparte la capacidad o velocidad del equipo en puntos (o en algun sistema equivalente) considerando la presencia o no de team members, o reuniones citadas.
  6. El PO lee la historia de usuario
  7. El equipo hace preguntas
  8. El SM invita a que el equipo estima historia de usuario estimen en puntos (se puede usar la serie de Fibonacci u otra serie)
  9. Con la facilitación del SM se llega a un acuerdo sobre cuantos puntos tiene la historia
  10. Se valida si la capacidad del equipo es alcanzada en puntos por la historia de usuario estimada, si la respuesta es NO, se retorna al punto 6 con la siguiente historia de usuario.
  11. Si la capacidad  puntos es alcanzada se identifican las tareas técnicas para realizar todas historias de usuario (ej: crear tabla, crear pantalla, modificar SQL, armar webservice, probar, desplegar, etc)
  12. (opcional) a las tareas se les asigna horas por parte del equipo llegando a acuerdos ayudados por el SM
  13. Se valida que la capacidad en horas no sea superada, en caso de ser superada se informa que es requerido remover una historia de usuario al PO
  14. El PO elige que historia no hace parte del sprint
  15. El SM comunica entonces:
    1. Cual es el objetivo,o se actualiza con la retroalimentación de todos
    2. las historias planeadas
    3. las fechas para refinamiento, review, retrospectiva.
  16. Se actualizan las herramientas de gestión

Bienvenido el feedback

Saludos ágiles
Jorge Abad


Notas, Referencias, Comentarios y Aclaraciones

  1. Un excelente post donde pueden consultar otra posible agenda es Migas de Pan – Scrum de mi gran amigo y agilista Carlos Gil - @cafegifo

martes, noviembre 01, 2016

Mantener el foco: Un pensamiento sobre equipos maduros y autogestionados.




Hola a todos

Dentro de la actividad de acompañamiento a equipos y Scrum Masters (SM), me he encontrado algunas veces SMs  que se sienten bastante orgullosos del nivel de autogestión de su equipo, tanto, que no requieren gestión de parte de ellos, pues el equipo es tan, pero tan maduro que ellos mismos remueven sus propios impedimentos y los SM no tiene que hacer nada, en estos escenarios lo que generalmente contesto es algo similar a lo siguiente:

Me encanta la autogestión y la proactividad de los equipos maduros, uno ve a los miembros del equipo preguntarse cosas y hacerse cargo de temas e impedimentos, y eso esta bien, pero prefiero que los equipos se enfoquen en lo que generan valor y los temas externos e impedimentos que requieren de tiempo e insistencia se dejen al Scrum Master.

Por ejemplo, si algo requiere del apoyo de un área externa, pues está bien que el miembro del equipo haga uno o dos intentos por contactarla, pero en vista que no se logra, le realice un pedido al SM del siguiente tipo: "oye he intentado comunicarme con x para lograr tal cosa para el proyecto, ayúdame por favor, pues esto noto que va a requerir de mucho tiempo y debo seguir con otras tareas".

En Scrum cada rol tiene su foco y su forma de generar valor, y es importante tener esto presente aun cuando el equipo se encuentre en importantes estados de madurez.


Hasta acá esta corta reflexión, ¿qué piensas de esto?¿estás de acuerdo?

Bienvenido el feedback y la reflexión.

Saludos ágiles

Jorge Abad

Referencias, Aclaraciones, Notas y Comentarios


  1. Una buena referencia: El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo