Tag Archives: scrum

eXtreme Coaching

by

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” ( 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].

Medir o no medir, ésa es la cuestión

by

En estos días estoy en un proyecto muy bonito ayudándoles a desarrollarlo con un enfoque ágil que luego puedan asumir como propio en otros proyectos. Es tan bonito que el nombre que hemos dado al proyecto de coaching es “Proyecto Bonito”. Un equipo como éste es toda una garantía de éxito: motivado, autoexigente, con muchas ganas de aprender y hacer las cosas mejor (ya las hacían bien, pero quieren hacerlas aún mejor). Este proyecto es tan bonito que incluso tenemos dueño de producto (dos: a falta de uno, dos). Son proxies del cliente, pero está plenamente justificado porque nuestro cliente está a muchos miles de kilómetros de distancia. Y está justificado el tener más de uno por eso de tener un respaldo durante las vacaciones… Yo, además, contento porque así es mucho más rico el backlog grooming que vamos haciendo. :-)

Hay retos, claro, si no no sería tan bonito… Tenemos que lidiar con la dispersión geográfica de sus miembros, con las dichosas vacaciones (¡quién las habrá inventado! :-P ) e incluso con retos técnicos como el uso de ExtJS. No son grandes retos, pero suficientes para sacar buenas conclusiones y no poner en riesgo ninguno de los objetivos, tanto el económico de tener éxito con el proyecto para nuestro cliente como el interno de interiorizar buenas prácticas ágiles y, además, tener cierto margen para ir obteniendo artefactos de arquitectura que luego puedan quedarse en la casa para abordar otros proyectos.

Pues bien, en este contexto nos van saliendo conversaciones interesantes que voy a intentar ir sacando en este blog poco a poco en la medida que pueda garantizar la debida confidencialidad. La primera de ellas que me gustaría sacar tiene que ver con la estimación de tareas.

Antes que nada:

¿Para qué estimamos las historias de usuario?

Yo no sé vosotros, pero a mi me gusta saber si el proyecto que tengo entre manos va bien, va mal, le queda mucho para acabar, seré capaz de entregar tal o cuál funcionalidad el mes que viene o dentro de tres meses… será mi pasado oscuro como jefe de proyecto o que es una pregunta muy normal cuando es tu responsabilidad manejar un presupuesto. Así que yo estimo historias y trato de responder a esas preguntas con un “si seguimos a este ritmo parece que sí” o “para ser posible tiene pinta de que tendríamos que hacer algo”. Otro día hablamos sobre cómo ayudo a responder a estas preguntas… :-)

Pues bien, en la primera reunión de planificación surgió lo típico: estimar en horas las tareas.

Y llegamos a la siguiente pregunta (a la que yo realmente quería llegar hoy):

¿Para qué estimamos las tareas?

A mi, personalmente, lo que realmente me interesa es tener un medio de provocar conversaciones que nos permitan reducir las diferencias de expectativas e ideas preconcebidas entre los diferentes miembros del equipo y el dueño del producto a la hora de abordar la historia de usuario en su conjunto y cada una de las tareas en particular. Y consigo este efecto pidiendo que se estimen las tareas… y cuidando de facilitar esas conversaciones, por supuesto.

Así que, al final, yo llego a la conclusión de que no es relevante si la estimación la hacemos en horas, en puntos o en lo que sea. Lo relevante es que salgamos todos alineados y con una conversación lo más rica posible alrededor de cada historia de usuario en el tablón.

LA FOTO: Un guiño a los seguidores de Dr. Who. Ayer vi dos episodios seguidos con niño1 y he terminado hablando con él sobre el continuo espacio-tiempo. :)

Nueva vida: días 3 y 4

by

Buff, 4 días y ya tengo troll y todo. :)

Bueno, al lío. Tengo la garganta hecha polvo por la sequedad del ambiente. Tengo que hidratarme más. Además, estoy pillando un catarro o algo así. No estoy haciendo pomodoros y eso se nota en mi productividad: mucho. No encuentro tiempo ni para tuitear.

Finalmente me decidí por hacer scrum con todos. Enrique Comba me advirtió del peligro de que un equipo se viera ninguneado por el jefe de proyecto. Hacer que los dos hicieran scrum por separado iba a ser peor aún porque hay demasiadas interdependencias entre ellos. Es mejor buscar la colaboración dentro del equipo: un producto en común, un objetivo en común. Va a ser complicado porque somos muchos. Ya hemos hecho una reunión diaria y ha durado más de media hora. Demasiado. No quiero ser autoindulgente. Sé que es la primera pero tenemos que mejorar esto.

