De Colección: 51 frases motivadoras para trabajar en equipo

Hola a todos

Buscando información para una presentación me encontré con esta selección de frases, realmente es una joya (la copié para que no se me perdiera la referencia):

1. “No hay reto que no podamos alcanzar trabajando unidos con claridad de los objetivos y conociendo los instrumentos”. -Carlos Slim.
2. “La fuerza está en la unidad. Con la colaboración y el trabajo en equipo es posible conseguir cosas maravillosas”. -Mattie Stepanek.
3. “Nadie puede silbar una sinfonía. Se necesita una orquesta completa para tocarla”. -HE Luccock.
4. “Este mundo no es un campo de batalla. Algún día te darás cuenta de cómo tu éxito depende de un montón de otras personas y ese día serás más sabio. Tú sabrás que todos estamos conectados. O lo hacemos todos o ninguno de nosotros lo hace”.-Jasleen Kaur Gumber.
5. “Ten presente que el destino de todos depende de la conducta de cada uno”. -Alejandro Magno.
6. “Jamás pongas en duda que un pequeño grupo de personas comprometidas pueden cambiar el mundo. En efecto, es lo único capaz de lograrlo”. -Margaret Meade.
7. “Ninguno de nosotros es tan bueno como todos nosotros juntos”. -Ray Kroc.
8. “El talento gana partidos, pero el trabajo en equipo y la inteligencia ganan campeonatos”. -Michael Jordan.
9. “Cuando las arañas tejen juntas, pueden atar a un león”.-Proverbio Etíope.
10. “La fortaleza del equipo está en cada miembro por separado. La fortaleza de cada miembro es el equipo”. -Phil Jackson.
11. “El trabajo en equipo es el secreto que hace que la gente común logre resultados increíbles”. – Ifeanyi Onuoha.
12. “El trabajo en equipo es la capacidad de trabajar juntos hacia una visión común. La capacidad de dirigir los logros individuales hacia los objetivos de la organización. Es el combustible que permite que la gente normal logre resultados poco comunes”. –Andrew Carnegie.
13. “El trabajo en equipo permite que los sueños se cumplan”. –Bang Gae.
14. “Si un equipo quiere alcanzar su potencial, cada miembro debe estar dispuesto a doblegar sus metas personales para el bien de todos”. -Bud Wilkinson.
15. “Si estamos juntos no hay nada imposible. Si estamos divididos todo fallará”. -Winston Churchill.
16. “Con un equipo lleno de entusiasmo puedes conseguir casi cualquier cosa”. -Tahir Shah.
17. “Un barco no avanza si cada uno está remando en una dirección”. – Proverbio Swahili.
18. “El espíritu de equipo es lo que da a muchas empresas una ventaja sobre sus competidores”. -George Clements.
19. “Mejor perder con el equipo adecuado que ganar con el equipo equivocado”. Ogwo David Emenike.
20. “Los cinco dedos separados son cinco unidades independientes. Ciérralos y el puño multiplica la fuerza. Ésta es la organización”. -James Cash Penney.
21. “No existe un hombre hecho a sí mismo. Alcanzarás tus metas con la ayuda de los demás”. -George Shinn.
22. “No hay equipo sin los miembros individuales; un individuo nunca puede ser un equipo”. -Michael Joling.
23. “Es mucho más gratificante llegar a la cima de la montaña y compartir tu experiencia con otros que mostrarte tu solo exhausto”. -Shandel Slaten.
24. “Solos podemos hacer muy poco; unidos podemos hacer mucho”. -Hellen Keller.
25. “Llegar juntos es el principio. Mantenerse juntos, es el progreso. Trabajar juntos es el éxito”. -Henry Ford.
26. “Trabaja en equipo. Unos inofensivos copos de nieve juntos pueden desatar una avalancha de destrucción.” – Justin Sewell.
27. “Si podéis reír juntos, podéis trabajar juntos”. – Robert Orben.
28. “Nadie puede conseguir el éxito solo”. -Ifeanyi Enoch Onuoha.
29. “Sólo llegando a estar unidos, como una sola fuerza, nos mantendremos fuertes e inconquistables”. –Chris Bradford.
30. “El ego es el asesino definitivo en un equipo”. – Patrick Lencioni.
31. “El mejor trabajo en equipo proviene de aquellos hombres que trabajan de forma independiente para conseguir una meta en conjunto”. –James Cash Penney.
32. “Tienes que ser consciente de lo que están haciendo los otros, aplaudir sus esfuerzos, reconocer sus éxitos, y animarlos en sus metas. Cuando todo el mundo se ayuda, todo el mundo gana”. – Jim Stovall.
33. “El trabajo en equipo comienza por crear confianza. La única forma de hacerlo es superar nuestra necesidad de invulnerabilidad”. –Patrick Lencioni.
34. “Construye en tu equipo un sentimiento de unidad, de dependencia de uno para el otro, de fortaleza derivada de la unidad”. -Vince Lombardi.
35. “Yo hago lo que tú no puedes, y tú haces lo que yo no puedo. Juntos podemos hacer grandes cosas”. -Madre Teresa de Calcuta.
36. “Hay que unirse, no para estar juntos, sino para hacer algo juntos”. – Donoso Cortes.
37. “Algunas veces, el mayor desafío de un jugador viene en relación con su papel en el equipo”. -Scottie Pippen.
38. “Los equipos comparten la carga y dividen el dolor”. -Doug Smith.
39. “Es increíble lo que se puede conseguir cuando a nadie le importa quién se lleva el crédito”. -Robert Yates.
40. “Es literalmente verdad que puedes tener éxito mejor y más rápido al ayudar a otros a tener éxito”. -Napoleon Hill.
41. “Un equipo es una combinación de miles de factores humanos y psicológicos encaminados hacia el mismo objetivo: La victoria”. -Manuel Gomez Brufal.
42. “No importan cuantos logros hayas conseguido, alguien te ayudó”. -Althea Gibson.
43. “No hay problema que no podamos resolver juntos, y muy pocos que podamos resolver por nosotros mismos”. -Lyndon Johnson.
44. “Invito a todos a elegir el perdón en lugar de la división, el trabajo en equipo en lugar de la ambición personal”. -Jean-Francois Cope.
45. “El talento gana juegos, pero el trabajo en equipo y la inteligencia ganan campeonatos”. -Michael Jordan.
46. “Con un equipo entusiasta se puede lograr casi cualquier cosa”. -Tahir Shah.
47. “El trabajo en equipo es el secreto que hace que la gente común logre resultados poco comunes”. -Ifeanyi Onuoha.
48. “La velocidad del jefe es la velocidad del equipo”. -Lee Iacocca.
49. “La colaboración no tiene jerarquía. El Sol colabora con el suelo para traer flores a la tierra”. -Amit Ray.
50. “Mi trabajo es hacer a todo el equipo ejecutivo lo suficientemente bueno como para que sean mis sucesores”. –Steve Jobs.

