Introducción al método Shape Up: Fase de "Building"

En el artículo anterior vimos que la fase de Betting consistía en decidir qué queremos hacer en el siguiente ciclo de desarrollo a partir de unas cuantas opciones a considerar en forma de apuestas potencialmente buenas. En el presente artículo nos adentraremos en la fase de Building, en la que el equipo de desarrollo construirá la solución descrita en el documento Pitch en el siguiente ciclo de 6 semanas.

Asignación de proyectos, no de tareas

Una vez tomada la decisión de qué proyectos entran en el siguiente ciclo de 6 semanas de desarrollo, entonces se tiene que hacer el traspaso del proyecto entero descrito en el documento Pitch al equipo de desarrollo asignado. Nadie asigna tareas al equipo. Ya que descomponer el proyecto en tareas al inicio del desarrollo sería como pasar el Pitch por una trituradora de papel. Todo el mundo recibiría únicamente piezas desconectadas, donde cada uno ejecutaría su parte sin sentirse responsable de juzgar como encajaran (se integraran) todas las demás antes de la entrega final. La idea es que el proyecto se mantenga "entero" durante toda la fase de desarrollo para que nunca se pierda de vista la visión general. Se confía en el equipo para que asuma todo el proyecto y trabaje dentro de los límites que se han definido en el Pitch. De este modo, el equipo definirá sus propias tareas y su forma de afrontar el proyecto. Tendrán plena autonomía y utilizarán su criterio para implementar el Pitch de la mejor forma posible con decisiones reales de diseño y de implementación.

Aquí es donde los esfuerzos por definir el proyecto al nivel de abstracción adecuado, sin demasiados detalles, darán sus frutos. Con el talento del equipo y su conocimiento de los detalles, se obtendrá un producto acabado mejor de lo que se podría llegar a tener intentando definirlo con el máximo detalle con antelación.

Done significa desplegado

Al final del ciclo, se espera que el equipo despliegue su trabajo en un entorno productivo (idealmente) o como mínimo pre-productivo. En el caso de un equipo que trabaje con un conjunto de mini-proyectos small batch (con un apetito de como máximo 2 semanas), entonces desplegará cada uno de esos mini-proyectos como crea conveniente, siempre que suceda antes del final del ciclo.

Esta limitación nos mantiene fieles a nuestras apuestas y respeta la técnica del circuit breaker. El proyecto debe finalizar dentro del tiempo que hemos presupuestado; de lo contrario, nuestro apetito y presupuesto no significan nada.

Acerca de la técnica del circuit breaker: El tiempo ininterrumpido de 6 semanas se combina con una política dura pero extremadamente poderosa. Los equipos tienen que entregar el proyecto dentro del tiempo que hemos apostado (cumpliendo el apetito). Si no terminan a tiempo, por defecto el proyecto no obtiene una prórroga. De forma intencionada se crea un riesgo de que el proyecto, tal y como se definió en el Pitch, no se llevará a cabo. Esto puede parecer demasiado estricto, pero es extremadamente útil para todos los involucrados.

Esto también implica que cualquier prueba y control de calidad deben realizarse dentro del propio ciclo de Building. El equipo se acomodará a esto detallando los aspectos más esenciales del proyecto, finalizándolos antes y coordinándose con el equipo de aseguramiento de la calidad para que se puedan planificar con tiempo.

Para la mayoría de proyectos la actualización de manuales/documentación de usuario, campañas y comunicaciones de Marketing, o los anuncios de las novedades a los clientes (en los app stores por ejemplo), no suelen ocurrir dentro del ciclo de 6 semanas. Estos temas considerados de bajo riesgo, normalmente son gestionados por otros equipos en el período de Cool-down (más detalle en el próximo artículo).

Kick-off del proyecto y orientación del equipo

Empezamos el proyecto realizando una sesión de kick-off entre el shaper (la persona que ha redactado el documento Pitch) y el equipo de desarrollo (formado por un diseñador y uno o dos programadores). Esta sesión da al equipo de desarrollo la oportunidad para realizar cualquier pregunta importante que no quede clara en la redacción del Pitch. Entonces, con una comprensión aproximada del proyecto, están preparados para empezar.

