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 Económico el Valor 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.
  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. 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 qué elementos de la Lista de Producto se han “Terminado” ycuales no se han “Terminado”;
  2. El Equipo de Desarrollo habla acerca de qué estuvo bien durante el Sprint, qué problemasaparecieron y cómo fueron resueltos esos problemas;
  3.  El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” 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.
  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, timbox 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?
  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
    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
    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





lunes, octubre 31, 2016

Sí, Mínimo Producto Viable ¿Pero en qué contexto?






La definición de Producto Mínimo Viable es muy conocida tanto en el mundo del agilismo como en el mundo del emprendimiento y es allí donde quiero poner foco el día hoy, pues para ambos significan cosas completamente diferentes. En palabras de Eric Ries, el Gurú de Lean Startup:


Minimum Viable Product; is a product with just enough features to gather validated learning about the product and its continued development(1)(2)


Y en palabras de Martín Salias y Martín Alaimo, referentes en la comunidad ágil latinoamericana:


Minimum Viable Product ( MVP) es la versión mínima de un producto, tal que nos permita recolectar la mayor cantidad de información de nuestro mercado y clientes con el menor esfuerzo posible.(3)


Y esta definición es muy acorde con la imagen del artículo, pues existe una clara diferencia entre ambas y es el momento del tiempo.


Miremos el ejemplo de Dropbox ellos crearon un vídeo con lo que sería Dropbox - https://youtu.be/7QmCUDHpNzE - , no lo habían implementado, y lo publicaron en Youtube para facilitar su acceso, necesitaban validar su idea - La primera definición de MVP de este post, y primer momento del tiempo - para atraer usuarios e inversores, la propuesta de valor: “funcionaba y era simple” y pasaron de 5.000 a 75.000 personas en la lista de espera para su beta una vez se hizo el vídeo, considerando que adicionalmente crearon Votebox, un espacio en su web donde los usuarios iban dando ideas de funcionalidades que incluir. Luego en otro momento del tiempo para Drobpox determinaron cual era la versión mínima de producto para su version beta, o sea la versión que iba a funcionar inicialmente en el mercado - la segunda definición de MVP de este post y el segundo momento del tiempo -.


Por tanto, es importante que identifiquemos en que momento del tiempo estamos, si estamos en la definición de producto buscamos aprendizaje validado y clientes, o si es en el segundo momento, con producto y clientes definidos, y es requerida una versión mínima de lo que vamos a entregar.


Aunque es de aclarar, que no dudo que hayan contextos en que lleguen a ser lo el mismo producto ambos MVP, pero observo que desde el punto de vista del desarrollo a la medida por lo general estamos en el segundo momento.


Saludos ágiles


Jorge Abad


Referencias Aclaraciones, Notas y Comentarios 

  1. https://en.wikipedia.org/wiki/Minimum_viable_product 
  2. https://es.wikipedia.org/wiki/Producto_viable_m%C3%ADnimo 
  3. "Proyectos Ágiles con Scrum: Flexibilidad, aprendizaje, innovación y colaboración en contextos complejos (Spanish Edition)"


jueves, octubre 27, 2016

[Tip Scrum]: Slack o el Tiempo para Afilar el Hacha en Scrum



Hola a todos

Comencemos con una historia para ilustrar el concepto

"Dos hombres determinan hacer una competencia en la cual deben lograr derribar un árbol en el menor tiempo posible. Ambos se lanzan a la obra, llenos de energía y convencidos de que el premio pronto estará en sus manos.

Al blandir sus hachas, vuelan las astillas y los espectadores miran con asombro como el corte en ambos árboles se va profundizando con cada hachazo.

De repente uno de los dos competidores se detiene. El público queda sorprendido al observar que saca una pequeña lima de su bolsillo y comienza a afilar su hacha con toda calma.

Su oponente está feliz. Sigue golpeando con aún mayor fuerza su árbol y muy pronto el corte que está haciendo llega a ser tan grande que su victoria parece ser evidente.

