Ourbit

Es responsabilidad de un Manager de Ingeniería garantizar la salud del equipo medida en términos de cualidades tales como performance, compromiso, responsabilidad y predictibilidad (entre un montón de otras). Sin embargo, esto no puede ser forzado por el Manager. En realidad el esfuerzo del equipo, y su correcta canalización son factores decisivos para alcanzar estos objetivos. Porque estos, son objetivos, ¿o no?

Bueno, esta primer discusión es interesante. ¿Cuál es el valor real de alcanzar estas cualidades? La compañía ¿puede vender “predictibilidad” a sus clientes? ¿Es la predictibilidad una feature de la aplicación?

Predictibilidad: ¿Una cualidad o un objetivo del equipo?

Si nos paramos en los zapatos de la “persona de producto”, podríamos decir que la predictibilidad es una forma de alcanzar los objetivos del equipo. Aún más, desde la perspectiva de producto, podríamos pensar que “predictibilidad” ni siquiera es algo (al menos hasta que el equipo deja de ser predecible). Pero desde el punto de vista del equipo, la predictibilidad es un objetivo en sí mismo. La parte engañosa para entender esto (entre otros tantos temas medio confusos) es analizar cuál es la causa y cuál el efecto. Hasta ahora, la predictibilidad parece ser la causa, y tener una nueva feature en tiempo y forma es el efecto. Esto es correcto. La predictibilidad es una causa, y por lo tanto no puede ser un efecto. ¿O si? ¡Por supuesto que sí! Cuando analizamos relaciones de “causa-efecto” siempre debemos recordar que todo se trata de una cadena. A->B->C->…Z. Ahora, digamos que una feaure en tiempo y forma es el un posible efecto causado por la predictibilidad (entre otro conjunto de causas). Y ahora, la parte importante: ¿Cuáles son las causas para lograr predictibilidad (como efecto/objetivo)?

Esta larga introducción no es solo el efecto de mi incapacidad de resumir. Estoy intentando establecer 2 hechos:

La predictibilidad es un objetivo del equipo (en medio de una cadena de causas y efectos).
El equipo necesita sentir su propia inclinación por ser predecible.

Ahora si, es una responsabilidad del Manager de Ingeniería alentar al equipo a lograrlo, y proveer las herramientas necesarias para que esto ocurra.

Pasemos a la historia

Capítulo I: Un equipo consciente

Mi equipo y yo la estábamos pasando mal. El roadmap estaba en un punto intermedio entre intenso e imposible. No parabamos de comprometer funcionalidades de más (y no cumplir), la predictibilidad era baja y cayendo rápidamente (por debajo del 40% durante varias sprints seguidas), y a pesar de que los refuerzos estaban comenzando a llegar, el esfuerzo inicial (ramp up) estaba por dejarnos en una situación incluso peor (al menos temporalmente). De a poco, managers de mayor jerarquía empezaban a aparecerse en nuestras daily meetings intentando descifrar lo que estaba pasando. Yo llamé a una reunión “no regular” en donde estaba a punto de tirar todas mis ideas arriba de la mesa cuando de repente, lo impensado. Uno de los miembros del equipo preguntó “¿Cuál es el problema con la predictibilidad? ¿Por qué de pronto es tan importante ser predecibles? ¿Por qué nos estamos preocupando tanto por los compromisos que no estamos cumpliendo?”. Yo estaba desconcertado. No podía pensar que esas preguntas estaban impulsadas por dudas legítimas, y tuve que frenarme de responder a alguien que, en ese momento, pensé que me estaba “trolleando”.

Y por suerte me frené, porque eso me obligó a comenzar un diálogo con esta persona y el equipo entero para descubrir que no había un entendimiento compartido acerca de lo que estábamos intentando lograr.

Lección 1: Asegurate de que todos estén en el barco. Entiendan que la predictibilidad es un objetivo del equipo y como tal, necesita ser definida y comunicada de una manera S.M.A.R.T. Como mencioné al comienzo, es imposible para un manager lograr este objetivo por sí mismo. Es un objetivo del equipo, y va a ser un logro del equipo.

Capítulo II: Causas primordiales

Yo ya era un manager experimentado, y había sido uno exitoso. Conocía todo tipo de trucos y métodos para hacer que las cosas pasaran. O al menos eso pensaba. Había estado intentando impulsar algunas ideas en el equipo que, en mi opinión, nos iban a llevar a mejorar la manera en la que estábamos trabajando (Predictibilidad incluida). Pero por alguna razón, sprint tras sprint no lograba que el equipo implementara estas ideas. Cada tanto solía pensar “ni estamos tratando”. La mayoría de estas ideas dependían de la implementación de algún mecanismo de seguimiento de tiempo, y no es novedad que esto no les gusta a los desarrolladores. Bueno, esto no es del todo cierto, y a decir verdad, es hasta un enunciado injusto. El “problema” real es que los developers generalmente son gente inteligente. Si tu equipo no está poblado con esta especie, estás en grandes problemas. La gente inteligente tiende a evitar los trámites sin sentido y, siendo honestos, salvo que haya una buena razón detrás de esto, realizar seguimiento del tiempo es exáctamente eso.

