Después de leer Agile Product Management With Scrum

Roman Pichler escribió ya hace diez años este libro que se ha convertido en un clásico pero que al igual que cualquier cosa que se vuelve clásica, contiene conceptos buenos para su época pero no necesariamente para el tiempo presente.

Mi principal observación es que en el libro siguen mencionándose resabios de la vieja noción de que el Product Owner es el manager del equipo, ejemplo de esto es que el autor menciona que en el Sprint Review el equipo presenta para el Product Owner lo que pudo lograr y que el Product Owner puede o no asistir al Daily Scrum Meeting para enterarse de que esta haciendo el equipo..

Yo llamo a estas conceptos de “viejo Scrum” porque fueron ideas y practicas útiles hace una década cuando Scrum se encontraba en una fase más temprana de maduración. En “Scrum moderno” entendemos que el Sprint Review es un evento que involucra stakeholders para que ellos usen el Incremento de Producto y así podamos recolectar feedback directo. También entendemos ahora que él Product Owner al ser parte del Scrum Team y al éste tener una jerarquía plana no tiene excusa para no ser parte del Daily Scrum Meeting.

Pichler visionariamente en su libro ya decía una década atrás que el Burndown Chart para un Sprint no era buena idea y que no debía usarse como una herramienta de reporte. Pichler también expresa su preferencia por utilizar Release Burndown/Burnup charts que deben dibujarse en papelógrafos y ser trabajados y discutidos por el equipo.

Una década atrás Pichler, al igual que muchos autores de esa época, proponían Scrum of Scrums como un mecanismo de escalamiento y coordinación. En “Scrum moderno” aprendimos que Scrum of Scrums no acaba siendo efectivo y tiene el efecto colateral no deseado de crear una jerarquía implícita en torno al rol del Scrum Master, qué es exactamente lo que no queremos.

En resumen, Pichler escribió un gran libro para su tiempo presentando conocimiento de manera resumida y directa, el problema surge cuando ese conocimiento cae en obsolescencia. Personalmente esperaría con muchas ganas que Pichler escriba una segunda edición actualizada de su libro.

Lo que me dejo el leer “Behind Closed Doors”

Johanna Rothman y Esther Derby escribieron el 2005 el libro “Behind Closed Doors: Secrets of Great Management” que fue uno de los primeros libros que trató de abordar cuál seria el rol y las competencias de un manager dentro de un entorno ágil.

Desde mi humilde perspectiva el libro tiene algunas concepciones que contraponen a la agilidad, la mas notoria es que trata de perpetuar el rol del manager tradicional pero ahora en una version ágil.

La contraposición se produce además porque hace más efectivo el rol del manager sin empoderar totalmente al equipo ni tomar el coaching como una herramienta fundamental de autodesarrollo del equipo mismo.

Sin embargo creo que aquellos quienes se encuentran actualmente en el rol de managers encontraran algunas técnicas y herramientas valiosas. Como las autoras mencionan en su libro típicamente las organizaciones promueven a sus mejores técnicos a posiciones de management sin proveer entrenamiento alguno, lo anterior produce un efecto negativo pues el conocimiento no es pasado al nuevo manager a través de mentoría ni entrenamiento guiado.

Algunas de los puntos principales que rescato del libro vienen a continuación:

Parece un consejo básico pero valedero, el ofrecer ayuda sin poder realmente brindarla acaba sonando a sarcasmo.

Este ultimo párrafo en la fotografía detonó en mi otro pensamiento: un manager que sólo hace tareas de management no esta en capacidad de ofrecer ayuda con temas técnicos.

Muchos dirían que para los temas técnicos tenemos el rol de Technical Lead, ¿pero qué pasara cuando esa persona que es Technical Lead quiera ganar más dinero? ¿Deberá buscar una promoción a manager?

Si la respuesta a la ultima pregunta es sí entonces el mensaje que la organización esta mandando es que la carrera de management paga más y es más valorada que la técnica. Lo malo de eso es que el código limpio no se hace con mejor management.

