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/

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

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

[scrum] Un buen Team Member

Existen muchos post sobre Product Owner  y el Scrum Master, y es bueno reflexionar sobre ellos pues son roles que estamos comprendiendo y haciendo parte de nuestra cultura TI que tanto tiempo ha estado  RUP-pizada o Waterfall-izada.

Pero sobre los Team Member en scrum, solo sabemos dos elementos claves, el equipo debe ser:

• multidisciplinario
• autoorganizado o autogestionado

De igual forma sabemos que los valores del Equipo Scrum ( Team Developer, Scrum Master, Product Owner (1) ) son:

• Enfoque
• Coraje
• Apertura
• Compromiso
• Respeto (ver más valores en este post anterior sobre valores ágiles (2)  )

Yo he notado que en la medida que el equipo comienza a tomar vida (pues no es un acto mágico que se convierta en autoorganizado) comienzan a emerger reglas éxplicitas e implícitas sobre los team members que son quienes perciben el latir y son el propósito de scrum (darles el entorno para que ellos produzcan el mejor producto)

Entre esas reglas, he observado varias:

• En el Planning
• Hacer preguntas para entender lo que se va a construir
• No permitir que el equipo se comprometa con cosas que no conoce
• Poner a disposición de todos mi experiencia para construir correctamente lo que se esta comprometiendo
• Dar mi estimación responsable.
• En la Ejecución del Sprint
• Llegar puntual al daily
• No dejar tirado a mi equipo con el compromiso (pues estuve en el Planning y junto con todos acepte el sprint backlog)
• No tener tiempos de ocio "irresponsables*" cuando todo mi equipo esta trabajando por bajar puntos
• Ayudar a mis compañeros
• Escribir buen código
• Realizar buenas pruebas
• Construir el producto con la calidad inmersa (no postergar la calidad esperando que otros encuentren defectos)
• Trabajar empleando la mayor cantidad de prácticas ágiles de desarrollo posibles (TDD, ATDD, Integración Continua, etc)
• Si se identifica algún sobreesfuerzo oculto, levantar la mano y dar visiblidad al equipo y al Scrum Master
• Preguntar dudas sobre el producto al Product Owner
• Dar visibilidad y alerta sobre los Impedimentos al equipo y al Scrum Master
• Dar feedback asertivo a compañeros que perdieron el "foco" y andan muy ocupados en no apoyar al equipo o haciendo nada.
• Reconocer cuando se esta fallando y corregir camino
• Ser honesto con el equipo y consigo mismo
• Mostrar el coraje y foco durante el sprint.
• Dar visibilidad de la deuda técnica
• Trabajar por reducir al  máximo la deuda técnica
• Mejorar las habilidades en el área de fortaleza técnica y trabajar con otros para aprender nuevas tecnologías de manera que se elimine en lo posible el riesgo de dependencias de compañeros de trabajo.
• Continuar la autoformación técnica
• Trabajar con coraje para lograr el DONE lo antes posible de cada funcionalidad comprometida
• Trabajar en lo que está priorizado y no en lo que "me parece"
• En el Review
• Tener el review preparado 
• Dar respuesta asertivas a lo que se requiera
• Apoyar a que el equipo se luzca en la sesión
• En la Retrrospectiva
• Dar y recibir retroalimentación
• Usar comunicación asertiva con todos los miembros del equipo
• Reconocer cuando se falla
• Aportar evidencias para la retrospectiva
• Decir todo aquello que sienta que debe ser compartido y aporta a la sesión (tanto del punto de vista técnico como humano)
• Ser honesto con el equipo y con sigo mismo.

Nota:

Este post seguirá en construcción pues este aprendizaje no termina.

---

* Ocio irresponsable (vale la pena aclararlo): no me refiero a los tintos o momentos de pausa que requerimos para seguir avanzando, me refiero - y creo que todos entendemos - a laaaargas y descaradas sesiones en cualquier cosa que no sea una pausa sincera.

Referencias 

(1) Scrum Alliance - Core Scrum

(2) Valores Ágiles - Charla de Ágiles 2014 (Parte 1)