Hasta el momento en el cual el hombre que afiló su hacha vuelve al trabajo. Un, dos y tres. Con solo un par de golpes acertados su árbol comienza a crujir y, ante la sorpresa de todos los espectadores, se derrumba a los pies del hombre sabio, quien supo lo importante que era contar con una herramienta en óptimas condiciones."(1)




Ahora sí...

Entre mis compañeros coaches con los cuales comparto actualmente, es muy común un término que ellos acuñan como "afilar el hacha", yo lo conocía como Slack ( referido en el post  Seis (6) estrategias de lograr mayor velocidad de los equipos en Scrum - clic aquí- )  y es un tiempo que se separa durante o entre sprints para que los equipos o las personas afilen el hacha y mejoren su forma de trabajo.






Dentro de las formas de seleccionar este tiempo están técnicas como:


  • dejar un tiempo pequeño entre sprints de 1 a 2 días 
  • 6×2 + 1 - despues de 6 sprints de 2 semanas, descansar una.
  • El viernes del desarrollador: Cada viernes el desarrollador tiene tiempo para alguna de estas tareas.
  • Una carta dorada. Esta carta en el juego del poker le dará al desarrollador un día libre (el que quiera) para usar el slack en lo que el quiera.
  • ver más en Cutting Slack in Scrum

Hasta acá este pequeño pero poderoso compartir.

Preguntas poderosas para ti y tu equipo

  • ¿hace cuánto no afilas el hacha en tu equipo?
  • ¿qué te lo impide?
  • ¿qué es necesario hacer para lograr afilar el hacha en tu equipo con frecuencia?
  • yendo un poco más allá, ¿en tu empresa, en tu relación de pareja, en tu vida hace cuanto no afilas el hacha?
Saludos ágiles

Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias




viernes, octubre 21, 2016

Cumplimiento de Promesas y Ofertas como Generadores de Confianza y Tejido en los Equipos



Diagrama basado en el libro de Ontología del Lenguaje de Rafael Echeverría

Hola a todos

les comparto las reflexiones asociadas a este diagrama que me fue explicado por mi amigo Wbeimar Vásquez:

  • Hacia el interior del equipo
    • El cumplimiento de ofertas y promesas entre los miembros del equipo  produce CONFIANZA
    • La CONFIANZA logra tejido social y relaciones fuertes al interior del equipo y capacidad para asumir compromisos y realizarceles pedidos que serán cumplidos
  • Hacia el exterior del equipo
    • El cumplimiento de ofertas y promesas del equipo produce CONFIANZA en el equipo.
    • La CONFIANZA en el equipo logra tejido social y relaciones fuertes con el equipo y capacidad para asumir y asignarles pedidos retos, compromisos.

En el sentido negativo sería:
  • Hacia el interior del equipo
    • El incumplimiento de ofertas y promesas entre los miembros del equipo  produce DESCONFIANZA
    • La DESCONFIANZA deteriora tejido social, debilita y destruye relaciones al interior del equipo y genera incapacidad para asumir compromisos y pedidos
  • Hacia el exterior del equipo
    • El incumplimiento de ofertas y promesas del equipo produce DESCONFIANZA en el equipo.
    • La DESCONFIANZA en el equipo deteriora tejido social, debilita y destruye las relaciones con el equipo y se duda en su capacidad de asumir compromisos, asignarle retos y realizarceles pedidos.
Hasta acá esta pequeña reflexión


Saludos Ágiles
Jorge Abad


miércoles, octubre 12, 2016

Keynote Agiles 2016: La puerta abre hacia adentro

Hola a todos

Les comparto el keynote del tercer día Agiles 2016 en Ecuador presentado por Martin Alaimo @martinalaimo, Inspirador, clarificante e impertible, hay que tomar mucha nota de todos los aspectos que menciona.

Saludos ágiles
Jorge Abad.




Dinámica - Juego de listones para la enseñar mejora continua

Hola a todos

Les comparto este juego que ayuda a enseñar mejora continua a los equipos.

Saludos Ágiles
Jorge Abad

---

domingo, octubre 02, 2016

