Últimamente hablamos mucho de lo que es un buen Development Team en Scrum, de equipos multidisciplinares, equipos autoorganizados, empoderamiento de equipos, Development Team que sea capaz de entregar valor… pero ¿Cómo sabemos que tenemos a este buen equipo? ¿Qué métricas tenemos en cuenta para ello? ¿Qué características tiene un buen Scrum Development Team?

Hace tiempo, escribimos un post sobre cómo podemos comenzar a reflexionar sobre un equipo Scrum de desarrollo perfecto, cambiando de mentalidad de silos o proyectos a productos o cadena de valor. Antes de lanzarnos a ver las características de un Dev Team en Scrum, repasemos lo que nos dice la guía sobre un Scrum DT (te recomiendo que la leas de vez en cuando).

Qué nos dice la guía Scrum sobre un Development Team

Según la Guía Scrum, un equipo de desarrollo está formado por profesionales que trabajan juntos para entregar un incremento de producto “HECHO” potencialmente liberable al final de cada Sprint (aquí hay un mito sobre que solo se entrega al final del Sprint). Sólo los miembros del equipo de desarrollo crean el incremento. Estos están estructurados y empoderados por la organización para gestionar y organizar su propio trabajo. La sinergia resultante optimiza la eficiencia y eficacia general del equipo.

Equipo de desarrollo en scrum

Los equipos de desarrollo tienen las siguientes características:

  • Autoorganizados. Deciden cómo convertir los PBIs (Product Backlog Items) en soluciones.
  • Multifuncionales. En conjunto, tienen todos los skills necesarios para crear el incremento del producto. Para este punto, hay que pensar en la cadena de valor, ¿Qué queremos producir? ¿Qué skills necesitamos para ello?
  • No hay títulos. Todos son desarrolladores de producto, nadie tiene un título especial.
  • No hay sub-equipos en el equipo de desarrollo.
  • Comprometidos con el Sprint  Goal y la entrega de un incremento de alta calidad. Algo que falla en muchos equipos. La calidad no es negociable. ¡Lo barato sale caro!

Y qué más puede caracterizar un equipo de desarrollo en Scrum

  • Persigue la excelencia técnica: Los grandes equipos de desarrollo utilizan eXtreme Programming como fuente de inspiración (el gran olvidado). XP proporciona prácticas y reglas que giran en torno a la planificación, el diseño, la codificación y las pruebas. Ejemplos de ello son la refactorización, Pair Programming ( Si piensas que el Pair Programming no vale de nada, prueba llevarlo al extremo con Mob Programming, la he probado en varias ocasiones y el resultado es increíble, ¡experiméntalo!), la integración continua, las pruebas unitarias y las pruebas de aceptación.

libro de extreme programming

  • Utiliza SPIKE. Un DT utiliza este concepto para descubrir el trabajo necesario para llevar a cabo en una tarea ambigua. Los grandes equipos de desarrollo utilizan experimentos para resolver problemas técnicos, de arquitectura o de diseño.
  • Refina el Product Backlog como un equipo: Los equipos de desarrollo en Scrum consideran que el refinamiento del Product Backlog es un esfuerzo de todo el equipo. Entienden que la calidad del Product Backlog es la base para un ritmo de desarrollo sostenible y la buena construcción de grandes productos. 
  • Cuestionan las ideas, y no critican a las personas ni las atacan. Sino que las respetan. 
  • Compartir experiencias. Los buenos equipos de desarrollo comparten experiencias con sus compañeros. Esto puede ser dentro de la organización, también lo pueden hacer en conferencias, meetup, etc. Muchos equipos suelen hacer sesiones de Lunch and Learn para ello también. 
  • Entiende la importancia de tener un poco de pausa. Los buenos equipos de desarrollo tienen cierta pausa en su día a día. Los seres humanos no pueden ser productivos todo el día. Ya hemos pasado de trabajadores manuales a trabajadores del conocimiento y ahora estamos en la era de los trabajadores creativos. Personas que necesitan tiempo para relajarse, charlar en la máquina de café o jugar al futbolín. Necesitan un descanso para ser innovadores y creativos. Necesitan tiempo para divertirse. Haciendo esto, aseguran una alta motivación y una máxima productividad.

happiness workers

  • Fomenta la diversión, la energía, la interacción y la colaboración ya que esto crea un atmósfera en la que el equipo pueda prosperar.
  • Los buenos Scrum Development Team consideran los eventos Scrum como una oportunidad para conversar. Tobias Mayer lo describe perfectamente en su libro «The People’s Scrum«: 