Manager que fuerzan el trabajo en múltiples frentes al final producen desenfoque y baja productividad.

Un buen manager, o cualquier persona que simplemente leyó acerca de neurociencias, debería saber que el cerebro humano no fue diseñado para hacer efectivamente tareas cognitivas en multitasking.

Por tanto es management by wishful thinking pensar que la gente de un equipo podrá hacer bien muchas cosas al mismo tiempo (aunque se ofrezcan incentivos y se compren pizzas).

Otro ejemplo de management by wishful thinking es pensar qué despidiendo a sólo una persona problemas de amplitud sistémica se acabaran resolviendo.

El corolario de la anterior frase también es cierto: contratar a una sola persona con la ilusión de que arregle ella sóla todos los problemas de una organización es wishful thinking.

Pensar qué una colección de personas que se conocieron recientemente son un equipo es otra forma de wishful thinking.

La gente, a diferencia de los recursos, necesita tiempo para aprender juntos, equivocarse juntos y crear ese espíritu de equipo del cual tanto hablan los libros. Conformar un equipo no algo que simplemente ocurre, es el resultado de una conjunción de factores que a veces se dan y a veces no.

Un manager que piensa que hacer staffing de recursos es lo mismo que construir equipos una vez mas estará haciendo management by wishful thinking.

En conclusion puedo decir que valió la pena leer el libro, tengo mis desacuerdos pero me sirvió para identificar mas formas de management by wishful thinking. Mi sugerencia es que los manager lo lean con ojos receptivos pero críticos porque al final el punto de un libro es siempre hacer que uno piense.

Después de leer Pragmatic Thinking & Learning de Andy Hunt

En un vuelo largo ayer termine de leer el libro “Pragmatic Thinking & Learning: Refactor Your Wetware” de uno de mis autores favoritos Andy Hunt.

El libro me dejo sabores mezclados por lo acostumbrado que estoy a esperar del autor lectura de temas profundamente técnicos. Hunt se aventura a explorar en su libros temas de psicología cognitiva, aprendizaje de adultos y neurociencias.

Si observamos desde una perspectiva holística todas esas disciplinas pueden contribuir grandemente al rápido y efectivo aprendizaje que se vuelve imprescindible para que la gente que aspira a crear código limpio.

En general del libro me llevo tres reflexiones, la primera de ellas viene del clásico modelo de aprendizaje de Dreyfus:

Este modelo muestra la progresión desde hacia un conocimiento experto que opera de manera natural, casi inexplicable y reservada para los maestros.

El modelo de Dreyfus, que me parece una alternativa interesante al sobre utilizado modelo Shu-Ha-Ri tomado de las artes marciales, muestra que no es posible llegar a un nivel experto sin haber invertido tiempo, esfuerzo y mentoría dedicada para alcanzar nuevas habilidades.

Este modelo resulta válido para cualquier disciplina manual o cognitiva, si pensamos por ejemplo en los mecánicos de automóviles ellos se vuelven expertos con muchos años de practica, metoría y un cumulo de errores cometidos. El nivel de expertise de un mecánico le permite diagnosticar con solo ver, escuchar e intuir la falla en un motor pero difícilmente puede verbalizar cómo sabe que ahi.

Similar nivel de expertise es el que puede observarse en software craftsman que intuyen que hay que refactorizar porque “huelen” que el código no esta bien.

Un corolario interesante de esta analogía con los mecánicos es que no se puede llegar a un nivel experto sin “hacer” el trabajo por mucho tiempo. Mi segunda reflexion del libro tiene que ve precisamente este punto, ver la siguiente ilustración:

La distribución poblacional indica que un porcentaje muy pero muy pequeño realmente alcanza el nivel experto.

Si la gráfica anterior es cierta, como parece serlo para muchas profesiones y oficios, ¿porque será que muchas gente en nuestra profesión del software se considera experta pocos años después de haberse graduado de la universidad?

Mi ultima reflexion tiene que ver con la poca efectividad de los cursos de capacitación dentro de la empresas, esta analogía la ilustra magistralmente:

Las ovejas pasan por este procedimiento forzado de desinfección que tiene un efecto temporal y debe realizarse periódicamente.

Los empleados de una empresa son enviados, a veces sin ser consultados a un curso de capacitación o certificación, aprenden con la mejor se su voluntad (o a veces no) durante los días que dura el curso pero luego regresan a sus puestos de trabajo a hacer las cosas como siempre solo cambiando pequeñas detalles y con el tiempo acaba olvidando todo lo aprendido.

Al igual que con la analogía de las ovejas, un nuevo “baño de conocimiento” es necesario quizás con un nuevo curso o un nuevo instructor. Este ciclo desde luego que genera negocio para muchos capacitadores, incluido su humilde servidor.

Pero habrá que preguntarse si genera beneficios duraderos para las empresas pues si estas no capitalizan esos beneficios la idea entera detrás de la agilidad puede diluirse.

Hunt propone algunas alternativas para hacer que los efectos del entrenamiento sean más duraderos, a saber:

  • Clubes de lectura formados por los mismos empleados
  • Grupos de práctica
  • Pair reading y mentoría cruzada
  • Y por sobre todo practica constante y dedicada de lo aprendido

Desde luego lo anterior requiere un mayor compromiso y apoyo de parte de la empresa pero principalmente de los estudiantes que participaron en el aprendizaje. Al fin y al cabo cada uno es dueño de su carrera y no es responsabilidad de nadie el forzarnos a aprender.

Finalmente creo que leer este libro fue una gran inversion de tiempo pues me sacó de mi zona de confort de conocimiento y eso es precisamente lo que hay que hacer para “refactorizar nuestro wetware”.

Reflexiones acerca de The Agile Samurai

Recientemente termine de leer el libro “The Agile Samurai” escrito por Jonathan Rasmusson. Debo en principio decir que encontré su estilo de escritura, con buenas ilustraciones y comentarios de un sensei imaginario, muy entretenido y valioso.

Varias cosas de este libro me llamaron la atencion, la primera de ellas fue esta grafica:

Analisis, pruebas y desarrollo todo en el mismo Sprint.

La razon por la cual me llamo la atencion es porque enfatiza la necesidad de realizar analisis “just in time” y “just enough”, analisis que al ser minimalista y oportuno posiblilita que historias sean codificadas y probadas dentro de la misma iteracion. Desde luego esto no seria posible si se comenten dos errores conceptuales: uno, escribir las historias en lugar de hablarlas, y dos, tener historias de varios dias de duracion.

Esta segunda grafica me parecio magistral porque ilustra bellamente un concepto clave:

La integracion continua implica integrar continuamente en una escala de tiempo de minutos.

El no integrar en una escala corta de tiempo (minutos) trae consigo serios problemas que repercutiran directamente en el exito de la iteracion.

La integracion continua es un tema que tecnologicamente ya se resolvio hace decada con la creacion de herramientas de software que compilan codigo de un repositorio compartido, sin embargo el tema humano que implica la comunicacion y disciplina necesarias para integrar codigo al final de cada ciclo corto de TDD es uno de los desafios pendientes de los equipos agiles.

Finalmente esta otra ilustracion me parecio mas que descriptiva:

La refactorizacion y frecuente constante es una herramienta valiosa para combatir la deuda tecnica.

Sin embargo una palabra de adavertencia, no es factible refactorizar constantemente si se carece de test unitarios y los test unitarios tambien se refactorizan. Esta parece una reflexion metacircular que incluso va mas halla pues todo codigo se debe refactorizar con el afan de introducir el conocimiento (tecnico y del domino del problema) mas reciente.

La no refactorizacion o la refactorizarion irresposablemente hecha que no considera pruebas unitarias, se vuelve una practica vacia y contraproducente.

En lineas generales puedo decir que despues de varios meses finalmente encontre un libro que describe adecuadamente el delicado balance entre las practicas ingeniereles y humanas que son necesarias para que la agilidad tenga chance de florecer.