Scrum vs. Shape Up: Diferencias

En el artículo anterior vimos que Scrum y Shape Up comparten ciertas similitudes. En el presente artículo veremos que también existen diferencias significativas entre ambos.

Entonces, ¿en qué se diferencian?

Sprints vs. Ciclos

En Scrum habitualmente se trabaja en sprints de 2 semanas sin pausa entre el final de un sprint y el inicio del siguiente, siguiendo un modelo de desarrollo iterativo e incremental.

En cambio el estándar de Shape Up son ciclos de desarrollo de alrededor de 6 semanas, más 2 semanas de período de Cool-down siguiendo también un modelo “iterativo e incremental” pero no consecutivo en el tiempo. Me explico, en Shape Up partimos de un documento Pitch, que es el resultado de la etapa de Shaping, y a partir de aquí el equipo (de desarrollo) comienza a secuenciar el trabajo que descubre que tiene que hacer identificando las diferentes piezas de software de las que se compone el mismo, empezando por el epicentro, averiguando así los problemas a resolver siguiendo un orden lógico de ejecución. En Shape Up prácticamente cualquier nueva funcionalidad se implementa en un único ciclo de como máximo 6 semanas, pero puede suceder que algo significativo haya quedado fuera del ciclo por falta de tiempo (el apetito que hemos establecido). En estos casos siempre podemos hacer un nuevo shaping de estas mejoras que han quedado fuera (ya sean aspectos de diseño UX/UI, casos de uso no contemplados, nuevos parámetros de configuración, etc.) y esperar a que se prioricen en un futuro ciclo. De esta forma estaríamos aplicando un desarrollo “iterativo”, por el hecho de requerir una nueva iteración en forma de un nuevo mini-proyecto en el que se repite el mismo proceso de trabajo; e “incremental” porque esta nueva iteración vendría a ser como un refinamiento de la primera. Y todo esto sucediendo en espacios de tiempo no consecutivos, a diferencia de Scrum en el que los sucesivos sprints de refinamiento suceden uno detrás del otro.

Estimaciones vs. Apetito

Otra diferencia clave es que normalmente cuando planificamos un sprint en Scrum, lo hacemos haciendo estimaciones de las historias de usuario que tenemos en el Backlog de Producto, generalmente utilizando puntos de historia. Pero ya se sabe que habitualmente las estimaciones resultan ser incorrectas. Y por supuesto es totalmente comprensible, especialmente con el trabajo técnico: lo que imaginamos que tenemos que hacer, y luego lo que realmente hay que hacer cuando nos ensuciamos las manos tocando código son dos cosas diferentes. Y luego, cuando el trabajo lleva más tiempo en completarse de lo que pensábamos, entonces se crean tensiones entre los equipos de Producto y de Ingeniería, porque el proyecto se sigue arrastrando en sucesivos sprints.

El enfoque de Shape Up es completamente distinto, y aquí hablamos de apetito en lugar de estimación. Ya no se le pide al equipo encargado del desarrollo que diga cuál cree que es el esfuerzo necesario para completar un determinado trabajo, sino que en realidad es el responsable del producto (con el beneplácito de los responsables del negocio) quien decide la cantidad de tiempo y dinero que la empresa está dispuesta a invertir en este trabajo. Es decir, están dando al equipo un presupuesto de tiempo (con una configuración de equipo determinada) para completar un trabajo, y este es un razonamiento completamente distinto. De hecho es un enfoque estratégico sobre el valor de lo que se pretende hacer, la urgencia que hay en estos momentos, así como las otras cosas que están sucediendo en el negocio que se van a tener que hacer a continuación. Y todo esto es posible porque hay diferentes grados en los que podemos hacer las cosas. Por ejemplo, si decimos que queremos construir un bote, podríamos construir un bote de remos, o bien una lancha, o bien un yate; y por supuesto, los diseñadores, programadores y personas que hacen las cosas siempre querrán hacer yates para dar lo mejor de sí mismos. En cambio Producto-Negocio puede que tengan una idea completamente diferente.

Refinamiento del Backlog vs. Shaping

El refinamiento del Backlog en Scrum a menudo queda relegado a una actividad de tiempo parcial, reservando entre un 5-10% de la capacidad del equipo Scrum (total o parcial) durante el sprint en curso para preparar las historias del siguiente sprint (o siguientes dos sprints).