Scrum se centra en las personas y las personas tienen conversaciones. Hay conversaciones para planificar, alinear y reflexionar. Tenemos estas conversaciones en el momento apropiado y con las duraciones apropiadas. Si no tenemos estas conversaciones, no sabremos lo que estamos haciendo (planificación), tampoco sabremos a dónde vamos (alineación), y seguiremos repitiendo los mismos errores (reflexión) — Tobias Mayer

el libro de tobias mayer The people's Scrum

  • Un buen DT conoce a su Customer. Están en contacto directo con ellos. Entienden realmente lo que desean y por lo tanto son capaces de tomar las decisiones correctas (técnicas). Pueden explicar el valor de los requisitos no funcionales. Los buenos equipos de desarrollo entienden la importancia de los requisitos no funcionales como, por ejemplo, el rendimiento, la seguridad y la escalabilidad. ¿En tus equipos encuentras estos elementos en el DoD o en el PB?
  • Los excelentes equipos de desarrollo piensan en los formatos de sus retrospectivas. Formatos creativos, divertidos y útiles y se ofrecen a facilitar las sesiones ellos mismos. Más de uno se preguntaría: “Y ahora ¿Qué va a hacer el Scrum Master?” Te recomiendo que leas sobre ello en nuestro post: Un buen Scrum Master
  • Entregan funcionalidades durante el sprint si así lo requiere su entorno. Los buenos equipos de desarrollo pueden entregar funcionalidades continuamente. Son capaces de crear un flujo de entrega continuo. Rompen el mito que solo se puede entregar al final de cada Sprint.
  • Velan por sus artefactos. Un buen DT en Scrum se asegura que el tablero (si tienen alguno… :P) del equipo esté siempre actualizado. y que sea un reflejo exacto de su realidad. No necesitan un Scrum Master para hacerlo, ni que el SM lo haga por ellos.
  • Los grandes equipos de desarrollo saben dar y recibir feedback de manera honesta y respetuosa. Dan feedback  cuando es necesario, y no esperan hasta la retrospectiva.
  • Entienden el concepto de la propiedad colectiva. Un buen equipo de desarrollo entiende la importancia de la propiedad colectiva. Por lo tanto, los desarrolladores rotan a través de diferentes módulos de las aplicaciones y sistemas para fomentar la propiedad colectiva. 
  • Gestionan las dependencias con otros equipos. Son conscientes de las posibles dependencias con otros equipos y las gestionan por sí mismos.
  • No necesitan puntos de historia. Ya no se centran en los puntos de historia. Han refinado el producto para que el tamaño de los PBis no varíe mucho. Saben cuántos PBIs pueden realizar cada sprint. Contar el número de funcionalidades es suficiente para ellos.

Conclusiones

No es fácil llegar a tener estas características, a veces suenan imposibles y no es fácil llegar a ellas, pero te puedo asegurar que pude disfrutar trabajando con un equipo con características similares. Un equipo que comenzó nuevo con personas de varias experiencias (mucha experiencia desarrollando producto y muy poco experiencia también) y después de varios meses de trabajo y sobre todo sus ganas de hacer las cosas de un modo diferente se llegó a algo similar. ¡Nadie dijo que será fácil! 

¿Has visto equipos así?

Nota: esta información fue extraida de varios artículos de Barry Overeem

Entradas relacionadas

¿Qué es Sprint Review?

¿Qué es Sprint Review?

Hoy quiero hablarte de la Sprint Review en nuestro canal de youtube. Cada dia hay más equipos que se lanzan ...
Leer Más
Definition of Ready en Scrum

Definition of Ready en Scrum

¿Te suena el Definition of Ready o definición de listo? ¿Lo has usado? ¿Dónde y cuándo? ¿Sabías que el Definition ...
Leer Más

 

¿Te ha gustado el post?

¡Valóranos!

Promedio de puntuación 4.9 / 5. Total de votos: 7

Hasta ahora, ¡no hay votos!. Sé el primero en puntuar este contenido.

Si continuas utilizando este sitio aceptas el uso de cookies. más información

Los ajustes de cookies de esta web están configurados para "permitir cookies" y así ofrecerte la mejor experiencia de navegación posible. Si sigues utilizando esta web sin cambiar tus ajustes de cookies o haces clic en "Aceptar" estarás dando tu consentimiento a esto.

Cerrar