51 (Bonus) . "Si quieres ir rápido camina solo, si quieres llegar lejos ve acompañado". Proverbio Africano




Tomada de: https://gananci.com/frases-para-trabajar-en-equipo/

Freddie Mercury - Queen - y su definición de equipo (banda)

Hola a todos

Les comparto esta divertida entrevista a Freddie Mercury (vocalista de Queen), aprovechando que todos los estamos recordando por estos días.

Lo más interesante es la definición de banda (equipo) que tienen ellos, ¿les parece conocida?. Espero la disfruten

----

Tu Equipo Ágil no comienza siendo Ágil. Unas poderosas tres razones.

Muchas veces pensamos que por el hecho de poner a personas juntas, pedirles que le pongan un nombre al equipo, asignarles un backlog, automáticamente se convierten en un equipo (1), y no solo eso, creemos que al primer sprint el equipo va tener la velocidad (ej: 50 puntos por sprint)  que planearon - http://www.lecciones-aprendidas.info/2017/12/un-cuarto-metodo-para-estimar-la-velocidad.html -  y que con esa velocidad podremos terminar en una fecha determinada el primer release ( ej: si el primer release se estima en 350 puntos, lo tendremos en 7 sprints).

La verdad, esto es lejano de la realidad, los equipos toman un tiempo en crearse y madurarse - tal vez  8 sprints, más o menos, y esto dependerá de muchos factores - y alcanzar un buen desempeño, en este post compartiré las razones por las cuales esto se presenta y algunas recomendaciones para ayudarte en este proceso.

1. La Curva de Tuckman

Este modelo muestra las diferentes etapas por las cuales pasa un equipo (2),  ella muestra el esfuerzo que toma lograr el mismo estado de desempeño inicial en el cual se formo el equipo. Solo imaginémonos haciendo parte de un equipo de fútbol, rugby, baloncesto, voleibol, musical - en fin cualquier equipo - y el esfuerzo que nos toma acoplarnos, las veces que debemos jugar / tocar  juntos para sentirnos cómodos los unos con los otros.

2. La Curva del Cambio o Curva "J" (fuentes: Elisabeth Kübler-Ross, Albretch, David Viney y otros)

Ver fuente (3)

Ver fuente (4)

Ver fuente (5) - Un excelente post- 

Las causas por las cuales se transita esta curva son muchas, pues cuando llegamos a un nuevo proyecto se vienen cambios como:

• El nuevo proyecto (obviamente)
• Conocer una nueva tecnolología
• Conocer a mis compañeros
• Conocerme interactuando con mis compañeros
• Conocer un nuevo negocio
• Conocer una nueva metodología
• Conocer una nueva empresa y sus reglas
• Conocer los nuevos sistemas
• Conocer la forma de interactuar en esa organización.

Lo que nos demandará inevitablemente avanzar por esta "J" del cambio y desempeño.

y por último (aunque no sé si sea la última causa, puede que existan más)

3. La Zona de Reducción de Riesgos en TI  de Cockburn

Esta curva ya la habíamos discutido en otro post anterior - ¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)? clic aquí - y observábamos que cuando un equipo supera la zona de adquisición de conocimiento la generación de valor fluye a ritmo constante, por lo tanto, aunque los equipos conozcan:

• la metodología, 
• el lenguaje de programación 
• y la tecnología que están manejando, 

existe el conocimiento que no poseen y que directamente implica un esfuerzo como:

• nuevas reglas de negocio
• los sistemas con los que interactuarán
• la interacción para la empresa en la que estan comenzando a trabajar (suponiendo que son proveedores, aun si son internos pero todos son nuevos)

Y es en consecuencia, natural que exista una fricción inicial para alcanzar rendimiento y puedan jugar bien como equipo scrum o como un equipo ágil.

Ahora, habrá mucha más fricción si:

• la tecnología es nueva
• es primera vez que trabajan como equipo
• es primera vez que interactúan usando la metodología o framework de trabajo

Unas Cuantas Conclusiones