El trabajo de los primeros días no parece "trabajo". Nadie está completando tareas. Nada se está desplegando en los entornos de pruebas. No hay ninguna entrega para revisar. A menudo ni siquiera hay demasiada comunicación entre el equipo durante los primeros días. Suele haber un extraño "silencio de radio". ¿Por qué? Porque cada persona está concentrada intentando averiguar cómo funciona el sistema existente y cuál es el mejor punto de partida. Todo el mundo está ocupado aprendiendo qué hay que hacer y orientándose.

Es importante que los stakeholders, shareholders, managers, etc. respeten este momento. Los equipos no pueden sumergirse en una base de código y empezar a crear nueva funcionalidad de inmediato. Tienen que familiarizarse con el código, analizar bien el Pitch, resolver algunas dudas y encontrarse en algún callejón sin salida hasta encontrar el punto de partida. Interferirles o pedirles el estado de progreso demasiado pronto lo único que hace es perjudicar al proyecto. El equipo necesita tiempo para encontrar el mejor enfoque. La exploración debe pasar de todos modos. Es mejor empoderar al equipo para que diga explícitamente "aún estamos averiguando cómo empezar" para que no tengan que esconder ni disimular este trabajo legítimo.

En términos generales, si el silencio no comienza a romperse después de 3 días, es un momento razonable para intervenir y ver qué ocurre.

Tareas imaginadas vs. descubiertas

Dado que al equipo se le ha asignado un proyecto entero y no tareas, deben plantearse ellos mismos las tareas. Aquí es donde observamos una diferencia importante entre las tareas que creemos que debemos realizar al inicio de un proyecto (tareas imaginadas) y las que descubrimos que debemos hacer a medida que nos adentramos en el trabajo real (tareas descubiertas).

Evidentemente el equipo comienza con algunas tareas imaginadas, las que se supone que tendrán que hacer sólo pensando en el problema. Entonces, a medida que se ensucian las manos descubren todo tipo de cosas que no podían imaginarse al principio. Estos detalles inesperados constituyen el verdadero grueso del proyecto y a veces presentan los retos más difíciles.

A medida que el equipo se orienta, empieza a descubrir y a hacer un seguimiento de las tareas que deben realizar para construir el proyecto. Haciendo el trabajo real es cuando realmente averiguan qué hay que hacer. Si el equipo completa muchas tareas pero no hay "algo" para hacer clic y probar, es difícil tener la sensación de progreso. Un equipo puede estar haciendo mucho trabajo pero se siente inseguro porque todavía no tiene nada real que enseñar, ya que realmente nada está terminado. El equipo no debe de empezar a construir cualquier cosa. Primero debe de elegir algo significativo, algo que sea central para el proyecto y lo suficientemente pequeño para poder hacerse de inicio a fin, con interfaz de usuario y código funcionando, en relativamente pocos días. Es decir, deben tener como objetivo hacer algo tangible y demostrable más o menos durante la primera semana de desarrollo. Eso requiere integrar verticalmente una pequeña pieza del proyecto.

Integración de un corte vertical

Podríamos decir que los proyectos tienen 2 capas: frontend y backend, es decir, diseño y código de lógica de negocio. Aunque técnicamente hablando existen más capas que estas, seguramente estas dos son el principal reto de integración en la mayoría de proyectos.

Supongamos que el proyecto comienza con mucho diseño. El diseñador podría diseñar una gran variedad de pantallas e incluso implementarlas como plantillas o vistas. Pero hasta que éstas no se conectan a un backend, nada funciona. El trabajo sigue siendo hipotético y especulativo.

Lo mismo ocurre con el backend. Se pueden finalizar muchas tareas de backend, pero sin ninguna interfaz de usuario, ¿qué haces?, ¿cómo juzgas si la programación hecha en una pieza específica de la lógica de negocio es realmente correcta sin ningún tipo de interacción?

En cambio, lo que queremos es integrar una parte front y una parte back del proyecto, junto con el end-point. Entonces, cuando esto ocurra, el equipo tendrá algo tangible que demuestre que funciona (o no funciona y reconsiderar). Cualquiera interesado podrá hacer clic y ver si la funcionalidad hace lo que debería hacer.

