eXtreme Coaching

Palabras clave:
Tiempo aproximado: 4 min.

No, no se trata de este tipo de coaching

La semana pasada estuve en Altea (Alicante) porque DreamStarCash me pidió que les diera un taller de TDD con PHP. Lo cierto es que yo no he programado nada serio en PHP y me parecía estar fuera de mi zona de confort, aunque estoy tan bien rodeado que así no es posible acomodarse. ¿Verdad Luis? 😉

Para poneros un poco en contexto, DreamStarCash es una muy exitosa compañía que desarrolla software de gestión de contenidos para adultos. Traducido al castellano (y simplificando): se dedican al porno. Pero ojo, no os quedéis en eso simplemente porque os estaréis perdiendo un mundo muy interesante desde el punto de vista del negocio del software. Tienen millones de visitas diarias, que además de mucho dinero (que tienen que repartir con los proveedores de contenidos, los estudios) significa que tienen problemas de escalabilidad, seguridad, trazabilidad legal de los contenidos, calidad de servicio… Es un negocio con mucha competencia y no toda cumpliendo con la legalidad. Rodney, su director de operaciones (COO) y Steve (CEO y fundador) son tipos muy inteligentes y quieren construir una organización capaz de aprovechar las oportunidades de negocio y adaptarse más rápidamente a todos los cambios que se producen en el sector (nuevas leyes, nuevas tecnologías, nuevos competidores…). Por eso se pusieron en contacto con Xavi Gost (beCodeMyFriend) y, a través de él, conmigo. Entre otras cosas, querían consejo para hacer posible este cambio en la organización. Están siempre contratando porque no cubren puestos sino que buscan talento (si estás interesado, habla directamente con Rodney), apuestan por el agilismo, la mejora continua y hasta han salido en el blog de 37signals. Por cierto, si vas a estar por la PHPConference en Barcelona aprovecha y salúdalos.

Bueno, el caso es que al llegar a DreamStarCash (tras un más que agradable chapuzón en la playa) me reuní con Steve (CEO y fundador), Rodney (COO) y Damian (CTO) para explicarles cómo iba a ser el taller y charlar un rato sobre cómo trabajaban ellos normalmente. Fue una conversación muy honesta y eso siempre es de agradecer. Me gusta muchísimo el ambiente de startup (aunque ya no se puede decir que DreamStarCash lo sean) porque tienen esa esencia de “garaje”, de reducción de jerarquías, de buen rollo… vamos, de todo lo contrario al ambiente “enterprise”. En estas empresas puedes meter el cuchillo hasta el corazón porque sabes que tienes muchas probabilidades de ayudar realmente, en cambio, en las grandes corporaciones, la energía se disuelve entre las “politics” y los miedos al cambio.

De resultas de esta charla nos dimos cuenta de que lo que realmente necesitaban (y con urgencia) no era tanto un taller de TDD sino un cambio en su cultura. Ellos ya habían asistido a un curso de certificación en Scrum impartido por Tobias Mayer hace varios años. Con el devenir del tiempo y la búsqueda de la eficiciencia se encontraban en un escenario desgraciadamente muy habitual: una gran deuda técnica y defectos acumulados en su software y una cultura incapaz de buscar la mejora continua. Se estaban arrinconando en el típico enfrentamiento: ellos vs nosotros. “El equipo no se implica con los objetivos” o “los requisitos no son suficientemente detallados”. Y para colmo no hacían retrospectivas regulares ni la mayoría de los rituales de Scrum. Ni tan siquiera estaban haciendo Scrum en apariencia. Estaban haciendo “Scrum In Name Only” (@legnita gratias). 🙂

Estuvimos dándole vueltas a la posibilidad de cambiar de planes y hacer algo diferente. Realmente los managers se habían dado cuenta de que, efectivamente, tenían un problema muy serio en la cultura de la empresa en cuanto al desarrollo del software se refería y que tenían que hacer algo. Tras una brevísima retrospectiva, propusimos al equipo hacer durante la semana un proyecto muy pequeño pero haciendo Scrum con iteraciones de 1 día. SÍ, DE UN DÍA. En realidad apenas nos daba tiempo a hacer una preparación del backlog y 3 iteraciones, pero al estresar tanto el proceso yo quería provocar que aquellos “bad ticks” que tenían afloraran con más rapidez y fuerza que en un coaching más “relajado”. Por otro lado, los ciclos de feedback iban a ser mucho más frecuentes, lo cuál nos daría muchas más oportunidades para ver qué pasa en un proyecto normal y cómo reaccionar ante ellos.

Ha sido una de las mejores experiencias de mi vida profesional. Realmente espectacular ver cómo reaccionan las personas ante este tipo de retos. Al final de la semana les di muchísima caña. Los “golpes en las rodillas” (figurado) fueron muchos y algunos seguramente no cayeron demasiado bien. Pero hubo para todos: para el equipo de desarrollo y también para los managers. (Incluso para Steve) 🙂 Pero cuando las personas son autoexigentes valoran mucho la honestidad. En la retrospectiva final había muchas más opiniones positivas que negativas. Y las negativas estaban identificadas claramente como aspectos que querían mejorar. Ése es justamente el espíritu que trato de transmitir, y ellos lo habían entendido perfectamente. Estoy deseando poder anunciar el resultado de este pequeño proyecto, donde el equipo aprendió a escribir su backlog, historias de usuario, orientarse a construir producto incrementalmente, manejar las tareas y los conflictos durante el sprint, planificar junto al dueño de producto, decidir acciones tras las retrospectivas… vamos, a hacer agilismo del bueno. Claro, como podréis suponer, será [Adults only].