Mitosis en Scrum: Dinámica para formar equipos

En el ciclo de vida de un equipo Scrum es normal que se vayan incorporando personas al equipo con el tiempo, pero esto hay que gestionarlo de alguna forma.
Veremos una dinámica que puede ayudarnos a gestionar esto.

Si implementáis Scrum, puede que llegue un día en que la daily se alarga demasiado, pero no porque cada miembro del equipo se alargue en qué hizo, qué va a hacer y qué le tiene bloqueado, sino simplemente somos ya muchos porque se van incorporando a la plantilla más personas. Empieza a parecer necesario dividir la daily o algo así, como la daily es por equipo, parece ser buena idea dividirnos en dos equipos, pero ¿cómo lo hacemos?

Mitosis Scrum
Mitosis Scrum

Hace tiempo, no recuerdo dónde, leí una dinámica que se basa en el principio de “multidisciplinaridad”. Se supone que un equipo debe ser autosuficiente para llevar a cabo cualquier proyecto que le llegue, por lo tanto, debe ser multidisciplinar. La cosa consiste en coger a todas las personas que forman parte del equipo que se va a dividir en una habitación y se vayan a la parte izquierda o derecha de la sala atendiendo al criterio de “multidisciplinaridad” para formar dos equipos diferentes.

Por ejemplo, si yo me considero una persona buena en crear interfaces de usuario y sé que Pepito también, pues no me pondré con Pepito en su mismo equipo, me iré al otro.

Una vez que tenemos los dos equipos, tomamos una foto de ambos y volvemos a repetir el proceso varias veces. Supongo que cinco configuraciones diferentes parece ser un buen número.

De esta forma, tenemos muy rápidamente, varias configuraciones posibles de equipos multidisciplinares con las personas que lo van a formar.

Lo que queda es elegir las definitivas. ¿Cómo lo hacemos?, como hacemos en la retrospectiva, cada miembro tiene tres votos y puede elegir tres combinaciones, el más votado, es la configuración elegida y la mitosis de un equipo se ha producido.

Esta dinámica no recuerdo dónde la leí, y ni si tiene nombre, ¿tiene nombre? ¿la habéis usado? ¿Qué tal os ha ido de haberla usado? ¿Cuántas configuraciones obtenéis antes de elegir una?

Juan María Laó Ramos

Una experiencia ALM ++

En estos últimos tres meses he tenido la oportunidad de aplicar Scrum y TDD de manera estricta.

Ha sido una experiencia muy enriquecedora y la voy a compartir con todos.

En el proyecto hemos usado Team Foundation Service y Visual Studio 2012 como solución ALM con la plantilla por defecto de Scrum. Con esto solventamos varias cosas de un plumazo:

  • Gestión del Backlog
  • Definición de Sprints
  • Gestión de Tareas.
  • Gestión de Bugs.

La interacción con el cliente también la hacíamos a través de la web del proyecto.

Lo que más me llamó la atención fué lo fácil que es la gestión de bugs. Cuando el cliente encontraba un bug, lo abría y le ponía la prioridad, el scrum Master lo comunicaba en el daily scrum y nos organizábamos para ver quién lo corregía

ALM

  • Teníamos definidas varias Builds para cada parte del sistema que lanzaba una compilación y ejecución de los Test Unitarios que había para asegurar que no se había roto nada.
  • También había otra serie de Builds manuales necesarias para generar una versión para desplegar en los distintos entornos Desarrollo, Pre-producción y Producción.

La verdad que esto de no salir de Visual Studio para crear un sistema es una bendición. En su día integré Jenkis, Trac y Subversion en un proyecto en .NET, me maravillaba lo que se podia hacer con estas herramientas. La verdad es que me costó un tiempo montarlo y después mantenerlo.

Y en una conversación con el Scrum Master me soltó esto:

“Luego te llegan los empalmados que si Subversion, Jenkins, Jira, Trac, Bugcilla, que es gratis. Si estás desarrollando en .NET, el intentar integrar todo eso para que funcione con .NET es posible, pero es cuestión de tiempo y dinero”

Y en estos tres meses de trabajo, le habremos dedicado 40 horas a estos temas (daily scrums incluidos) y todo sin salir de Visual Studio.

Design a site like this with WordPress.com
Get started