Organización por estructura, no por persona o rol

En general, estamos acostumbrados a organizar las tareas del equipo por persona o rol, creando listas de tareas para los diseñadores, listas de tareas para los programadores, tareas para el equipo de QA, etc. Esto provoca el problema que comentábamos al inicio del artículo, el equipo completará tareas, pero nadie se sentirá responsable de integrarlas antes de que finalice el ciclo.

En el desarrollo de software la estructura natural (la anatomía) de cada proyecto no se puede definir previamente. Normalmente construimos cosas que nunca hemos construido antes. Cada proyecto es un territorio salvaje que debemos recorrer antes de poder dibujar un mapa de todas las partes. Profundizando en el trabajo es cuando descubrimos dónde están las interdependencias, cómo se conectan las diferente partes y cómo podemos separarlas.

Como hemos visto anteriormente, los cortes verticales integran tareas de frontend y backend, que nos permiten terminar una parte real del proyecto y seguir adelante. Esto es mejor que tener muchas piezas separadas que, cruzando los dedos, se supone que se integrarán al final del ciclo.

Estas secciones verticales del proyecto llevan el nombre de scopes (“alcances” en castellano), de tal forma que se desglosa el alcance (scope) global del proyecto en alcances separados que se pueden finalizar independientemente los unos de los otros.

Lenguaje del proyecto

Los scopes son mucho más que simples cortes verticales, se convierten en el lenguaje del proyecto a nivel macro. Cuando llega el momento de informar sobre el estado del proyecto, el equipo utiliza el lenguaje de los scopes para explicar qué está finalizado y qué no. Es más satisfactorio tener la conversación a un alto nivel y hacer referencia a piezas del software finalizadas que bajar a nivel de tarea y defender los propósitos y el estado de las tareas pendientes de forma individual.

En el ejemplo de arriba vemos que la estructura del proyecto está formada por 5 scopes, y uno de ellos está finalizado. El trabajo del equipo consiste en ir identificando sobre la marcha todos y cada uno de los scopes del proyecto. Y las tareas que se van descubriendo se van añadiendo debajo de cada uno de los scopes (en el ejemplo se utiliza Basecamp, pero sirve cualquier herramienta de gestión de tareas).

Mostrando el avance del proyecto

Podríamos decir que el trabajo es como una colina. Cada trozo de nuestro proyecto pasa por 2 fases. Primero está la fase ascendente de averiguar cuál es el enfoque que le queremos dar y cómo lo haremos. Es el terreno de la incertidumbre y de la resolución de problemas. Entonces, una vez podemos ver todo el trabajo implicado, llega la fase descendente de ejecución, que es el terreno de la certidumbre y la confianza.

En la parte inferior izquierda es donde comienza todo proyecto. A medida que vamos sabiendo cómo resolver el problema, cómo lo vamos a implementar, cómo vamos a diseñar las pantallas, cómo vamos a encajar todas las piezas, etc., entonces vamos subiendo la colina hasta el momento en que ya no hay nada que no conozcamos, hemos resuelto todas las incógnitas y sólo queda la ejecución. Es cuando decimos que bajamos la colina.

En el libro este concepto lo llaman Hill Chart, una herramienta integrada dentro de Basecamp que permite mostrar el estado del proyecto sin necesidad de preguntar (interrumpir) al equipo. Existen versiones de Hill Chart independientes de Basecamp o conceptos de Hill Chart implementados en paneles con columnas de estado (más info aquí).

Con el Hill Chart se evitan las sesiones de #dailyscrum y cualquier otra reunión específica de status de proyecto.

En el ejemplo de arriba vemos 3 scopes con los que estamos trabajando: Hay varias incógnitas en el scopes "Future-applying edits”, y los otros 2 scopes están bajando la colina, no tienen incógnitas y sólo quedan horas de ejecución.