Algunos Tips para Brindar un Buen Entrenamiento o Ser un Buen Trainer o Faculty




Hola a todos

Hace poco para la organización en la que trabajo me solicitaron dictar un curso de "Cómo ser un buen Faculty",o un "Train de Trainers", pues sin quererlo mis cursos y entrenamientos se han convertido en punto de referencia para los otros entrenadores.

Bueno, dado este requerimiento quisiera aprovechar para compartirles algunos tips para que impartan capacitaciones, entrenamientos o cursos exitosos, no antes sin aclarar  que soy el fruto de muchos maestros(1), de fallar mucho, aprender mucho y del feedback de mis compañeros y estudiantes, y ahora sí volviendo al tema les comparto los tips, espero les sirvan tanto como a mi:

  • Preparación

    • Aunque sea obvio, garantice el entendimiento y dominio del tema, los estudiantes - y usted y yo lo sabemos -  sabemos cuando alguien no esta lo suficientemente preparado para compartir un tema, materia, entrenamiento o cátedra específica.
    • Siempre piense:
      • ¿Cómo le gustaría que le enseñaran el tema que va a impartir?
      • ¿Cómo lograría que sus estudiantes aprendieran y comprendieran más? y 
      • ¿Cómo mantenerlos despiertos y activos durante la clase, entrenamiento o capacitación?
      • tenga presente la siguiente frase:
Frase atribuida a Benjamín Franklin o a un Proverbio Chino,
sin importar la fuente es efectiva y real.

    • Envíe a sus estudiantes un material introductorio que garantice una sensibilización previa.
    • Sea humilde, en el auditorio hay personas de las cuales tiene mucho que aprender y sus preguntas le ayudarán a enfocarse donde más profundizar más para que la próxima vez el curso sea más exitoso..

  • Durante el entrenamiento

    • En lo posible apréndase los nombres de los asistentes, recuerde que la palabra más dulce para una persona es su nombre, para lograr esto use una actividad de:
      • una presentación individual 
      • una dinámica de presentación y memorización
      • Durante el entrenamiento hacer preguntas y validar nombres
    • Pregunte por las expectativas de los asistentes al curso y lo que ellos quieren lograr, si lo desea cree un tablero de expectativas:

    • Comparta los objetivos del curso (2) y el resultado esperado al final todas las sesiones, y con base en lo anterior determine si puede variar el programa.
    • Comparta el objetivo de la sesión que va a impartir el día de "hoy"
    • Invierta 20 minutos en que todos discutan cuales son las reglas que van a respetar conjuntamente, - el resultado es mejor cuando las reglas las formulan los asistentes en vez del facilitador -.

    • Presente el temario en un tablero kanban,  y a medida que avance mueva los posit por cada una de las columnas:
      • To-Do (por hacer) 
      • WIP (en progreso)
      • Done (terminado)
    • También sugiero tener un burndown y mostrar el avance en esta herramienta. Para esto sugiero que a cada tema se le ponga un peso en la función del tiempo que se requiere invertir en cada tema.
Kanban y Burndown de un Entrenamiento


    • Enfóquese en lograr una dinámica interactiva con el tema de manera que garantice apropiarse del conocimiento antes con una actividad o después con un taller o similar. basada en:
      • tema - dinámica (juego o taller)
      • dinámica (juego o taller) - tema
    • Respecto a las pausas
      • Trate de que hayan pausas cada 50 minutos de al menos 10 minutos que permitan al estudiante volver a concentrarse.
      • Al menos cada 2 horas realice una actividad en la cual estén todos interactuando o jugando, sea que tenga que ver o no con el tema ayuda a conservar la atención de la misma.

      • Después del almuerzo realice una actividad que energice a los asistentes, esta hora es pesada y se requiere de actividad para vencerla
      • Si alguien se está durmiendo invítalo a que escuche la sesión de pie o realiza una actividad para energizar - dependiendo del tiempo y lo que estés tratando - 
    • Tenga un manejo "impecable" del tiempo con horas de inicio claras para temas, descansos, actividades, etc. esto le dará credibilidad y mostrará su profesionalismo.
    • Tenga una zona de preguntas o parking lot y resuélvalas al final de la sesión o máximo cada 4 horas

    • Tenga un rincón de los famosos o referencias, allí sabrán sus estudiantes a donde seguir avanzando en caso de querer profundizar





    • Minimice el uso del video beam y de videos, 
    • Incentive el hecho que se tome nota en papel y no en computador aumentan el aprendizaje.
    • Use presentaciones exitosas(3) basadas en poco texto y baja saturación de imágenes e información.
    • Facilite gráficamente o escriba en pliegos de papel, y déjelos pegados en las paredes los estudiantes volverán sobre cualquier tema sin necesidad de buscar diapositivas, solo con mirar un concepto en la pared.