1. Es inevitable pasar por la zona de baja productividad
2. En mi experiencia, he observado que los equipos logran llegar a la Fase Normalización de Tuckman aproximadamente  entre 4 y 8 sprints - sprints de duración de dos semanas-, antes no. Si alguien tiene mejores datos al respecto agradecería mucho los compartiera. 
3. El periodo de 4 a 8 sprints podría ser más largo pero he observado que los ciclos continuos de feedback aceleran el proceso de maduración, permitiendo avanzar rápidamente en la curva J - ver este post donde afirmo que Scrum es un modelo de Auto-Coaching de equipos http://www.lecciones-aprendidas.info/2018/08/scrum-como-modelo-de-auto-coaching.html -.
4. Se requiere de un buen liderazgo situacional del Scrum Master para que este periodo sea cubierto de forma exitosa. - ver este post Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización http://www.lecciones-aprendidas.info/2015/11/como-ensenando-montar-en-bicicleta-como.html -
5. La verdadera velocidad o capacidad del equipo debe considerarse después del ciclo de estabilización, o sea, después del quinto o noveno sprint según el caso.
6. Recordemos que el Product Owner,  el Scrum Master y el Equipo de Desarrollo, son un equipo por lo tanto, todos están padeciendo los efectos de este inicio y acople.
7. Luego de estabilizada la velocidad o capacidad del equipo, la forma de incrementarla poco a poco es:
• promoviendo la excelencia técnica
• no escribiendo código basura, apestoso o "crappy code"
• removiendo la deuda técnica y haciendo refactors estratégicos
• aplicando las prácticas ágiles de desarrollo (pair programming, tdd, propiedad colectiva del código, etc)
• implementando las mejoras identificadas en las retrospectivas
• tener retrospectivas exitosas que le permitan al equipo avanzar en la dirección correcta - ver post http://www.lecciones-aprendidas.info/2017/02/scrum-master-como-continuar-la-mejora.html
• trabajar la felicidad del equipo

Cerrando, Qué recomiendo

1. No es una buena estrategia estar armando y desarmando equipos, se pierden estos procesos de acople, un principio importante a aplicar llevarle proyectos a los equipos en vez de armar equipos para los proyectos, es muchísimo más productivo para todos.
2. Recomiendo que al menos la mitad más uno de los integrantes del equipo sean entre Semi-senior y senior, esto acelera los procesos de formación de equipo y reduce considerablemente la creación de código basura debido a inexperiencia de los Juniors, pues los desarrolladores maduros le hacen mentoring a los nuevos - esto es de bastante importancia en equipos que desarrollan software - 
3. Hacer consciente a las organizaciones que comienzan con scrum, o con cualquier marco ágil,  que sus equipos agiles no van a ser "super- ágiles" y "super productivos" por el simple echo de que los pongamos juntos, con un tablero lleno de post-it, Jira u otro software instalado, un Product Owner y un Scrum Master,  es cierto van a ser mejores que en cascada o tradicional, pero es un hecho las primeras velocidades son lentas, y se requiere de acompañamiento incrementarlas.
4. Se recomienda hacer las proyecciones de cuando se va a entregar el producto luego de la fase de estabilización, antes no tiene sentido hacer proyección alguna, 
5. Liderazgo situacional es clave en este tipo de procesos. Sugiero se revise esta colección de post Tips para Comenzar con un Equipo Scrum - http://www.lecciones-aprendidas.info/search/label/comenzando%20con%20scrum proporciona herramientas útiles en el proceso de maduración y estabilización de tu equipo.

Hasta acá este compartir. Bienvenido el feedback.

Saludos Ágiles

Jorge Abad.

Notas, Comentarios, Observaciones y Referencias

1. Les recomiendo este artículo de Martín Alaimo - http://www.martinalaimo.com/es/blog/hacia-un-equipo-real - y la serie de "Hacia un Equipos Real" - http://www.martinalaimo.com/es/blog/tag/equipos-reales-.
2. Explicación de la curva de Tuckman en este post:  Equipos Estables por sobre Pool de Recursos - http://www.martinalaimo.com/es/blog/equipos-estables
3. Curva de Cambio - http://activaconocimiento.es/curva-de-cambio/
4. Las fases que vivimos ante un cambio -https://elpais.com/elpais/2013/12/16/laboratorio_de_felicidad/1387150998_138715.html
5. Falsos Positivos (agárrense que vienen curvas) https://wynwin.wordpress.com/2013/05/10/falsos-positivos/

¿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 Cambiar el Sprint a no más de tres semanas (4 semanas no lo recomiendo de verdad), y tener ese tamaño como estándar de ahora en adelante Reducir el tamaño de las historias de usuario, aplicando patrones de división y haciéndolas menos complejas. (Sugiero la lectura de este post: Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint - cilc aquí-) 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): Reducir el tamaño de las historias de usuario, aplicando patrones de división y haciéndolas menos complejas. (Sugiero la lectura de este post: Esfuerzos Sugeridos de Historias de Usuario según la Duración del Sprint - cilc aquí-) 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): No aceptar las historias de usuario que no cumplen la Definition of Ready (DoR). Suigiero leer este post de Johnny Ordoñez - La Definición de “Ready” es tan importante como la Definición de “Done” - Clic aquí - 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. No aceptar las historias de usuario que no cumplen la Definition of Ready (DoR) y no tienen sus dependencias resueltas o construidas previamente. Suigiero leer este post de Johnny Ordoñez - La Definición de “Ready” es tan importante como la Definición de “Done” - Clic aquí - Tener muy buena arquitectura de componentes y crear contratos, APIs, interfaces de componentes entre el trabajo de los diferentes equipos, de forma que se puedan generar resultados. Crear Mocks basados en contratos que emulen el trabajo de los otros equipos. 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

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.

Tarjetas que ayudan a identificar y remover impedimentos: Impediment Cards

Hola a todos

En un gran equipo del cual tuve la fortuna de ser parte de ellos durante un año como Scrum Master generamos una base de conocimiento para ayudar a identificar impedimentos en el proceso de desarrollo, de forma que la consultaba el team member:

• cuando algo no funcionaba
• cuando no sabíamos que pasaba con el sistema
• cuando estaba el desarrollador bloqueado y no se le ocurría como solucionar el impedimento
• y en especial para ayudar a los novatos en su búsqueda de respuestas, pues muchas veces estos no querían cubrir su curva de aprendizaje y preguntan incesantemente al programador experto hasta colmarle la paciencia (¿o no les ha ocurrido esto en sus equipos?).

La estrategia consistía en primero revisar la base de conocimiento y si esta no ayudaba a resolver el problema, sí pedir ayuda a un compañero experimentado, o a todo el equipo en pleno. (en algunas ocasiones a los novatos, sino cumplían revisar la base de conocimiento no se les ayudaba - este fue el acuerdo de equipo -).

Esta base de conocimiento decidimos que en vez de manejarla como una lista de verificación (o checklist), sería un grupo de tarjetas individuales con una pregunta a ser resuelta o que da pistas de donde buscar el error o problema al cual se esta enfrentando el desarrollador o team member, poco a poco fuimos engrosando las tarjetas a medida que nos encontrábamos con problemas típicos o ganábamos experiencia. A continuación les comparto el listado que contenía el mazo de cartas "Impediment Cards":

• ¿Revisaste los webconfig, web.xml o el xml de configuración de la aplicación?
• ¿Leíste bien el mensaje de error?
• Insisto: ¿Leíste bien el mensaje de error y comprendiste que te decía?
• ¿las IP son las correctas?
• ¿el proxy lo está bloqueando?
• Si es un bug ¿le preguntaste el correcto funcionamiento al Product Owner?
• ¿revisaste si las contraseñas cambiaron?
• No tiene lógica pero: reiniciaste ¿el IDE, El PC, El server, y/o bd?
• ¿borraste caché?
• ¿Reiniciaste el server para que reflejara los cambios?
• ¿Seguro revisaste detalladamente el archivo de configuración?
• ¿Tienes correctamente instaladas las dependencias?
• ¿hiciste una correcta conversión de tipo de dato?
• ¿será que el puerto o la IP están bloqueados en tu PC o en el Server?
• ¿el usuario de cualquiera de los sistemas le quitaron o expiraron los permisos?
• ¿Verifique si la versión del software es la soportada?
• ¿el usuario tiene permisos / no tiene permisos?
• ¿los servicios, bases de datos, etc apuntan a la dirección correcta o al ambiente correcto?
• ¿la memoria RAM esta copada?
• ¿el disco duro esta copado?
• ¿soportamos la versión del navegador y/o del sistema operativo?
• ¿los sistemas base tienen los parches?
• ¿se encuentra sobre la versión del framework correcta?
• ¿la versión del sistema operativo es la soportada?
• ¿la versión sobre la cual se reporta el problema AUN DAMOS SOPORTE SOBRE ELLA?
• ¿El tipo de dato en el software es el mismo que en la base de datos?
• ¿las trazas, logs corresponden a la fecha de análisis del problema (fecha y rangos correctos)?
• ¿hiciste copy-paste?, si es así, ¿no te parece mejor crear una clase, método que haga lo mismo?
• Si la consulta esta lenta: ¿el procedimiento almacenado o consulta tiene un MAX, sobre una tabla de millones de registros?
• ¿revisaste la documentación oficial del framework o componente?
• ¿revisaste si el problema es de TIPO DE DATO?
• ¿buscaste en Google?
• ¿leiste bien el mensaje de error o log? ¿lo entendiste?
• ¿lo solicitado se encuentra dentro de la garantía o del alcance del proyecto?
• ¿estás lanzando y capturando la excepción?
• ¿estás en el BRANCH correcto del proyecto o versión?
• ¿hiciste DEBUG paso a paso?
• ¿estás trabajando con las últimas versiones de los fuentes?
• ¿revisaste conectividad, (incluido el cable)?
• ¿la tabla tiene índices?
• ¿borraste las cookies? (Fuente: Heimar Vega)
• ¿borraste el historial del explorador? (Fuente: Heimar Vega)
• ¿Se desplegó la versión correcta?(Fuente: Heimar Vega)
• ¿Se ejecutaron las pruebas unitarias? (Fuente: Heimar Vega)
• ¿verificaste estar conectado a la vpn? (Fuente: Anónimo)
• ¿Verificaste si el servicio está operativo? (Fuente: Anónimo)
• ¿Verificaste si la estructura del wsdl es la misma? (Fuente: Anónimo)
• Problemas de rendimiento : Millones de registros , sugiere el uso de tablas históricas
• ¿Todos los componentes de la solución corresponden a la misma versión?
• ¿el web server se encuentra arriba? ¿la base de datos se encuentra arribla? ¿hiciste PING?
• ¿preguntaste si esto había ocurrido antes?
• Penúltima opción: Seguro: ¿buscaste en Google?
• Última opción: No siendo más, pregúntale a un compañero

Estas cartas estaban disponibles en el "lugar o zona lúdica del equipo", allí donde teníamos fotos, chistes para leer, dibujos para colorear y descansar, entre otras cosas (¿tienes un espacio para tu equipo en tu zona de trabajo?, es una buena práctica y genera cohesión e identidad de equipo)

Hasta acá este pequeño y poderoso compartir, si tienes más causas de impedimentos típicas que puedas compartirme para agrandar la lista te lo agradecería, y si lo ves útil compártelo y con base en este listado crea tu propio mazo de cartas de Impediment Cards.

Las ImpedimentCards las puedes descargar aquí

Saludos ágiles

Jorge Abad

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

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