En cambio, el Shaping en Shape Up es prácticamente un trabajo a tiempo completo por parte de un perfil sénior de Producto (tipo Product Manager) durante las ˜6 semanas de duración del ciclo, que una vez hecha la apuesta (en la etapa de Betting), el Pitch resultante es traspasado al equipo de desarrollo para que lo ejecute. Durante el tiempo que dura el Shaping se involucra puntualmente a expertos técnicos (analistas, arquitectos, programadores, diseñadores UX/UI, QA testers, etc.) para que evalúen la viabilidad técnica de lo que se está definiendo (ejecutando spikes si es necesario). Su involucración temprana también ayuda a que el equipo de desarrollo se haga el proyecto más suyo (mejor aceptación) en el momento de ponerse manos a la obra (en la etapa de Building).

Otra diferencia es que el refinamiento en Scrum se hace a nivel de historia de usuario y tiene afectación al Backlog de Producto (añadiendo detalle técnico y estimaciones en las historias, repriorizando el Backlog, etc.); en cambio en Shape Up el shaping se hace a nivel de documento Pitch sin ninguna afectación al Backlog porque en Shape Up no existe el concepto de Backlog tal y como lo conocemos.

Épicas e Historias de Usuario vs. Documentos Pitch

Otra diferencia que encontramos es que en Scrum se trabaja con “flujos de tickets”, donde básicamente tienes un montón de tickets (entendidos como ítems que conforman el Backlog de Producto) en una herramienta de ticketing tipo JIRA, Github, Trello o similar, y siempre hay alguno que comienza con un: como <tipo de usuario>, quiero <funcionalidad>, para <conseguir un beneficio>. Y esto per se no está mal, el problema es que a menudo cada ticket proviene de partes distintas de la aplicación/sistema, y eso hace que el equipo tenga que estar cambiando constantemente de contexto. Imaginémonos que hay un desarrollador que, por ejemplo, está trabajando en cuatro o cinco tickets durante el sprint y cada ticket es de una parte completamente diferente de la aplicación. Entonces continuamente está forzado a aprender diferentes partes de la aplicación, y eso requiere de un esfuerzo en tiempo y energía considerable. A veces esto ocurre porque no se ha definido un objetivo suficientemente claro del sprint.

Y de nuevo, si lo comparamos con Shape Up, el enfoque es completamente distinto. La persona responsable del producto es la que prepara una propuesta de mini-proyecto (o Pitch), que define, en el nivel adecuado de abstracción, lo que se debe conseguir durante las próximas ˜6 semanas (o 2 semanas si es un proyecto más pequeño). Una vez preparada la propuesta y a punto para iniciar la ejecución, entonces es cuando se le da al equipo de desarrollo autonomía sobre el mini-proyecto en la fase de Building, y el equipo se auto-organiza como mejor le convenga para implementar lo descrito en el Pitch.

Prioridades vs. Binarios

En Scrum y en otros marcos de trabajo ágiles estamos acostumbrados a utilizar técnicas de priorización como las descritas en la parte izquierda de la ilustración para priorizar Backlogs o extensas listas de cosas que queremos hacer. La gente parece amarlas, pero en el desarrollo de productos digitales, a la hora de elegir qué hacer a continuación, la respuesta siempre acaba siendo binaria: “sí” o “no”, “ahora” o “no ahora”, un “tal vez” es un “no” (por ahora). Ser binarios sobre lo que elegimos hacer nos aporta claridad a lo que debemos hacer.

En Shape Up se es binario en la toma de decisiones que tiene lugar en la mesa de apuestas de la etapa de Betting (eligiendo las pocas opciones en formato Pitch que van al siguiente ciclo), en contraposición a la elección de los diferentes tickets que conforman el Backlog del sprint en Scrum.

Tamaño y composición del equipo

Hablando de equipos, el tamaño estándar de un equipo Scrum es de como mucho 10 personas, con al menos un Product Owner, un Scrum Master y varios Desarrolladores que conforman el Equipo Scrum, según la Scrum Guide 2020.