Observar las paredes con los temas facilitados

    • Si su curso dura varios dias, al principio de cada día haga recorderis de lo visto el día anterior. (visite las paredes del día anterior).
    • Traiga ejemplos del mundo real al curso, son de alto valor para los asistentes del curso.
    • Trate de crear un ejemplo que sea hilo conductor a lo largo de todo el entrenamiento 
    • Elabore talleres que sigan el mismo hilo conductor del ejemplo del curso.
    • Recuerdan que en la universidad o colegio teníamos un compañer@ que tomaba muyb buenas notas, para maximizar este beneficio realice el ejercicio de qué aprendi y que aprendi de mi compañero, es una recapitulación que se realiza cada cierto tiempo y donde las personas ponen los temas centrales que aprendieron luego comparten estas notas con un asistente y el compañero toma nota de lo que le llamó la atención o le hizo "clic".

    • Elabore talleres que ayuden a inferir el conocimiento o a remarcarlo

  • Cerrando

    • A pesar de que por lo general hay encuestas que se hacen al final, realice un ejercicio de Feedback al final, donde obtengas respuestas sobre la satisfacción del auditorio 


    • Elabore un examen al final del curso que lo resuelvan individualmente o en grupos y que luego usted resuelva para todos y explique las razones de cada respuesta.
    • Por último, valide con los asistentes si el resultado final fue el esperado.
Este es el resumen de mi experiencia y la forma como dicto cursos, no dudo que tengan referencias a expertos en gestión del conocimiento y enseñanza pero la verdad los desconozco, yo soy alumno de sus alumnos.

Bienvenidos los aportes y el feedback.

Saludos ágiles

Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias

  1. La mayoría de mis maestros son del mundo de la agilidad (Luis Mulato, Martin Alaimo, Claudia Sandoval, Pablo Tortorella, Ingrid Astiz, Ricardo Colusso, Lucho Salazar, Leonardo Agudelo, Juliana Betancur, Johnny Ordoñez, entre muchos otros)
  2. De ahora en adelante llamaremos curso al entrenamiento, materia, tema, o cátedra con el fin de hacer más fácil la lectura.
  3. Ver esta interesante recomendación de Johnny Ordoñez - Desecha tus antiguas presentaciones, es una orden del Doctor - Clic aquí

sábado, octubre 01, 2016

Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión




Hola a todos

He notado que además del Planning que compromete al equipo y el Review en el cual el equipo entrega el incremento al Product Owner y a los interesados, una de las grandes herramientas que tiene el Scrum Master para la incentivar y lograr la autoorganización de un equipo son las Preguntas Poderosas (1), estas son una herramienta común del coaching de personas y  equipos (2)  y permiten:

  • Generar curiosidad
  • Estimular la reflexión y el pensamiento
  • Sacar a la superficie creencias y supuestos
  • Abre la creatividad y nuevas posibilidades
  • Generar energía, invitar a la acción
  • Canalizar y enfoca la atención
  • Tocar un significado profundo
  • Empoderar, responsabilizar
  • Cuestionar al equipo y no a una sola persona
  • Evidenciar al equipo lo responsables que son del resultado
  • Invitar a encontrar soluciones entre ellos
  • Permitirque el equipo se escuche y surjan ideas creativas, innovadoras y divergentes
  • Suscitar más preguntas