Responsabilidad de Equipo

"Si uno de los miembros del equipo falla, el equipo entero falla. Ninguna de las tareas es la tarea de un individuo" https://t.co/GbHrHNRRKD

— Lucho Salazar (@luchosalazarc) September 28, 2016

Tip de Scrum: La calificación del Product Owner al finalizar el Sprint

Hola a todos

Scrum es un framework que se va enriqueciendo en un equipo sprint tras sprint de prácticas y tips , hoy quiero compartirles una pequeña práctica(1) de bajo costo y alto impacto para el equipo, la cual detallo a continuación.

Al finalizar el Review el Scrum Master solicita al Product Owner (PO) que califique el Sprint en términos ¿Qué tan útil y de valor fue el incremento entregado? o ¿Qué tanta alineación tiene el incremento entregado con el objetivo del sprint?

 "sin importar cuantos puntos o historias se entregaron, sino centrándose en el valor recibido", 

el PO lo podrá calificar en un escala de 1 a 5 (o la que elijamos) de la siguiente manera:

5 - El incremento estuvo genial, asombroso
4 - El incremento estuvo bien y satisfactorio
3 - El incremento no era todo lo que esperaba
2 - Al incremento le faltaron elementos importantes
1- El incremento lamentablemente no fue satisfactorio

y luego que nos explique la razón de este valor, esta última parte es de mucho valor para el equipo para que este comprenda el norte hacia el cual se dirige el producto.

Estos dos aspectos calificación y explicación, le sirve de motivación, dirección y feedback al equipo y es un importante insumo para la retrospectiva, pues se pueden dar los siguientes escenarios:

• Hacer menos puntos o historias de los esperados pero generar mucho valor al PO,
• Hacer muchos puntos o historias pero no hacer lo que le genera valor al PO, o
• Cumplir las expectativas del PO para el sprint.

Hasta acá esta sencilla y poderosa práctica, espero me compartan los resultados de usarla y todo feedback será bienvenido.

Saludos ágiles y hasta la próxima

Jorge Abad

Notas, Aclaraciones, Comentarios y Referencias

1. Escuche esta práctica en el DevHangout  "Técnicas para formar equipos ágiles #devHangout 133 con @chuzzete" donde Jesús Méndez - @chuzzete habla de su libro "Técnicas para formar equipos ágiles" y días después me la recordó mi estimado amigo y agilista Carlos Gil - @cafegifo en la actividad de Migas de Pan.

Algunos tweets sobre Agilidad y Scrum

"la gente no va a extrañar lo que no tiene" @camilohenao1 #lean #agile #ProductOwner #scrum #mvp

— Jorge Hernán Abad L. (@jorge_abad) 22 de septiembre de 2016

---

"Los equipos son inmutables, cada vez que alguien entra o sale es un equipo nuevo, no uno modificado" @richardadalton #Agile #scrum #Genial pic.twitter.com/V1jz9ohaJw

— Jorge Hernán Abad L. (@jorge_abad) 22 de septiembre de 2016

---

#PreguntaPoderosa de @pmejia7 sobre #MVP

"¿Cómo puedo resolver progresivamente el problema de negocio del #ProductOwner?" #agile

— Jorge Hernán Abad L. (@jorge_abad) 21 de septiembre de 2016

---

El #ScrumMaster es el responsable de la fluencia de su equipo, de disminuir y eliminar la fricción Sprint tras Sprint #Agile #Scrum

— Jorge Hernán Abad L. (@jorge_abad) 21 de septiembre de 2016

---

Cambio en preguntas del #daily con @cafegifo

Qué logre ayer
Qué voy a lograr hoy
Qué me lo está impidiendo pic.twitter.com/DmrpjAfffP

— Jorge Hernán Abad L. (@jorge_abad) 17 de septiembre de 2016

Cómo leer la serie: Comenzando con un equipo Scrum

Hola a todos

Desde hace un tiempo he estado publicando posts bajo la etiqueta "comenzando con scrum", en este post quiero presentarles la forma de leerlos y acercase a ellos para obtener el mejor provecho:

1. Actividades para activar un equipo el primer día, team canvas y otras técnicas - clic aquí.
2. Personal Maps - Mapas Personales - clic aquí.
3. Parte 1 - Los Cuatro Acuerdos - clic aquí.
4. Parte 2 - Ciclo de vida de los equipos - clic aquí.
5. Parte 3 - Dando Feedback - clic aquí.
6. Parte 4 - Triángulo dramático de Karpman - clic aquí.
7. Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado - clic aquí.
8. Empezar una Retrospectiva y la Directiva Principal de las Retrospectivas Ágiles - clic aquí.
9. Saber escuchar, escucha activa - clic aquí.
10. Bonus Track | Entrenando la Inteligencia Emocional - clic aquí.
11. Liderazgo Agil y otros temas por Gustavo Quiroz. - clic aquí.

Espero este orden les sea de ayuda

Saludos ágiles

Jorge Abad.

Comenzando con un equipo scrum: Personal Maps - Mapas Personales

Hola a todos

He notado en la vida que pequeñas acciones generan gran impacto, y hoy quiero compartirles algo que cumple estas características, que habilita la generación de equipo (1) entre quienes regularmente son compañeros de trabajo o integrantes de un grupo, esta sencilla herramienta son los Mapas Personales - o Personal Maps -(2), técnica en la cual empleamos un mapa mental para contar quienes somos (3). Este mapa mental se construye poniendo nuestro nombre en el centro y alrededor se complementa con diferentes aspectos que son detallados según se requiera, estos aspectos pueden ser.