Mi tablón es, provisionalmente, un papel de embalaje en la pared de un despacho. No está a la vista de todo el equipo y fácilmente accesible. Pero bueno. Así tampoco se ven las cosas que estoy haciendo mal. Ooops! Me falta por hacer el “product backlog”. No tengo perdón, pero es lo que hay. Soy consciente de que debo hacerlo lo antes posible. Es mi gran objetivo para mañana. SIN FALTA.

Estoy intentando que el equipo se enfoque en poner en producción cuanto antes y en la reunión de planificación (me resisto a llamarle sprint planning porque no he hablado aún de sprint) salieron muchas tareas y casi no tuve que manipular para que la gente se autoasignara. Tampoco estimamos. No me pareció útil porque necesito ganarme su confianza y permitirles que ellos mismos ganen en autoconfianza. No quise liarles en aquel momento con estimaciones; me pareció mejor simplemente pedirles que se pusieran a trabajar y que tardaran lo que fuera necesario para conseguir el objetivo. La reacción ha sido extraordinaria. A continuación en incluso al día siguiente  por la mañana me encontré a prácticamente todo el equipo totalmente enchufado. Un cambio brutal en comparación con los días anteriores en los que, en vez de trabajar, estaban cuchicheando entre ellos acerca de correos y comentarios que ponían en entredicho su profesionalidad.

Ya tenemos Hudson funcionando y desplegando automáticamente en dos entornos gracias a uno de los miembros del equipo más quemados. Me alegra mucho que esté recuperando la ilusión por venir a trabajar. Mañana por la mañana tenemos que afinarlo y ponerme al corriente. He delegado esto pero es demasiado importante como para no saber los detalles sobre cómo ha quedado.

Nuestro maestro en ecosistemas, Guido, ha instalado incluso Sonar. Tengo miedo a mirar los informes. De momento tenemos tests de un proyecto anterior que se han dejado ahí después de un copipega que se hizo al principio. Lógicamente fallan todos. Hay mucho que limpiar. Pero no ahora mismo. El objetivo es poner en producción lo antes posible y liberar presión que hay sobre mucha gente (a todos los niveles). ¿Será el lunes? Tengo poco tiempo para decidir porque hay que pedir a QA (no es un departamento sino unos usuarios del cliente) que nos validen lo que puede pasar a producción y reservar la ventana de cambio para hacer el paso a producción.

Aún no tengo ni idea de en qué consisten todas las funcionalidades que se esperan que estén listas para el día 20. Cuando veo el Mantis y reviso las incidencias que hay allí me suena a chino (bueno, a italiano porque tenemos el italispanglish como lingua franca). Afortunadamente el equipo es consciente de que ahí me tienen que ayudar y se están portando genial conmigo. De hecho, he manipulado un poco para que surgiera el tema en la primera reunión diaria. Creo que ha ayudado a rebajar algunas preocupaciones y a demostrar que el estilo de dirección es sensiblemente diferente.

Todos los días tenemos muchas interrupciones debidas a incidencias o tareas que vienen directamente de la aplicación en PRODUCCIÓN. Es muy difícil manerjar esto si encima no tienes criterio suficiente siquiera para ver si son urgentes o no. De nuevo, el equipo se está encargando de esto. Se autoorganizan. Pero voy a tener que darle la razón a mi jefa de que vamos a tener que destinar a dos o tres personas para este tipo de actuaciones manuales. Ya lo hemos visto hoy en la primera reunión diaria. Mañana lo afinaremos, pero la idea es que estas personas estén todo el tiempo trabajando entareas muy manuales y laboriosas (más propias de un operador que de un programador) pero que nos va a permitir por un lado proteger al resto del equipo de muchas interrupciones y por otro lado identificar tareas que se pueden automatizar y, potencialmente, incluso ir automatizándolas.

Mañana hablaremos tras la reunión diaria de vacaciones y de autoorganización. Difícil y sensible tema. Pero la realidad es que a base de no conceder vacaciones al equipo ahora tengo menos disponibilidad. ¿Cómo llamamos a eso? ¿Deuda de gestión?

Mañana por la noche tengo una cena con gente superinteresante. Voy a poder escuchar a Luismi Cavallé intercambiando opiniones e ideas sobre la artesanía del software con Enrique Comba y Xavi Gost. Y además Alejandro Pérez y Roberto Canales no tendrán, como otras veces, que pagar la cena. :)

Ahora. A dormir. Que hay que conseguir un ritmo sostenible. ;)