Durante una de las reuniones individuales que tuve con los miembros del equipo (luego del incidente “honestamente-no-un-troll”), me enfoqué en dos temas principales:

Definir claramente y de forma conjunta los objetivos individuales y los del equipo.
Entender las causas primordiales que impedían que el equipo alcanzara estos objetivos (desde la perspectiva de cada miembro).

Para que el segundo punto se dé, hay una precondición que no había mencionado antes porque no era un problema en nuestro equipo (pero que podría serlo en el tuyo): Como Manager, tenés que asegurarte de crear un ambiente de trabajo seguro. Cada miembro del equipo debería poder llegar a vos (o incluso saltarse un nivel si fuera necesario) planteando sus pensamientos sin ningún tipo de temor. Por ejemplo, no importa qué tan antinatural era para mi la pregunta “¿Por qué la predictibilidad es tan importante?”. Frené mi instinto natural de cortar esa conversación. En este caso, era significativa, pero incluso si no lo hubiese sido, era una gran oportunidad de crear relaciones de confianza. Si no podés con esto, vos y tu equipo están condenados.

Resulta que había montones de posibles causas primordiales para tan baja predictibilidad. Estas pueden variar de equipo a equipo, pero en este caso:

Falta de comportamiento de equipo: Las Stories eran trabajadas por individuos y no por el equipo. Por lo tanto, no había interacción durante las daily meetings, ni capacidad de maniobra para aquellas stories que iban camino a caerse. No había un diseño unificado, y no se compartía conocimiento.
Visión de producto poco clara: El equipo no era consciente del panorama general, y no estaba recibiendo las especificaciones funcionales con suficiente tiempo como para entenderlas. Esto generaba estimaciones constantemente imprecisas.
Story Points sin convención: Hablando con uno de los desarrolladores, acordamos que una story debería haberse terminado ya que estaba estimada apropiadamente en 5 puntos, que parecía ser una medida de puntos factibles por desarrollador durante una sprint. No obstante, la story no fue completada. Cuando pregunté a otros desarrolladores acerca de su opinión acerca de la cantidad de story points por persona durante una sprint, no obtuve dos respuestas que coincidieran.
Ausencia de métricas: Como con casi todo, las estimaciones no pueden ser mejoradas si no pueden ser medidas. Y es muy poco probable que puedas ser predecible si tus estimaciones andan flojas. ¿Cuánto tiempo podés escribir código por día? ¿Qué tan imprecisas son tus estimaciones? ¿Cómo vamos con esta story? entre otras preguntas, deberían ser fáciles de responder si queremos controlar nuestra capacidad (primero) y nuestra predictibilidad (después).
Las herramientas y procesos se traban en la mitad: Las herramientas y los procesos son geniales. Implementados como corresponde, estos pueden prevenir bugs, acelerar la velocidad de desarrollo, asegurar deployments más tranquilos, entre una larga lista de beneficios. Pero cuando una herramienta no está funcionando como debe, esto puede convertirse en una pesadilla y una sentencia devs.forEach(frustrate). A nadie le gusta trabajar horas interminables, pero todos aceptamos que esto puede pasar de vez en cuando. Resulta que los esfuerzos adicionales causados por una “herramienta de test estúpida” que se queda sin recursos y se convierte en el mayor cuello de botella del departamento de ingeniería, no está ni remotamente cerca de ser aceptable para un grupo de gente inteligente. Además del efecto demotivador, ¿Cómo alguien podría reclamar predictibilidad cuando cosas inesperadas como estas pasan todo el tiempo?

La anterior es una versión abreviada de lo que pasaba en la realidad, pero:

Ejemplifica el escenario.
Muestra algunas situaciones que encontré en otros equipos y en otras empresas.
Establece un par de situaciones fáciles de arreglar, pero difíciles de detectar.

Capítulo III: Acciones impulsadas por objetivos

No era cuestión de conocer las respuestas, sino de hacer las preguntas. Como mencioné, estaba (y siempre estuve) listo para aparecer con mi caja de herramientas, solucionar los problemas y salvar el día, cuando mi equipo me enseñó una valiosa lección: primero acordemos los objetivos y luego discutamos acerca de cómo alcanzarlos. Una vez que todos coincidimos en que queríamos ser predecibles (y por qué lo necesitábamos), sugerir las herramientas fue mucho más sencillo. Pero más importante que esto:

El equipo propuso algunas de estas herramientas.
El equipo me solicitó sugerir aquellas herramientas que ellos no conocían.