• Educación
• Familia
• Trabajo
• Valores
• Objetivos - metas
• Hobbies
• Casa
• Amigos
• Tres momentos importantes de la vida (4)
• entre otros

Realizando este sencillo mapa todos sabrán mejor quienes somos y nos ayudará acortar la transición  entre ser compañeros de trabajo a un verdadero equipo.

Mapa Personal / Personal Map - Elaborado para el Taller de Energizando Equipos con Técnicas de Management 3.0 (5)

Sugiero que el Mapa Personal se elabore cuando estamos comenzando a crear un equipo de trabajo, y para su construcción sugiero dos técnicas:

1. Cada cual elabora su mapa y lo explica a sus compañeros
• Elaboración 10 minutos
• Explicación 20 minutos (suponiendo un equipo máximo de 10 personas, tal vez tome más o menos tiempo dependiendo de la cantidad de integrantes)
2. Otro elabora y explica mi mapa
• Las personas que van a conformar el nuevo equipo se dividen en parejas 
• cada pareja se entrevista mutuamente, elabora el mapa de su compañero (tiempo 10 minutos)
• Cada persona explica el mapa de su compañero a todo el equipo (tiempo aproximado 20 minutos)

Luego estos mapas se pegan en la pared para que estén disponibles para todos y de esa manera se ayuda a mejorar las interacciones pues comprendemos que detrás de cada uno hay una vida, un otro, y no solo un cargo o rol con el cual interactuar.

Bienvenido el feedback y los resultados de esta experiencia

Saludos ágiles

Jorge Abad

Notas, aclaraciones, comentarios y referencias

1. Esta técnica la conocí gracias a mi gran amigo Lucho Salazar - @LuchoSalazarC, agilista y apasionado por el Management 3.0 - lugar de donde viene esta técnica - .
2. Management 3.0 Practice: Personal Maps
3. Quienes somos es muy ambicioso, pero presenta algunos rasgos principales 
4. Sugerido por mi
5. Taller facilitado por Lucho Salazar y Mi persona (su servidor)

El compromiso del Sprint mal entendido

Hola a todos

En scrum durante el planning del sprint se establecen varias premisas para poder avanzar bajo el escenario de la incertidumbre:

• La primordial: Cual es objetivo del sprint, ¿qué capacidad de negocio queremos proporcionar al final del ciclo?
• Las secundarias:
• Entender qué se va a construir (parte estratégica)
• Decidir dada la capacidad del equipo cuantos ítemes de backlog cree el equipo que es capaz de llevar al DONE / COMPLETADO / TERMINADO (recomiendo este post Uno de los objetivos secundarios del planning no es la puntuación, sino determinar con cuanto se compromete el equipo dada su capacidad )
• Decidir cómo se va a construir (parte táctica)

Y durante todo el sprint, el equipo trabajará en:

• cumplir el objetivo del sprint
• Construir la mayor cantidad de producto posible(1) (software) que tenga calidad y valor durante el tiempo laboral del sprint y según las prioridades establecidas en el planning. (ver poster de responsabilidades de los diferentes roles durante el sprint - clic aquí)

Pero no todos lo entienden así

Existen implementaciones de scrum donde:

• el compromiso TIENE que ser cumplido
• el compromiso es IMPUESTO
• se considera al sprint como una mini-cascada
• existe un microcontrol durante todo el sprint
• y la gerencia se "montó" en scrum sin entender como funcionaba y solo por moda

Es allí donde se observan escenas como la siguiente

Aunque es cómica la exageración, se que varios de los que leemos este blog (incluido yo) hemos estado en situaciones así, les confirmo, este no es el espíritu de Scrum, esto no es lo que se busca, además esto no es Scrum.

Respecto a la escena, si al final del ciclo si la cantidad de ítemes identificada no es cumplida, pues se realizará una retrospectiva y se mirará como mejorar tanto en lo técnico, táctico como en en las relaciones para ser exitosos el próximo ciclo.

Ojo, no se trata de que si no logramos el objetivo, no nos importe (2), pero tampoco se trata de imposiciones al equipo, se trata de poder trabajar de forma autogestionada, táctica,  profesional y con foco durante el periodo del sprint para hacer lo más que se pueda, con calidad y valor.

Espero haber ayudado un poco al entendimiento de este aspecto.

Saludos ágiles y bienvenido el feedback

Jorge Abad

Notas, aclaraciones, comentarios y referencias

1. "Posible" se refiere a que dados los impedimentos, la incertidumbre, las habilidades técnicas, el equipo, se construirá lo más que se pueda bajo el escenario que se presente.
2. Recomiendo ver este post para entender mejor esta afirmación -Un gran poder conlleva una gran responsabilidad. Una reflexión sobre la falsa concepción de autogestionado- .
    

¿Cuáles son las fronteras de un scrum master como coach?

(1) Esta imagen muestra el área de influencia y trabajo del Scrum Master (solo el trabajo de equipo y el proceso scrum), el resto es área de trabajo personal

Hola a todos

Hace unos días reflexionaba sobre ¿hasta dónde debería llegar el Scrum Master en su rol de Coach del Equipo y del Product Owner?(2)(3), pues muchas veces observo compañeros que estoy acompañando en este proceso de ser Scrum Master  en líos cuando aparecían personas dentro de sus equipos que:

• no querían o no les interesa trabajar en equipo
• son lobos solitarios
• son perezosos 
• incumplen frecuentemente sus compromisos ante el equipo
• maltratan constante a sus compañeros con su comportamiento y palabras
• son tóxicos
• o que con su dinámica de día a día afectan de forma negativa al equipo de trabajo

