Introducción al método "Shape Up"​ de desarrollo de producto
© 37signals LLC. Used with permission. 37signals.com

Introducción al método "Shape Up" de desarrollo de producto

Índice de artículos relacionados

  1. Introducción al método "Shape Up" de desarrollo de producto (artículo actual)
  2. Introducción al método Shape Up: Fase de "Shaping"
  3. Introducción al método Shape Up: Fase de "Betting"
  4. Introducción al método Shape Up: Fase de "Building"
  5. Introducción al método Shape Up: Período de "Cool-down"
  6. Scrum vs. Shape Up: Similitudes
  7. Scrum vs. Shape Up: Diferencias

Contexto y motivación

Después de la buena acogida de mis últimas charlas sobre el método Shape Up (podéis ver la última versión de las slides aquí), quiero hacer mi aportación a la comunidad de hispanohablantes creando una serie de artículos sobre este método-proceso de desarrollo de producto ideado por la compañía 37signals (antes Basecamp), liderada por Jason Fried y David Heinemeier Hansson.

En el libro Shape Up: Stop Running in Circles and Ship Work that Matters, publicado el verano de 2019, que se puede leer online de forma totalmente gratuita, su autor Ryan Singer, que trabajó en el equipo core del producto de Basecamp durante prácticamente 18 años, nos explica el marco de trabajo que utiliza esta compañía para su propio desarrollo de productos. Éste método-proceso tiene como objetivo definir y priorizar mejor los proyectos de desarrollo de software antes de pasárselos a los equipos para que los ejecuten, abordar las incógnitas del proyecto desde muy al inicio, así como aumentar la colaboración y el compromiso dentro del equipo.

Hay que decir que ellos no se posicionan en una corriente o framework determinado. Desde el principio dejan claro que no hacen #waterfall o #agile o #scrum, su enfoque es completamente distinto. Lo que presentan en el libro son más de 15 años de prueba y error constante de su forma de trabajar, iterándola, perfeccionándola y puliéndola. Han moldeado su propio método y lo presentan abiertamente en este libro.

Tengo que confesar que después de leer el libro por primera vez tuve un “momento eureka”, me di cuenta de que había una alternativa clara al framework Scrum, que evitaba los cuellos de botella comunes de Kanban, Scrum y otros marcos ágiles populares. A partir de aquel momento, y sin tener vinculación alguna con 37signals, me he convertido en un claro entusiasta y divulgador de este método y de su forma particular de hacer negocios.

En resumen, con el método Shape Up se consigue una alta productividad (a partir de la creación de entornos de trabajo libres de distracciones), con equipos altamente motivados (que se les da máxima autonomía y responsabilidad sobre la ejecución), que entregan software de calidad cumpliendo con las fechas de entrega comprometidas.

La serie de artículos que iré publicando sobre la "Introducción al método Shape Up" consistirán en un mezcla de resúmenes y claves principales del libro, aportaciones de la comunidad en el foro de Shape Up, ideas de artículos de otros autores, así como aportaciones personales basadas en mi propia experiencia profesional. Para este primer artículo en particular, he incorporado algunas frases de este post del blog "Esto no es Scrum" de Raúl Alonso.

Ciclo de vida de Shape Up

En este primer artículo voy a hacer un introducción general del método Shape Up y su ciclo de vida. Así es cómo funciona:

Shape Up life cycle
© 37signals LLC. Used with permission. 37signals.com

Existen 3 fases: Shaping, Betting y Building, que transcurren en 2 carriles en paralelo, siguiendo un proceso dual-track de Discovery & Delivery.