Todos sabemos cuan importante es, pero muy frecuentemente necesitamos un gran equipo para recordarnos que no somos la persona más inteligente de la sala, e incluso si lo fuéramos, no hay forma de ser más inteligentes que el equipo entero. Si vos pensás que lo sos, te tengo una mala noticia (podés elegir cual):

Necesitás un equipo más inteligente.
Tu equipo definitivamente necesita un manager más inteligente. Apuesto que esta segunda es la correcta, incluso si vos elegiste la otra.

Los objetivos eran una cadena (o un árbol) de causas y efectos. Estos objetivos podían agruparse como un gran hito: remover/mitigar las “causas primordiales” (mencionadas en el capítulo anterior).

Entonces, a modo de resumen, acordamos:

Insistir al equipo correspondiente para que arreglara los problemas con las herramientas, siendo flexibles en soportar temporalmente el esfuerzo adicional requerido para poder trabajar.
Mantener registro del tiempo invertido en lidiar con las herramientas y elaborar reportes para ayudar a los otros managers a priorizar correctamente los arreglos.
Dedicar el equipo entero a trabajar en el mismo set de funcionalidades durante las sprints.
Registrar el tiempo invertido en construir las funcionalidades (tiempo de trabajo continuo e ininterrumpido por día).
Registrar el esfuerzo restante a nivel tarea (antes estábamos viendo decaer los puntos cuando cerrábamos una historia). Este tema merece su propio artículo si no estás en tema. Pero básicamente hay que recordar que “Estimación Original” - “Tiempo dedicado” no siempre es igual a “Esfuerzo Restante”. Tener la capacidad de detectar esta diferencia tan pronto como sea posible es una herramienta decisiva al momento de ser predecibles.
Mostrar el progreso parcial durante las daily meetings (burn-down chart con granularidad fina).
Discutir acerca de cualquier desvío significativo tan pronto como este apareciera.

Por supuesto que esto es solo un resumen. Ni siquiera puedo recordar cuántos detalles fueron definidos sobre la marcha y si todas estas fueran las acciones originales que acordamos.

Capítulo IV: La parálisis causada por “demasiados cambios”

Estábamos por comenzar un gran refactor en la forma en que solíamos trabajar. Cuando escribimos código, tenemos (o deberíamos tener) una gran cantidad de tests unitarios, y estamos bastante seguros de no estar rompiendo nada. Pero esto es diferente. No existen frameworks de tests unitarios para personas.

No nos paralizamos una vez que acordamos y tomamos las decisiones como equipo. Pero no puedo evitar pensar que, antes de esto, conocer todo el trabajo implicado en este refactor era un freno para al menos comenzar con las discusiones.

Yo solía pasar mucho tiempo pensando cómo articular todas las acciones necesarias. Mientras esto es algo bueno, planear puede convertirse en una trampa. Siempre asegurate de que “planear” es tu herramienta para organizar los esfuerzos de tu equipo, y no una excusa para procrastinar profesionalmente. Si no sabés como hacer esto, usá el viejo análisis “causa efecto”. Pensá cuáles son los objetivos que querés alcanzar construyendo un plan.

En este caso, planear la forma en que íbamos a proceder no tenía sentido. Pero implementar todos los cambios al mismo tiempo nos habría llevado a una situación donde:

No íbamos a tener claridad acerca de qué cambios producían qué resultados.
No íbamos a ser capaces de identificar si algún cambio era en realidad un retroceso.
Los cambios requieren aprendizaje. Demasiados cambios implican aprender demasiadas cosas al mismo tiempo.

Nunca dejes que este tipo de cuestiones te frenen. Necesitás empezar con algo, medir los primeros resultados y decidir basado en las métricas arrojadas. Una vez más, no sos la persona más inteligente de la sala. Discutí con tu equipo acerca de los cambios a implementar al principio, recolectá datos, presentalos en la reunión de retrospectiva y discutan otra vez acerca de “qué sigue”.

Conclusión

Para el final de la tercera sprint desde que el equipo comenzó este refactor (ítems logrados):

El comportamiento del equipo mejoró radicalmente. Cualquier miembro del equipo era capaz de acudir en ayuda de cualquier otro.
El equipo era capaz de identificar las stories que estaban en riesgo y los motivos de las demoras (subestimación, problemas con las herramientas, bajo rendimiento individual).
El equipo tenía suficientes datos para tomar decisiones (comenzar con pruebas parciales antes de que la story estuviera completa, cambiar a una story diferente para evitar riesgos).

Para el final de la cuarta sprint:

El equipo estimaba más rápido y las estimaciones eran más precisas.
La visión de producto era compartida por el equipo entero.
Los desvíos respecto del roadmap eran previstos y se tomaban medidas correctivas.

“Ítems logrados”->”Predictibilidad”->”Features en tiempo y forma”. Todos eslabones en la cadena.