domingo, enero 18, 2015

[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 

No hay comentarios.:

Publicar un comentario