Pensad lo difícil que puede llegar a ser hacer el reporting del estado de proyecto a nivel de tareas. Si por ejemplo tenemos un proyecto con 100 tareas, hemos completado 20 y hay 80 de pendientes, pero 10 de ellas son las más difíciles, entonces no es preciso decir que llevamos un 20% del proyecto si todavía quedan las tareas más difíciles. En cambio con los Hill Chart solventamos esta problemática.

Decidir cuando parar

Partiendo de la premisa de que siempre habrá más trabajo que hacer que tiempo disponible para hacerlo, entregar a tiempo significa entregar algo imperfecto.

Las personas talentosas siempre querrán dar lo mejor de sí mismos. El orgullo por el trabajo bien hecho es importante para entregar con buena calidad y para la moral del equipo, pero debemos saber dirigirlo hacía el objetivo adecuado. Si apuntamos a un diseño perfecto, ideal, nunca lo conseguiremos. De la misma forma, no queremos rebajar nuestros estándares de calidad. Entonces ¿cómo lo hacemos para decir que lo que tenemos es suficientemente bueno y seguir adelante?

Para dar respuesta a esta pregunta es necesario cambiar el punto de comparación. En lugar de comparar con lo ideal (perfecto, que nunca llegaremos), tenemos que comparar con la línea de base: la realidad actual de los clientes.

Podemos decir "vale, esto no es perfecto, pero funciona y los clientes sentirán que esto es una gran mejora para ellos". El alcance variable no consiste en sacrificar la calidad. Hay que ser extremadamente exigentes con la calidad del código, el diseño visual, los textos de las interfaces de usuario y el rendimiento de las interacciones. La cuestión es preguntarnos qué cosas importan realmente, cuáles son las que marcan la diferencia.

Cuando decidir ampliar un proyecto

En casos muy extraordinarios se considera alargar un par de semanas un proyecto que supere su fecha límite. ¿Cómo decidimos cuándo extender un proyecto y cuándo dejar que el circuit breaker haga su trabajo?

En primer lugar, las tareas pendientes deben ser auténticos must-have, que se resistan a cualquier intento de aplicarle scope hammering (martilleo del alcance).

Acerca del scope hammering: En ocasiones donde las aspiraciones iniciales para una determinada funcionalidad no cumplen con los límites presupuestarios del ciclo, entonces la herramienta de referencia para llegar a la fecha de entrega es el martilleo de alcance. Básicamente, esto significa reducir el alcance eliminando características, aspectos de configuración o de fidelidad, hasta que el trabajo sea factible dentro del tiempo restante. Es la táctica opuesta a trabajar más horas al día o fines de semana o posponer el proyecto al siguiente ciclo.

En segundo lugar, el trabajo pendiente debe ser todo de bajada en el Hill Chart, sin incógnitas por resolver y sin preguntas abiertas. Cualquier trabajo de subida al final del ciclo es una sospecha de un descuido en la fase de Shaping, probablemente por un agujero (rabbit hole) en el concepto. El trabajo que aún tiene incógnitas por resolver es demasiado arriesgado para apostar por él. Si el trabajo es cuesta arriba, es mejor hacer otra cosa en el siguiente ciclo y poner el proyecto problemático en una nueva ronda de Shaping. Si se encuentra una forma viable de reparar el agujero, entonces se puede considerar apostar de nuevo más adelante.

Incluso si se cumplen las condiciones para considerar la posibilidad de ampliar el proyecto, todavía es preferible ser disciplinado y hacer cumplir el apetito para la mayoría de proyectos. El período de enfriamiento (Cool-down) de 2 semanas suele proporcionar al equipo suficiente tiempo para finalizar el desarrollo antes de que comience el siguiente ciclo. Pero esto no debería convertirse en un hábito. Acabar de picar código en el período de Cool-down indica que o bien hay un problema en el proceso de Shaping o bien hay un problema de rendimiento con el equipo de desarrollo que habría que analizar.

---

Hasta aquí la introducción a la fase de Building, que corresponde a los capítulos del 10 al 14 del libro Shape Up. En el próximo artículo veremos en qué consiste el período de 2 semanas de Cool-down (o enfriamiento) entre ciclos de forma intencionada, que gracias a esto conduce a organizaciones más saludables, que entregan mejores productos a tiempo.

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.