Estas personas se convierten en un reto tanto para el equipo como para el scrum master, ni con las retrospectivas, ni con sesiones personales de feedback se logra que las condiciones mejoren, es allí donde el Scrum Master debe reconocer que este no es su área y debe delegar esto en talento humano organizacional (o recursos humanos - como se llama en algunas empresas -), en este caso es posible que se activen varios caminos:

• el team member comience un trabajo de mejora acompañado por talento humano
• el team member comience un trabajo sicologico
• el team member no continue trabajando con el equipo
• el team member no continue en la organización

No son caminos fáciles, pero en Agile las disfunciones se evidencian más rápido pues los ciclos cortos de feedback habilitan que los problemas salgan mas pronto a flote.

Espero este post sea de ayuda, bienvenido el feedback


Saludos ágiles
Jorge Abad

Notas, aclaraciones, comentarios y referencias

1. Esta imagen muestra el área de influencia y trabajo del Scrum Master (solo el trabajo de equipo y el proceso scrum), el resto es área de trabajo personal
2. Realicé esta pregunta al foro de ágiles latinoamérica  para ver las respuestas  hacer clic aquí
3. También realice a Martin Alaimo @MartinAlaimo (autor y agilista de renombre en Latinoamérica) y esta fue su respuesta: "Desde el punto de vista del Coaching, uno debería darse cuenta cuándo alguien está fuera de las posibilidades del coach y ahí entra en juego la humildad para decir "con esto yo no puedo" y derivar el caso a un profesional"

Algunos Tweets sobre Agilidad

"¿Si la organización no realizara este proyecto / producto, que impacto tendría?"@pmejia73 #ProductOwner #PreguntaPoderosa #AgileInception

— Jorge Hernán Abad L. (@jorge_abad) 29 de junio de 2016

---

"todo agilista debe preguntarse cada día
¿si hoy se interrumpe el proyecto, que producto de valor le dejé al negocio?" @pmejia73

— Jorge Hernán Abad L. (@jorge_abad) 29 de junio de 2016

---

This is so brilliant :) Really awesome :) “The Enemies of Adaptability” #agile #hr #leadership pic.twitter.com/f7bv5qxHmr

— Luis Gonçalves (@lgoncalves1979) 28 de junio de 2016

---

Implementa historias de 1/10 a 1/6 máximo de la velocidad del equipo https://t.co/b2DBcLJaUC#Ágil #Incremento #Scrum #HistoriaDeUsuario

— Lucho Salazar (@luchosalazarc) 28 de junio de 2016

---

The currency of Agile should be working software, not a velocity of story points. #agile #lean ^ @troytuttle pic.twitter.com/tI8XSQp0ra

— AgileFortune (@AgileFortune) 26 de junio de 2016

---

---

a coach is responsible for identifying and inducing productive discomfort ^ @KentBeck pic.twitter.com/8QWIdn49Cr

— AgileFortune (@AgileFortune) 23 de junio de 2016

---

"Responding to Change" is impossible unless code is easy:
to change
to maintain
to fix
to enhance. ^ @WoodyZuill pic.twitter.com/USVMuwwSSe

— AgileFortune (@AgileFortune) 21 de junio de 2016

---

Cambio de paradigma para el Testing Ágil
por @henrikkniberg #Agile #Scrum #Testing #AgileTesting pic.twitter.com/aBipD4wyJl

— Jorge Hernán Abad L. (@jorge_abad) 15 de junio de 2016

---

Definitivamente #TodoCambia y mucho más el sw
El problema radica en como responder al cambiohttps://t.co/ANeUFZ2taC pic.twitter.com/AT66hGzwI3

— Jorge Hernán Abad L. (@jorge_abad) 14 de junio de 2016

---

Tip para un Equipo #Scrum

Planear cada sprint la remoción de la #DeudaTécnica#TechnicalDebt #Agile pic.twitter.com/HP3rVP3GU1

— Jorge Hernán Abad L. (@jorge_abad) 14 de junio de 2016

---

#Agile es una cultura no un proceso
Pero la cultura Agile si generará un estilo #LEAN de procesos
Es crítico entonces hackear la cultura

— Jorge Hernán Abad L. (@jorge_abad) 24 de junio de 2016

Muchas veces lo más importante del daily ocurre después

Hola a todos

El daily (Scrum Diario o Daily Scrum ) es una reunión de sincronización del equipo que es facilitada por el Scrum Master, que se hacen de pie y donde cada miembro del equipo responde tres preguntas poderosas:

• ¿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? (según la Guía de Scrum)

O más simple

• ¿Qué hice ayer?
• ¿Qué voy a hacer hoy?
• ¿Qué impedimentos tengo?

Esto se contesta rápidamente dentro de los 15 minutos del timebox establecidos, eso si,  evitando los antipatrones (clic aquí), pero a los scrum master y a los equipos que comienzan con scrum les realizo las siguientes sugerencias y ellos determinan si las adoptan o no.

• Al equipo
• Tomar nota o tratar de recordar los temas que les llamen la atención de sus compañeros para ser resueltos luegos del daily
• Al Scrum Master:

• Tomar nota de los impedimentos con fecha en que se originan ya sea en notas adhesivas (post-it) para el kanban de impedimentos o en alguna otra parte para ser resueltos. Ojala lo más visible posible, para poder reaccionar rápido.
• Tomar nota de temas que le estén haciendo "ruido"-(llamando la atención o smells) del daily para ser resueltos para preguntarle a alguien o al equipo, después del daily.
• Apenas el último miembro de equipo  finaliza el daily, decir abiertamente 
• "FINALIZÓ EL DAILY" o "AQUÍ TERMINA EL DAILY" (o algo similar)
• y luego decir (permitiendo el incomodo silencio cuando sea necesario):
• los impedimentos identificados son este y este, ¿están de acuerdo?
• ¿alguien quiere compartir algo, u observó que puede ayudar a alguien o necesitar ayuda?
• ¿algo que necesite ser resuelto de primero?
• Y después de un silencio decir por ejemplo:  "listo equipo vamos a trabajar" o esperar a que otro lo diga.