Se le da mucha importancia a la llamada etapa de definición (Shape), que involucra a expertos de negocio, analistas y arquitectos de software, y que discurre en paralelo con la fase de desarrollo (Build). Es en la fase de Shaping cuando se perfilan las funcionalidades futuras como mini proyectos independientes, poniendo el foco tanto en acotar las necesidades reales a cubrir como en la identificación de riesgos (incógnitas técnicas, problemas de diseño no resueltos o interdependencias mal entendidas). A destacar que esta fase se realiza de manera asíncrona, lo que supone una gran optimización en tiempo y coordinación para las ocupadas personas de negocio, exigiendo entre ellas, eso sí, un compromiso y una comunicación fluida y certera.

Una vez dado forma al proyecto, con la incertidumbre reducida a la máxima expresión, aquí viene la principal diferencia respecto al #agilismo: no es el equipo encargado del desarrollo quien estimará o quien irá entregando incrementos de producto de manera iterativa e incremental, sino que es alguien cercano a negocio quien va a predefinir qué cantidad de tiempo (Appetite) está dispuesto a invertir (Bet) en la necesidad o funcionalidad concreta (6 o 2 semanas, por lo general), dejando bien clara su improrrogabilidad, aunque no siempre.

Finalmente, después del ciclo Shape-Build llega el período de Cool-down (o de enfriamiento) de 2 semanas, en el que el equipo de desarrollo puede aprovechar para trabajar libremente en lo que “quiera” (más detalles en un próximo artículo). Después de trabajar arduamente durante 6 semanas consecutivas, ahora disfrutan de tener el tiempo bajo su control, ayudándoles a recuperar fuerzas y a ser productivos una y otra vez. También es en este período de enfriamiento donde las personas con poder de decisión en la empresa deciden qué hacer en el siguiente ciclo de desarrollo.

---

Hasta aquí la visión general del método Shape Up. En los siguientes 4 artículos iré detallando cada una de las fases, empezando por el artículo de la fase de Shaping. Para acabar de entender mejor este método, más adelante también voy a dedicar una serie de artículos a ver las similitudes y diferencias más significativas entre Scrum y Shape Up.

Antes de acabar os dejo con algunos conceptos clave de este método.

Conceptos clave

  • Ciclos de desarrollo de 6 semanas. Brinda un marco de tiempo razonable para construir algo significativo de inicio a fin, y lo suficientemente corto para que todos puedan sentir desde el principio que la fecha límite se acerca.
  • Preparación del trabajo. Un pequeño grupo senior explora y define un proyecto antes de entregárselo al equipo de desarrollo para que lo construya. Dar forma a los proyectos (Shaping), haciendo un trabajo previo al inicio del desarrollo, trata de conseguir un equilibrio entre ser lo suficientemente concretos para proporcionar una determinada dirección, y ser lo suficientemente abstractos para dar espacio al equipo en la fase de ejecución. El proceso de Shaping ayuda a resolver preguntas abiertas antes de asignar el proyecto al equipo de desarrollo.
  • Los equipos tienen plena responsabilidad. Los equipos tienen una mayor autonomía para definir tareas, hacer ajustes al alcance y dar lo mejor de ellos mismos. A su vez, esto también significa que los managers tendrán más tiempo para pensar estratégicamente y definir mejor los proyectos, en lugar de perder el tiempo en minucias y distrayendo constantemente a los equipos haciendo micro-gestión.
  • Reducción del riesgo. En su esencia, el método Shape Up busca reducir el riesgo de no entregar a tiempo.
  • Apuestas. Los proyectos que se les ha dado forma (Shaping) se llevan a la "mesa de apuestas” (betting table), donde las partes interesadas deciden en qué proyectos trabajar en el siguiente ciclo de desarrollo. Los proyectos que no se apuesta por ellos en el siguiente ciclo se descartan, no se les hace ningún tipo de seguimiento (tampoco van a un backlog).

---

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.

Raúl Alonso Sáez

Agile Delivery Leader at Paradigma Digital

2 años

Hombre, ya que calcas frases exactas de mi blog, podrías al menos citarlo, que es Creative Commons...

Inicia sesión para ver o añadir un comentario.

Más artículos de Marc Rovira Vall

Otros usuarios han visto

Ver temas