Informe de actualización: Prueba de la metodología 'Shape Up' de Basecamp

El año pasado, intenté trasladar a mi equipo de producto del enfoque clásico SCRUM a la metodología Shape Up de Basecamp. Fue una experiencia increíble; Aprendí mucho de ello y pensé en compartir algunos de mis hallazgos con ustedes.

Si has experimentado con esto tú mismo, me encantaría saber cómo te fue. Si no lo has hecho, me encantaría saber por qué te mantuviste alejado.

Parte 1: ¿Por qué ponerse en forma?

Mi equipo había estado usando SCRUM desde siempre. Durante nuestros días de inicio, vivíamos los ciclos tecnológicos clásicos: trabajar rápido, realizar envíos y no pensar demasiado en los procesos. Luego nos adquirieron.

Una vez que tuve un poco más de tiempo para considerar las opciones de metodología de nuestros productos, decidí probar Shape Up. Hubo algunas razones:

1. Hasta entonces, intentábamos sprints de 2 semanas y no lográbamos terminarlos de manera bastante consistente. Cada semana parecía una cinta transportadora de entradas que nunca terminaríamos.

   
   

2. El equipo se sentía como monos codificados. Escoger billete. Boleto de trabajo. Entregar billete.

   
   

3. Como nunca terminamos el sprint, las tareas siempre pasaban al siguiente. Al final, la presa se rompe.

   
   

4. A todos nos faltó concentración. Cada sprint fue una selección y combinación de cosas en las que trabajar en toda la base del código.

   
   

5. Muy poco trabajo en equipo. Cada desarrollador trabajaría en su pedacito del pastel, dejando poco espacio para aprender unos de otros y, francamente, un sentido de comunidad.

   
   

6. Casi no hay comprensión del cliente. Los desarrolladores recogían los tickets asignados, los hacían y no tenían idea de por qué/quién/qué.

Después de volver a leer La puesta en forma del campo base , Pensé en intentarlo ya que pretendía resolver la mayoría de esos problemas.

Parte 2: Lanzamiento interno

Una de las partes más difíciles de pasar a Shape Up fue presentar la idea internamente.

Dediqué más tiempo a internalizar la mayoría de los conceptos de Shape Up para asegurarme de estar preparado para cualquier pregunta. Como era de esperar, a los desarrolladores les encantó la idea de este nuevo enfoque (más tiempo, más concentración, más colaboración; ¡por qué no les gustaría!).

Tampoco sorprende que la jerarquía fuera más reticente. Al final logré convencerlos de la siguiente manera:

1. Asegurando que fue solo una prueba. Si las cosas no funcionaran, volveríamos a la "normalidad".

   
   

2. Asegurándome de que permanecería tan disponible como siempre para ayudarlos. Los desarrolladores estarían concentrados y serían ininterrumpibles, pero yo no.

   
   

3. Destacar Shape Up nos permite resolver problemas más grandes, lo que significa mayores oportunidades.

   
   

4. Insistir en el dolor que se vive actualmente producto del producto y cómo afecta a cada equipo.

Preparé una presentación de diapositivas muy clara y la repasé por cada jefe de departamento (servicio al cliente, ventas y C-suite).

Parte 3: Miedos y preocupaciones

Mi experiencia como fundador, comercializador y gerente de producto me ha enseñado que siempre vale la pena anotar las inquietudes antes de comenzar un experimento. Tuve algunos con Shape Up:

• ¿Cómo manejamos las distracciones? Sé que se supone que debo "decir no". 'Estabamos ocupados.' "El próximo ciclo podremos investigarlo". Esa es la teoría, y funciona si toda la empresa adopta esta metodología. Durante mi primera prueba en bicicleta, me preocupaba que surgiera una emergencia.

• ¿Atrasos? Shape Up recomienda que no haya retrasos (capítulo 7). Como recién estábamos probando esto, obviamente no fui y cmd+a+eliminé nuestro trabajo pendiente, pero aún así. Si adoptáramos esta metodología, me sentiría algo perdido sin un retraso.

• 'Casi terminado.' Éste realmente me asustó. ¿Qué sucede si llegamos al final del ciclo de 6 semanas y estamos tentativamente allí, pero no del todo? Basecamp dice "empezar de nuevo" (a menos que estés muy cerca). Me preocupaba que no acertáramos en el molesto rango del 20-30%.

Al final, ninguno de estos miedos/preocupaciones pudo impedirme continuar con el juicio. Sin embargo, valía la pena tenerlos en cuenta.

Parte 4: El ciclo

¡Y nos vamos!

Comencé el primer ciclo un lunes por la mañana y vi seis semanas de intensa concentración y trabajo en equipo. Aquí hay un resumen de lo que sucedió cada semana:

• Semana 1 : Saque inicial y... silencio. Dejar al equipo en paz, dejarles investigar y sumergirse en el código en su propio tiempo son una parte importante de esta metodología. Fue increíblemente difícil para mí dejarlo ir durante esa primera semana y no pedir actualizaciones. ¡Me mantuve fuerte!

• Semana 2 : El equipo finalmente salió de su caparazón. La comunicación se recuperó. El diseño del trabajo empezó a aparecer, tuvimos que dar algunos comentarios y trabajar juntos.

• Semana 3 : en teoría, la semana 3 debería ser la parte superior de la curva del ciclo. Al final, el equipo debería tener una muy buena idea de cómo van a construir lo que hay que construir. Creamos un canal de Slack específico para el ciclo a medida que la comunicación comenzó a mejorar adecuadamente. Al final de esa semana, vimos prototipos, diseños, fragmentos de código y más. ¡Estábamos en camino!

• Semana 4 : Tranquilo de nuevo. Todo el ir y venir de la semana 3 produjo una semana 4 enfocada en la que todos implementaron su trabajo. Iniciamos un viernes 'mostrar y contar'.

• Semana 5 : Semana de bola curva. Uno de los visores empezó a generar bastante conversación. Rápidamente quedó claro que el alcance no era lo suficientemente claro. No había sido lo suficientemente preciso en mis requisitos y lo que inicialmente parecía bonito y sencillo resultó ser complejo. Tuve que tomar la difícil decisión de cortar este alcance.

• Semana 6 : Los alcances restantes estaban funcionando muy bien. La intensidad aumentó drásticamente en la semana 6 mientras realizaba controles de calidad por todos lados y los desarrolladores repetían mis comentarios increíblemente rápido; Todos estábamos trabajando juntos para alcanzar el objetivo.

  
  

Al final, dimos en el blanco. ¡Lo hicimos! Fue súper intenso y estaba devastado porque tuvimos que cortar uno de los visores, pero lo logramos.

El lunes siguiente a las 10 am enviamos a producción.

Parte 5: Algunas lecciones

Sin ningún orden en particular, aquí hay algunas lecciones y recomendaciones:

1. Dar forma es difícil . Pensé que había hecho un trabajo decente al darle forma a la mayoría de las partes aterradoras del ciclo. Resulta que me perdí algo descaradamente obvio que casi descarriló todo el ciclo.

   
   

2. Incluya a su equipo durante la formación . Le di forma principalmente por mi cuenta y, a veces, con el líder de mi equipo de desarrollo. Habría sido valioso para mí incluir a otros desarrolladores.

   
   

3. Si te encuentras discutiendo o dando forma a mitad del ciclo, algo salió mal . Detén todo. Tu prioridad es resolverlo antes de que descarrile por completo todo lo demás.

   
   

4. La intensidad no está distribuida uniformemente . Ya sea entre miembros del equipo o a lo largo del ciclo, la intensidad del trabajo variará mucho. Como primer ministro, su función es detectar estos focos de intensidad y prestar especial atención a las personas que los atraviesan.

   
   

5. Crea un canal de Slack separado . Hizo que la comunicación fuera mucho más fácil pero también mucho más divertida. El equipo ciclista desarrolló rápidamente un lenguaje compartido, memes relacionados con el trabajo en el que estábamos trabajando, etc. Básicamente me sentí como si fuera una startup dentro del equipo.

   
   

6. Implementar reuniones de mostrar y contar desde la semana 1 . Esperamos demasiado para hacer esto. Debería haber suficiente para mostrar o discutir desde el final de la semana 1. También es una oportunidad para reunirse, discutir, aprender, etc.

   
   

7. El período de recuperación resultó ser mucho más difícil que el ciclo en sí . Todo el "otro trabajo" se había acumulado durante 6 semanas; Fue como volver a SCRUM. Esto es algo en lo que todavía estoy trabajando para mejorar.

Como probablemente podrás ver, esta prueba me convenció.

Implementar Shape Up y adoptar sus peculiaridades ciertamente no es algo que suceda de la noche a la mañana. Sospecho que será un largo proceso de aprendizaje. He apreciado especialmente el cambio de mentalidad que nos ha permitido este ensayo. Nosotros (y espero que los otros equipos) aprendimos a ver el trabajo tal como es: un desafío apasionante que superaremos juntos.

Si has probado esto (o no), ¡me encantaría leer algunas historias o comentarios!

Si te ha gustado esta publicación, es posible que disfrutes de mi boletín . Escribo sobre gestión de productos, comparto conocimientos prácticos y asumo desafíos de productos de la vida real por diversión (lo sé, ¿verdad?).