En Shape Up los equipos core de desarrollo de producto están formados por 2 o 3 personas como mucho (habitualmente un diseñador y uno o dos programadores). Los QA testers y otros perfiles técnicos transversales se involucran puntualmente cuando son requeridos. Con equipos de como máximo 3 personas en el equipo core de desarrollo se simplifica muchísimo la comunicación y la interacción social entre los diferentes miembros del equipo. Un equipo de 3 personas significa que solo puede haber como máximo 3 canales de comunicación abiertos a la vez (véase parte derecha de la ilustración). Solo añadiendo a una persona más al equipo, esto hace que crezca la complejidad de forma exponencial (4 personas significa 6 posibles canales de comunicación abiertos a la vez). Con dos personas hay una comunicación directa, es decir, pueden hablar entre ellos. Con tres personas ya no hablan sino que mantienen una conversación. Y con cuatro o más personas lo único que pueden hacer es una reunión. Simplemente se vuelve más difícil mantener a todos informados. Cuanta más gente involucrada, todo va más lento.

Además equipos grandes significa discusiones más largas, más difícil llegar a un consenso, más difícil compartir conocimiento importante entre los miembros, y la química que se genera tampoco es la misma que la que hay en grupos más pequeños. Incluso se pueden llegar a crear silos dentro del propio equipo (programadores por un lado, diseñadores por otro, los QA testers por otra, etc.).

Otra diferencia respecto a los equipos es que en Shape Up habitualmente las personas son seleccionadas (en la mesa de apuestas) para trabajar en un proyecto específico, es decir, los equipos se configuran de nuevo cada vez. En cambio en Scrum el trabajo le llega al equipo y habitualmente la composición de este no cambia en función de las necesidades del proyecto.

Velocidad del equipo

En Scrum existe una fórmula (véase parte izquierda de la ilustración) que sirve como indicador del desempeño del equipo en un momento dado. Luego esta fórmula de velocidad del equipo se utiliza para realizar predicciones del tiempo necesario (o número de sprints necesarios) para completar una determinada funcionalidad que todavía está en el Backlog.

En cambio en Shape Up se habla de crear entornos libres de distracciones para conseguir una alta productividad de los equipos. Cada pequeño despiste puede costar unos 20 minutos de tiempo de un desarrollador antes de que pueda volver a un estado productivo. Si tuviéramos que resumir el enfoque sobre la productividad en Shape Up en una fórmula imaginaria, se parecería a la de la parte derecha de la ilustración: Para conseguir una alta productividad es necesario limitar el número de reuniones, evitar conversaciones innecesarias y no perder el tiempo en tareas burocráticas que no aportan valor al equipo ni al producto, tales como el uso de herramientas de ticketing (tipo JIRA), informes innecesarios o controles horarios. Si conseguimos proteger el equipo de las distracciones, con esto ya tenemos la mitad de la batalla ganada. La segunda parte de la fórmula consiste en asegurar que el equipo no pierde el tiempo ni energía en cosas sin importancia. Por lo tanto, el equipo no debería complicarse en exceso en la implementación de las features (buscando siempre la sencillez), no debería hacer ingeniería excesiva del código, ni trabajar en tareas nice-to-have.

Entonces, ¿es posible trabajar en un entorno sin Backlogs, sin que los managers troceen el trabajo que hay que hacer y los programadores actúen como simples recogedores de tickets (ticket-takers), sin post-its en las paredes, sin estimaciones con puntos de historia, sin necesidad de participar en rituales como Stand-ups diarios y otras ceremonias donde se da mucho estatus de las cosas que se hacen, sin necesidad de hacer constantemente seguimiento de la velocidad del equipo, sin el rol o figura de un Scrum Master, y finalmente sin un Project Manager que se encargue de mantener el equilibrio entre el alcance, costo y tiempo (triángulo de hierro) del proyecto?

La respuesta es Sí, y se llama Shape Up.

---

Hasta aquí las diferencias entre Scrum y Shape Up. En un próximo artículo veremos el camino a seguir para pasar de Scrum a Shape Up sin morir en el intento.

Muchas gracias por leer el artículo, compartirlo si te ha gustado y poner tus comentarios más abajo. Si algo de lo que has leído ha resonado en ti y te apetece darle una oportunidad a Shape Up, ponte en contacto conmigo.

Sobre el autor

Soy un apasionado de las nuevas formas de trabajar y organizar los equipos de Producto e Ingeniería para conseguir que sean equipos de alto rendimiento, altamente motivados, garantizando previsibilidad y calidad de las entregas. Estoy muy alineado con el método Shape Up, un nuevo enfoque de desarrollo de productos digitales que va más allá de Agile, Lean, Kanban y Scrum.