muy a diferencia de la estrategia tradicional de gestión de proyectos en "comando-control" donde el gerente asigna las tareas a cada miembro del equipo y este estos reportan su avance. En este aspecto se diferencian los estilos de liderazgo mientras el el Scrum Master  cuestiona y empodera el Gerente de Proyecto dirige y asigna para lograr el objetivo.


Mientras el Gerente de Proyecto dirige y asigna, el Scrum Master cuestiona y empodera para lograr el objetivo. 

El poder de las preguntas poderosas esta dado en la capacidad de abrir posibilidades, acciones y proporcionar información valiosa, por lo tanto, las preguntas abiertas proporcionan más información que las cerradas, sin demeritar que un simple "Sí", "No" o "Estamos de acuerdo" según el contexto nos permiten actuar o no en cierta dirección. A continuación bajo esta óptica presento una simple clasificación de estilos de pregunta
  • Alta importancia (proporcionan mucha información)
    • Qué 
    • Por qué
    • Cómo
    • Para qué
    • Qué tal si
  • Media importancia (proporcionan menos información)
    • Cuándo
    • Dónde
    • Quién
  • Baja importancia (proporcionan poca información)
    • Cierto o falso
    • Te gustaría
    • Podrías
    • Están de acuerdo
    • Estás de acuerdo

Cómo se usan en Scrum

A continuación comparto algunas unas preguntas que se pueden realizar en cada uno de los momentos que se viven durante un sprint, igual no dudo que en el instante apropiado el Scrum Master sabrá cuales realizar ya sean estas que están propuestas u otras mejores:


Planning
  • ¿Cómo consideran ustedes que van a lograr construir todas las historias comprometidas en este planning?
  • ¿Se sienten tranquilos con el sprint backlog?¿Por qué?

Durante el sprint
  • En la mitad del sprint
    • ¿Creen que podremos lograr el objetivo del sprint y las historias comprometidas?¿Qué estrategia podemos idearnos como equipo para lograrlo?
    • ¿Se encuentran tranquilos con la calidad del producto que estamos logrando?¿Qué podemos hacer?
    • ¿Cómo creen que se debe resolver esta situación?
    • ¿Qué deberíamos hacer para estar completamente tranquilos?
  • Si algo va mal
    • ¿Creen ustedes qué vamos en la dirección correcta?¿Qué podemos hacer para corregirla?
    • ¿Qué necesitan para hacerse cargo? 
    • ¿Cuándo se van a hacer cargo? 

En la retrospectiva (el lugar más natural de las preguntas poderosas)
  • ¿Qué podríamos hacer diferente el próximo sprint para que nos fuera mejor?
  • ¿Usted qué cree que anda mal en el equipo? ¿Como lo mejoraría?
  • ¿Qué necesitamos hacer para ser un mejor equipo?
  • ¿Estamos tranquilos con la forma como estamos construyendo el producto?¿Por qué?
  • ¿Qué Podemos construir el producto mejor?
  • ¿Cómo podría la organización soportar mejor al equipo?
  • ¿y si nos atrevemos a?
  • ¿ y si vemos esto desde otra óptica?
  • entre muchas otras.

Para terminar quisiera dejar esta pregunta:

¿Cómo Scrum Master o Team Member(3) que preguntas le haces a tu equipo?


Si lo deseas únete a la conversación a través de twitter, este es el tweet:



Bienvenido el feedback


Saludos Ágiles
Jorge Abad



Notas, Aclaraciones, Comentarios y Referencias

  1. No es mi tradición subrayar, pero desde mi punto de vista la idea es clave para llegar a ser un buen Scrum Master.
  2. Algunas características tomadas de http://es.slideshare.net/CoachingTalanton/preguntas-poderosas-12961845
  3. Un miembro del equipo también es alguien llamado a cuestionar a su equipo.
  4. Buenos ejemplos de preguntas poderosas - http://www.coactive.com/learning-hub/es/intermediate/fulfillment/res/tools/FUL-Ejemplos-de-preguntas-poderosas.pdf