Es por eso que yo digo que:

Muchas veces lo más importante del daily es lo que ocurre un segundo después de finalizada esta conversación #Scrum #agile

— Jorge Hernán Abad L. (@jorge_abad) 21 de junio de 2016

Ámbitos del Proyecto y del Producto en Scrum

Hola a todos

Siguiendo con la serie (http://www.lecciones-aprendidas.info/2016/05/ambitos-del-producto-y-del-proyecto.html ), les comparto dónde está ubicado el Equipo Scrum (el cual esta compuesto por Product Owner, Scrum Master y Team Members) dentro del ámbito del Producto y del Proyecto

Saludos Ágiles

Jorge Abad

Poster: Responsabilidades Durante el Sprint de los Tres Roles de Scrum

Hola a todos

Les comparto este poster de las responsabilidades de los diferentes roles de Scrum durante diferentes momentos del tiempo durante los sprints.

En los entrenamientos que dicto ayuda a resolver muchas inquietudes.

Para descargar el archivo en alta resolución

• con formato pdf hagan -clic aquí-

Saludos ágiles
Jorge Abad

Equipos Scrum: El equipo es multifuncional, no los team members polivalentes

Hola a todos

Cuando alguien se aproxima a Scrum (desde el desarrollo de software), se encuentra con que los equipos son multifuncionales (1) y comienza a buscar en la literatura y en las experiencias de otros equipos, como rayos implementar esto.

Comprendemos que multifucional consiste en tener todos integrantes requeridos con las habilidades (skills) requeridas para lograr un incremento en la construcción del producto, es decir, ya no esta tester y desarrollo aparte, sino que trabajan juntos.

                  - ¿como así?,
                     ¿ya no nos podemos acusar mutuamente?

                  - pues si, ya no son ellos y nosotros,
                    ya somos un solo team (wow, tremendo cambio)

Activando un riesgo

En esa búsqueda de referentes en internet, se encuentra que equipos muy maduros no tienen personas con el rol de tester, sino que el equipo toma sobre sí la responsabilidad del producto, y por ende,  se puede caer en una interpretación riesgosa es: "no necesitamos personal de testing, la calidad del producto debe ser garantizada por el equipo de desarrollo", no digo que este enfoque esté del todo mal, pero perdemos de tajo las habilidades de alguien experto en calidad del producto y le delegamos esta responsabilidad al equipo de trabajo que deberá aprender:

• a verificar el producto,
• a aprender de estrategia de pruebas
• a buscar lo que no se ha perdido, 
• es decir, intentar casos de prueba extraños para identificar comportamiento del producto.
• adicional, los desarrolladores tienden a probar los caminos que saben que funciona, lo que deja huecos "funcionales" o "no funcionales".
• Solo un desarrollador con gran disciplina y orientado a pruebas (tdd - test driven development) cubriría muchos de estos escenarios sin garantizarlo - y la verdad de eso he visto poco en estos años -.
• a pensar como usuario
• entre otras fortalezas de un buen tester

Implicando que los team members sean polivalentes(2), esto se puede lograr con el tiempo - no lo dudo -, pero esta transición deberá pagarla alguien con plena seguridad:

• el equipo: pues le reclamarán tempranamente por habilidades que no tiene
• el cliente: recibirá un producto que no tendrá full "Done / Terminado / Completado"
• el scrum master: le dirán que por que no removió este impedimento oportunamente
• el product owner: pues confió en el equipo y este le entrego un producto que tiene alta probabilidad de incidencias
• la empresa proveedora: por el desagrado del cliente y el desgaste del equipo de trabajo.

Qué significa realmente un equipo multifuncional

La multifucionalidad significa que tenemos todos los roles y solo los roles requeridos para lograr el incremento del producto - ya lo había dicho -, por lo tanto, es muy probable que un buen Equipo de Desarrollo para software podría estar constituido por:

• Desarrolladores de software
• Tester
• Tester automatizador (depende del proyecto y producto)
• Base de datos (depende del proyecto y producto)
• Diseñador gráfico  (depende del proyecto y producto)

Pues lo que se quiere en "Agile" es romper los silos y permitir que quienes saben construir la solución interactúen de forma más efectiva y eficaz, sin tropiezos y barreras burocráticas.

No dudo - como me ha sucedido - que los miembros del equipo comiencen a compartir conocimiento y a enseñarle a otros para verse apoyados en momentos que el producto tiene un aumento de esfuerzo en un tipo de especialidad específica, me ha sucedido que:

•  los testers se apoyan en sus compañeros de desarrollo para probar, 
• o que desarrolladores enseñan a testers a programar,
• expertos de bases de datos y desarrolladores
• etc

 y así poco a poco lograr una "polivalencia" pero el equipo reconoce en que hay al interior expertos que lideran un campo de conocimiento y se apoyan en ellos para encontrar la mejor solución.

Hasta acá la reflexión del día de hoy, espero les haya servido, pues encontrar quienes hacen todo bien es más difícil que encontrar quienes hagan bien unas cuantas cosas.

Saludos ágiles

Jorge Abad.

Notas y Aclaraciones:

• (1) Guía oficial de Scrum (clic aquí)
• (2) Polivalente: que vale para muchas cosas (clic aquí: http://dle.rae.es/?w=polivalente), en la industria de la manufactura, significa que puede realizar correctamente muchas labores