¿Qué decisiones se deben tomar antes de arrancar con Scrum?

Es curioso como para Scrum no hay nada antes del primer Sprint. Para la cultura que propone Scrum, todo tiempo que inviertas para poder empezar a inspeccionar y adaptar es tiempo “perdido” o desperdicio ya que lo que más valor aporta es entregar lo antes posible. Sin embargo, un Scrum Team debe tomar muchas decisiones sobre cómo quieren trabajar. ¿Cuánto va a durar el Sprint? ¿Con qué DoD inicial arrancamos? ¿Scrum Board o Jira?

Lo curioso es que, en todas las organizaciones que he estado, siempre me han impuesto estas decisiones. ¿Cómo fomentamos la autoorganización si las decisiones más vitales del trabajo las decide la organización? Actualmente estoy trabajando con una compañía nueva en Scrum, y hemos decidido que cada equipo tomará sus propias decisiones. ¡Estudiemos cómo sería un Kickoff Scrum!

¿Necesitamos entrenamiento?

Scrum se está implantando en las organizaciones. En algunas aún no saben trabajar así y debemos preguntarnos si el equipo necesita algún tipo de training ya sea en Scrum como en otro tipo de técnicas como pueden ser TDD o Historias de Usuario. Detectar estas carencias lo antes posible nos ayudará a arrancar y dar el mejor servicio posible.

¿Quién ocupará los roles?

Esta decisión se suele escapar del propio equipo, es cierto que muchas veces es la propia organización quien prescribe las personas. Lo idílico es que el Product Owner sea nombrado por la organización (ya que es a quién rinde cuentas) y que este componga el resto del equipo.

Esto suena fantasioso, aún así, he visto a Development Team decidir su propio Scrum Master o Development Team autocomponerse e incluso en equipos grandes decidir cómo distribuirse en equipos. ¡Cada decisión que dejemos tomar aumentará el grado de responsabilidad!

Es importante, en el caso del Development Team, que se hagan la pregunta ¿Somos multifuncionales? Es decir, ¿Tenemos todas las habilidades en el equipo necesarias para entregar? Si la respuesta es no, es hora de tener una conversación con la organización para incorporar personas con dichas habilidades o bien, hacer un plan para adquirirlas.

¿Cómo vamos  a utilizar los artefactos?

Lo siguiente es estudiar los artefactos de nuestros equipos. En el caso del Product Backlog ¿Vamos a usar Jira o similar o va a ser físico? Lo mismo para el Sprint Backlog ¿Dónde lo vamos a ubicar? tener un debate sobre esto es vital. Los equipos más maduros suelen tender a tableros físicos pero no es obligatorio en Scrum.

Apostemos por físico o digital, necesitaremos definir la forma de nuestro tablero ¿Usaremos el clásico todo-doing-done o queremos otra forma? Hay muchas maneras de trabajar con tableros visuales y deberemos estudiar el que nos interesa. ¡Y adaptarlo con el tiempo!

¿Dónde nos sentaremos?

Esto no es baladí, ¿Nos sentaremos juntos o separados? Si nuestro Product Owner es de otra organización ¿Nos vamos a sus oficinas? Este tipo de debates es interesantes tenerlos y pensar siempre en la maximización de valor que vamos a ser capaces de entregar a nuestros customer.

¿Para qué estamos aquí?

Tener una visión clara del producto. Esta labora la puede trabajar el Product Owner previamente o trabajarlo con el resto del Scrum Team. Hay muchas técnicas, alguna de las más famosas son el Elevator Pitch o la Caja de Cereales. Se trata de tener claro el motivo para el que vamos a trabajar juntos los próximos Sprints. Sin eso, nos costará tomar decisiones.

¿Tamaño del Sprint?

Esta decisión debe ser tomada por el propio Scrum Team. Recordemos que Scrum solo pone una regla: que no dure más de 30 días y que no lo modifiquemos constantemente. Deberíamos de tender a la duración más corta posible pero que permita entregar cosas terminadas. Si para entregar (llegar a producción) hacen falta más de 30 días entonces hay que hablar de cómo podemos reducir eso.

Otro asunto a tratar es ¿Días laborables o naturales? Hay equipos que prefieren Sprints con días laborables para ser más exactos mientras que otros prefieren naturales para ganar en constancia. ¿Qué día de la semana empezamos? El patrón habitual es lunes-viernes pero está demostrado que los viernes no es buen día acabar porque estamos pensando más en el fin de semana. Hacernos estas preguntas nos ayudarán a tener el mejor entorno posible de trabajo.

¿Cómo serán los eventos?

Nos puede interesar hacer Sprint Review, Retrospective y la siguiente Planning el mismo día, o puede que nos interese separarlo. Hay que hablar de estas rutinas. ¿Qué personas van a ir a la Sprint Review? Por ejemplo, en un equipo en el que acompaño los Stakeholders están a 300 kilómetros, lo que provoca que seguramente sea una Sprint Review a distancia y necesitemos de una sala para conectarnos ¡Hay que planificarlo!.

Una buena idea que me dió una compañera era hacer un calendario con todos los eventos y que el Product Owner (que suele estar muy ocupado) tenga planificado los días que hay un evento Scrum. Esto es importante en organizaciones nuevas en Scrum porque no tenemos la costumbre de darle importancia a los eventos.

Definition of Done

Puede que nuestra organización disponga de ciertas reglas de calidad, debemos conocerlo para intregrarlo en nuestra primera Definition of Done. Podemos definir una primera versión ¿Haremos pruebas de integración? ¿Pruebas cruzadas? ¿Cómo usaremos GIT?

¿Tenemos un Product Backlog?

Aquí entramos en el mundo tenebroso del “sprint 0” que no siendo Scrum, está ahí y muchas veces es necesario. Aquí podemos leer más sobre ello. Realmente no lo necesitamos, pero desde luego, nos va a tocar construirlo en el primer Sprint Planning. Mi consejo es que, si no lo tenemos, no retrasemos el inicio del equipo meses por esto.

¿Qué espero de mis compañeros?

Un gran consejo que me gustaría aportar es hacer esta dinámica. Consiste en entender las expectativas de unos compañeros con otros. En Scrum no hay roles ni etiquetas pero si especialistas y eso significa que debemos organizarnos. El objetivo no es mantener a todo el mundo ocupado, sino ser capaces de maximizar valor.

¿Esto es todo?

Posiblemente haya muchas cosas más, dudas con el funcional o disponer de entornos. Cada equipo es un mundo y cada equipo debe pensar qué necesita para Sprintar de la mejor manera posible.

Muchas de estas decisiones no dependerán solo del Scrum Team, pero desde luego, definirle a las personas todo no ayudará  a su autoorganización. Si no tienes respuesta a todas las preguntas no pares el trabajo, empieza cuanto antes e inspecciona y adapta, con el tiempo obtendrás las respuesta.

Y tú, ¿Cómo arrancas un Scrum Team?