Elementos integradores de LeSS

Por mucho tiempo se ha estado buscando la combinación que mejor funcione y que permita que múltiples equipos Scrum puedan trabajar de manera productiva. Los creadores de LeSS, siguiendo un enfoque de experimentación, acabaron descubriendo que cosas no funcionan y cuales pueden tener buenas chances de funcionar.

Es precisamente porque con Scrum no hay receta cierta que muchos errores se acaban repitiendo una y otra vez. A lo anterior hay que sumarle el síndrome del “yo soy diferente” que básicamente consiste en creer que por alguna razón lo que no le funciona a nadie a mí me acabará funcionando bien.

Entrando en tema, en LeSS existen elementos que centralizan y otros que descentralizan. La idea de los centralizadores es crear alineación y seguir una linea común y desde luego los descentralizadores están para proveer autonomía y fomentar la creatividad. En este post hablaré de solamente un par de estos elementos centralizadores.

Un solo Product Owner para todos

Dentro de Scrum básico ya se veía desde hace décadas que la figura de un PO empoderado, visionario, emprendedor y que concibe el producto de manera sistemática, acaba siendo fundamental para llevar a buen termino el trabajo de varios equipos.

Desde luego lo anterior no quiere decir que el PO no escucha a nadie, por el contrario esta en constante comunicación con todos los equipos, interesados, clientes, usuarios, etc., pero al final del dia es el/ella quien tomas las decisiones de producto.

Visto desde la perspectiva opuesta, tener múltiples POs acaba creando dos grandes problemas:

  1. Una jerarquía accidental con múltiples niveles donde la comunicación fluye rápidamente de abajo hacia arriba pero no necesariamente igual de bien en la dirección contraria
  2. La demora en la toma de decisiones pues estas deben ser consensuadas en largas reuniones

Todos o nadie querrá ser ese PO

Si el salario, privilegios, poder de decision e influencia están concentrados en ese único PO, desde luego que todos en los equipos (o fuera de ellos) ambicionarán esa responsabilidad.

Es ahi donde precisamente LeSS propone hacer cambios sistémicos profundos dentro de la organización para que la figura del PO sea influyente y decisiva mas no jerárquica y burocrática.

En el extremo opuesto, ¿qué hacer cuando nadie quiere ser ese PO? La respuesta a la pregunta anterior puede ser el síntoma más no la causa raíz, quizás la verdadera razón resida en que la organización no crea productos innovadores, sigue recetas antiguas o simplemente castiga y busca responsables. 

Al explorar las causas raíz quizás se desvelen ante nosotros las verdaderas razones por las cuales nadie de buena gana se quiere aventurar a ser el PO de varios equipos.

Un unico repositorio sin ramas

La idea de que cada desarrolladores es libre, feliz y más productivo avanzando en solitario con su copia local de código es simplemente eso, una idea; idea qué por cierto ha probado una y otra vez ser contraproducente. Desde luego en este punto comenzarán Ustedes a pensar en contraargumentos como:

  • Es que así hemos trabajo siempre
  • Es que la gran empresa X a la que miramos con admiración trabaja de esta manera
  • Es que el manager de desarrollo, que hace 15 anos es manager y no desarrollador, nos dijo que trabajemos así
  • Es que en la universidad yo trabaja así y a eso estoy acostumbrado
  • Es que yo hago mi parte y luego veré como integro (si llego a integrar mi trabajo con el de los demás)
  • Y la clásica, este no es un problema para nosotros porque somos “diferentes”

Acortaré el camino y les daré la respuesta a sus males: todos los desarrolladores, en todos los equipos Scrum, todos los dias, en incrementos muy pequeños, integran su código sobre un repositorio que no tiene ramas.

Si lo anterior es difícil de entender vuelva a leerlo y verá que el problema no esta en el entendimiento de la oración sino en lo contraintuitivo que suena. Contraintuitivo porque estamos acostumbrados a hacer lo contrario de lo simple, disciplinado y ordenado.

La pesadilla de la integración

“Ya terminamos nuestras historias, solamente nos falta integrarlas”, ¿habrán escuchado de casualidad la frase anterior? De haberla escuchado quizás se hicieron preguntas como las siguientes:

  • ¿Cuánto tiempo tomará integrar todo?
  • ¿Porque no integramos antes?
  • ¿Y después de integrar recién vamos a poder probar si todo funciona?
  • ¿Qué vamos a mostrar en el Sprint Review de los equipos si nada esta integrado?
  • Y una pregunta existencial aún más profunda, ¿porque será que los desarrolladores desarrollan su código sin integrarlo continuamente?

Facilitaré la vida de mis lectores respondiendo solo a la última pregunta, los desarrolladores no integran su código frecuentemente porque piensan que integración continua es igual a una herramienta que compila el código de todos.

En LeSS redescubrimos un viejo concepto de eXtreme Programming, integración continua es integrar continuamente al final de cada ciclo corto e integrar siempre sobre el repositorio central.

Si lo anterior llega a ser entendido, digo realmente entendido, y practicado con una disciplina espartana, finalmente habremos despertado de la pesadilla de la integración.

La despedida

Así como existen elementos de centralización organizativa, como es el caso de tener un único PO, y elementos de centralización del trabajo técnico, como es el tener un único repositorio sin ramas, existen muchos mas elementos centralizadores dentro de LeSS – elementos que espero poder describir a futuro en otro post.

Sin embargo este juego de centralizar algunas cosas y descentralizar otras requiere un cambio profundo y la motivación para mantener este cambio. Al final LeSS, como herramienta de rediseño sistémico, lo que pretende es precisamente hacer que la forma cómo las organizaciones se estructuran cambie y de esta manera impactar el trabajo mismo y consecuente la organización de múltiples equipos Scrum.

Liderazgo y gestión del conocimiento

Siglos atrás era mucho menor el conocimiento necesario para emprender una actividad comercial, generar lucro y sostener una familia. De hecho el conocimiento era tan especifico que eran prioritariamente los artesanos quienes los poseían; de aquí es que podemos inferir que los artesanos como herreros, sastres, carpinteros y otros tenían un conocimiento profundo pero no amplio.

Las empresas, que dicho sea de paso son una invención relativamente moderna, si existían giraban en torno al taller de un artesano que con sus operarios y aprendices generan bienes para la venta. En ese contexto que casi ya no existe era muy sencillo pensar que quien dominaba su oficio podia generar productos, acomodarlos en el mercado, y llevar una vida relativamente tranquila.

Saltando al tiempo presente

A diferencia de lo que pasaba dos siglos atrás, hoy la mayoría de los profesionales trabaja, trabajó o aspira a trabajar en una gran empresa. Las empresas como tales son vistas por las sociedades como unidades productoras de riqueza y que emplean y brindan oportunidades de crecimiento a sus trabajadores.

Sin embargo hoy más que antes se hace necesario pensar en que el conocimiento que se aglutina dentro de una empresa es clave, no solo para seguir operando, sino también para sobrevivir en estos tiempos de alta competitivad e incertidumbre.

La gestión de este conocimiento, que dicho sea de paso es intangible y colectivo, es algo de lo que poco se habla en los círculos de lideres. 

La quimera del plan de capacitación

Muchas empresas interpretan la adquisición y gestión del conocimiento como algo que puede ser planificado, medido y gestionado por un departamento especifico. Lo anterior generalmente deriva en una lista de cursos, certificaciones y horas de entrenamiento que los empleados de una empresa deben completar si quieren crecer o mantener sus empleos.

Sin embargo hay varios factores que juegan en contra de este enfoque, por citar algunos:

  • El aprendizaje más efectivo ocurre en grupo y no de manera individual
  • Aprender requiere fuerzas intrínsecas no cuantificables como motivación y compromiso
  • El aprendizaje no tiene principio y fin mas es una actividad recurrente y atemporal
  • Los adultos necesitamos aprender de manera divertida

Si los puntos anteriores resuenan en la mente del lector entonces quizás comienza a formarse la idea de que si es tan difícil lidiar con el aprendizaje porque mejor no hacer terciarización de tareas, proyectos y conocimiento.

Terciarizar o no terciarizar, esa es la pregunta

La terciarizacion se vuelve algo tentador pues es fácil pensar que si no tengo el conocimiento dentro de una empresa puedo comprarlo afuera a un precio razonable. Seamos sinceros, quiero terciarizar para pagar lo menos posible y obtener un servicio, producto o conocimiento de altísima calidad.

La terciarización de actividades mecánicas, distractivas pero necesarias, como digamos la limpieza de oficinas, tiene total sentido. Al final como lideres de una empresa no necesitamos que nuestros empleados se vuelvan expertos en limpieza si nuestro rubro es otro. Sin embargo hay tareas y conocimiento que son el centro mismos del negocio que no pueden ni deben ser terciarizados.

Conocimiento y software

El software, y lamento comunicar esta noticia, no es un activo fijo, no es barato, no es simple de hacer, no es estático y no debe de ninguna manera ser de baja calidad.

Un paréntesis, creo que es económico pensar como líder de una empresa que puedo tener ciertos componentes de la infraestructura y operaciones de una empresa que no necesariamente deben ser de primerísima calidad, por ejemplo papel, escritorios, sillas, etc. Sin embargo es muy riesgo trabajar con software de dudosa o baja calidad.

Retomando paso una idea poderosa: el software es la expresión del conocimiento de una empresa. Explicando un poco mejor la idea anterior presento un ejemplo, si tenemos un gran banco con operaciones transnacionales el “como” ese banco sirve a sus clientes esta reflejado en reglas de negocio, formulas, cálculos, excepciones, etc. que viven no en papel sino en software. 

Una otra idea poderosa, el software cambia pues el negocio también cambia. Entonces si el software cambiará constantemente, será el conocimiento el que permitió crear software diseñado para cambiar, es decir software que abarata el costo del cambio. En este punto dirán Ustedes, ¿pero y cuál es el problema si tengo un terciarizador que me hizo el software y lo puede cambiar?

Mi respuesta a la pregunta anterior es doble: primero, acaban de diseñar su empresa para ser constantemente dependiente de alguien (léase relación potencialmente asimétrica), y segundo, el conocimiento no existe mas dentro de las competencias directamente bajo su control (lease refuerzo de la relación asimétrica con el terciarizador).

Bueno, bonito, barato y leal 

En un mundo ideal podríamos pensar que existen proveedores de servicios terciarizados que son excelentes en lo que hacen, y posiblemente los hay en muchos rubros más no en el software. Mi afirmación anterior posiblemente hiere la sensibilidad de los lectores más no es mi interior criticar sino enfatizar que el software para ser considerado “bueno” debe tener un costo de cambio minino (Adaptabilidad = Agilidad, ¿recuerdan?)

El software puede también ser “bonito” cuando reúne un grupo de atributos que hacen que quienes lo utilizan piensan de él como una pieza fina de arte. Más ser “bonito” no implica para nada dejar de lado el pragmatismo de que el software se hizo para resolver algún problema y necesidad y es en sí una herramienta para la generación de ganancias.

Barato, oh barato, ¿cuántas veces compraran barato y acabaron pagando caro? Yendo más atrás con esta pregunta, para que algo (un servicio, un conocimiento o software) se vuelva mucho más barato tendría que realizarse en un país cuya economía y costo de vida son correspondientemente mas baratos. Jugando al economista, que por cierto no lo soy, lanzo la siguiente hipótesis, un país cuya economía es más barata también produce un sistema educativo de menor calidad que consecuentemente repercute en la capacidad de sus profesionales de adquirir y dominar conocimiento avanzado. Jugando al sociólogo, que tampoco lo soy, lanzo una segunda hipótesis, un país con una economía limitada acaba produciendo hábitos de comportamiento en sus profesionales que no necesariamente les permitirán ser disciplinados, colaborativos y creativos.

Si por fortuna encontraron un proveedor bueno, bonito y barato, ahora surge el tema de la lealtad pues los competidores de Ustedes también querrán trabajar con ese proveedor. Desde luego Ustedes dirán “pero tenemos firmado un contrato de exclusividad”, y mi contra respuesta es que si bien ese contrato existe ese proveedor opera en un país donde el ámbito legal no es necesariamente transparente. Jugando al abogado, que por cierto tampoco lo soy, lanzo una tercera hipótesis, un contrato no puede limitar por completo el accionar de un proveedor en un país a miles de kilómetros y cuyo sistema legal puede no operar de manera correcta todo el tiempo.

Lideres generalistas

Mis argumentos anteriores tratan de ayudar a formular esta hipótesis:

  • Los lideres de empresas deben tener un conocimiento amplio que les permita entender los diferentes aspectos de cómo se genera valor dentro de sus empresas.
    • Complementando la hipótesis anterior, no entender por completo la importancia y complejidad del software puede comprometer la generación de valor.

La hipótesis anterior tiene varias derivaciones, quizás la primera y más natural de ella es que Ustedes dirán “pero no somos una empresa de software”, y quizás no lo sean, digo si hacen todo absolutamente a mano y a la antigua. Mas si por el contrario, usan, consumen, se integran, canalizan, etc. sus operaciones cotidianas y generadoras de valor a través de software, lamento comunicarles que en realidad son una empresa de software aplicada al rubro X.

Concebirse como una empresa de software no es algo malo en lo absoluto, de hecho la Agilidad, Scrum y otros derivados vienen del software. Entender porque vienen del software les abrirá los ojos hacia una forma de management más moderna que se basa en algunos principios simples que parafraseo a continuación:

  • Organizar la empresa en torno a equipos de producto que resuelvan problemas reales y generen valor
  • Mantener el realismo a través de la cercanía constante con el mercado y los clientes
  • Habilitar la comunicación y colaboración alejándose de la burocracia

Ser un líder generalista me ayudará también a entender mejor este trabalenguas: equipos pequeños de funcionalidad cruzada formados por especialistas-generalistas, empresas lideradas por generalistas-especialistas. El trabalenguas anterior es la base de lo en el mundo Agil llamamos “equipos Scrum” y “organizaciones Agiles”.

El cierre

Escribir estas ideas no fue fácil, de hecho solo lo hice porque un amigo muy querido me pido hacerlo. Espero que algunas de estos pensamientos hayan detonado en Ustedes algún sentimiento, un acuerdo, un desacuerdo, una reflexión y por lo menos la sensación de haber invertido algo de su tiempo leyendo un punto de vista alternativo.

Un pensamiento final, como líder puedo entender “que” empresa estoy liderando y puedo tener mi propio estilo de liderazgo, y es precisamente ese “estilo” de liderazgo el que irá cambiando si voy entendiendo el “porque” que hay detrás de la Agilidad.

Reflexiones después de leer “The Age of Agile”

Stephen Denning escribió en 2018 “The Age of Agile“, libro en el cual plantea la tesis de que nuestras sociedades, después de pasar por varias innovaciones tecnológicas (e.g. canales, trenes, acero, producción, en masa, y telecomunicaciones) se encuentran en el tiempo presente en una era de gran cambio e incertidumbre, condiciones que claman por la necesidad de incorporar la Agilidad como el paradigma dominante dentro de las empresas.

Sin embargo este clamor −que más que un capricho o una corriente de modernidad, es una necesidad− se ve grandemente limitado por la visión tradicional de gestión que tiende a centralizar poder económico y de decisiones en niveles ejecutivos. En la segunda parte de su libro Denning hace un análisis muy profundo acerca del efecto −en general negativo− que ha tenido en la empresas el emitir acciones e incentivar a los ejecutivos para que siempre traten de maximizar el valor de cotización esas acciones.

Continuando con su análisis Denning nos recuerda que el ofrecer acciones a ejecutivos como parte de su compensación, o permitir que las empresas compren y revendan sus propias acciones; en general ha traído consecuencias negativas para las empresas. Desde luego las practicas anteriores han hecho millonarios a varios ejecutivos e inversionistas pero no han contribuido a crear empresas con capacidad de innovación que hagan felices a sus trabajadores y a su entorno.

Agil viene en contraposición pues apunta exactamente a lo contrario, es decir: a crear un ambiente humanizante y gratificante donde los trabajadores puedan innovar a gusto y crear de manera sostenible productos con valor para los cliente finales. Un corolario de lo anterior es que en una empresa que aspira a ser realmente Agil no se necesitan ejecutivos estrella, sino más bien trabajadores capaces y motivados que se autoorganicen en equipos pequeños que creen productos y resuelvan necesidades.

Denning hace también una revision historia para tratar de llegar a los orígenes de la Agilidad como concepto. Según él fue Helmuth von Moltke, un general prusiano que en el siglo XIX, quien introdujo la adaptabilidad y los equipos pequeños como parte de la doctrina militar que aplicaba con sus tropas. Von Moltke fue un innovador para su tiempo pues desafió la noción común de su época que planteaba que los generales mandaban y los soldados solamente obedecían.

Denning plantea casi al final de su libro que para que las empresas realmente se puedan agilizar, el cambio debe ocurrir en diferentes instancias, a saber:

  • Los gerentes deben percibir que un nuevo tipo de management es necesario y estar dispuestos de corazón a entenderlo, adoptarlo y practicarlo.
  • Las juntas directivas de las empresas deben entender que las empresas no existen solamente para incrementar el valor de las acciones, y que por el contrario existen para crear valor y ocuparse de la gente.
  • Los gerentes financieros deben dejar de pensar que enviar trabajo a países con salarios más baratos realmente ayuda a reducir costos.
  • El sector financiero debe dejar de incentivar prácticas que se enfoquen solamente en obtener lucro temporal a cualquier costo.
  • Los organismos reguladores deben sancionar comportamientos de empresas que pretenden mostrar a cualquier costo que el precio de sus acciones sube pero en desmedro de la innovación, la capacidad creativa y la motivación de sus empleados.
  • Las agencias calificadoras deben dejar de tomar el precio por acción como el indicador definitivo que separa a las empresas pseudo exitosas de las demás.
  • Los inversionistas deben dejar de pensar que al comprar acciones se convierten en dueños de una empresa y por tanto tienen derecho a extraer lucro sin importar las consecuencias a largo plazo.
  • Los politicos debe trazar políticas más coherentes que tiendan a favorecer empresas que creen ecosistemas de innovación y bienestar.
  • Las escuelas de negocio deben dejar de enseñar teorías de administración que no condicen con los tiempos actuales.
  • La prensa debe dejar de presentar como héroes a los ejecutivos que ganan millones en empresas donde los demás empleados ganan muchísimo menos.
  • Y finalmente, los lideres intelectuales deben pensar y seguir explorando hacia donde nos llevara la Agilidad en los próximos anos.

Todos los cambios de la lista anterior pueden sonar drásticos y en verdad si lo son, mas no son utópicos y por el contrario se hacen necesarios. Denning al final del libro nos dejó un pensamiento alentador de Margaret Mead quien dijo: “Nunca dudes que un pequeño grupo de ciudadanos reflexivos y comprometidos puede cambiar el mundo. De hecho, es lo único que lo ha hecho”.

Mis reflexiones después de leer “Fifty Quick Ideas To Improve Your Tests”

Este libro escrito por Gojko Adzic, David Evans y Tom Roden presenta una colección de ideas que podrían mejorar las practicas de testeo de un equipo. Sin embargo creo que no debe confundirse, este libro no es para testers, es para equipos multidisciplinarios que hacen del testing parte de su día a día.

El libro enfatiza ideas resumidas en cincuenta prácticas que podrían aplicarse, pero más importante que eso enfatiza que los desarrolladores mismos deberían testear su código.

Por mucho tiempo se creyó que testear el código de uno mismo no es efectivo pues uno tiende a tener una “vision de túnel”. El libro si bien reconoce que tal vision sesgada podría existir en algunos casos, enfatiza que la ineficiencia de tener roles especializados (que provocan desperdicios como cuellos de botella, dependencias y fallos en la transferencia de conocimientos) es mucho peor.

Los autores recomiendan que un grupo multidisciplinario puede reunirse y hablar de que testear, que escenario, en qué plataformas, etc. Al tener esta participación grupal la “vision de tunel” queda neutralizada y el siguiente paso es que cualquier persona que es parte de ese grupo multidisciplinario se dedique a realizar el testeo.

Finalmente, más allá de las técnicas propuestas por los autores −que no deberían tomarse como recetas sino más bien como ideas− rescato el hecho de que testing no es una actividad propia de un rol sino más bien una aliada de la artesanía de crear código limpio.

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.

Ways To Improve The Product Backlog

Keep the Backlog at a Manageable Size 

A Product Backlog with hundreds of items clouds visibility and demoralizes the team that can not clearly see the light at the end of the tunnel. What is even worst the cost of maintaining a huge backlog is so high that consumes the Product Owner’s time preventing her/him from working in more important things.

For the reasons stated above is very important to keep a backlog with the least number of items possible. Empirical evidence from several sources including my own experience show that less than one hundred items seems adequate. 

Be Proactive and Groom it

The Backlog Refinement Meeting is an event specifically designed to keep the backlog away from growing unnecessarily and with the wrong level of detail. This event an other mechanisms should be used to keep the backlog in good shape and as a valuable artifact for the team. 

Making an analogy with gardening, grooming is an essential activity that needs to be performed weekly or bi-weekly at the most, if not plants and trees grow wildly and eventually the whole garden ecosystem starts to degrade. Not grooming the backlog will cause the same effect: degradation. 

Share the Backlog with Stakeholders

Having stakeholders input about the backlog is very valuable because it helps the team to gain reassurance if they are building the right product with the right features. From the stakeholders perspective it’s very valuable to learn if the team is correctly interpreting their needs and concerns and crafted a possible solution that is being represented in the form of backlog items.

Trying to share the backlog with stakeholders will fail if communication is not effective and for this high bandwidth communication like face to face dialog is always recommended. Avoiding concussing terminology in the communication is another recommendation.

Techniques to Organize and Filter a Product Backlog

The best way to think of filtering the Product Backlog is to imagine it -or actually have it- in a spreadsheet and apply a condition that will display only the rows that meet that condition hiding the rest.

Filters can provide views of the Product Backlog without necessarily changing priorities. In fact, by seeing just a portion of the Product Backlog that meets certain criterion we might discover that we need to reorder the Product Backlog by changing priorities.

Organizing items in the Product Backlog around certain characteristics is another form of filtering, for instance we might decide to organize the backlog putting high risk items first.

By ordering the Product Backlog we may change priorities or just do something more temporary like applying a filter for visualization purposes only. Next you’ll find two techniques that can be really handy for organizing and filtering a Product Backlog.

Specific user/customer types 

Which basically means filtering all items that a particular user/customer will use; in other words, the filtering criterion will be user/customer type.  An example of this could be having a Product Backlog for a product similar to Uber in which you filter by driver or by customer.

Feature areas

In this other techniques the idea is to filter by observable functionality that end users would be able to use and interact with. In simpler terms, the filtering criterion will be the feature area name that represents functionality. If we take the Uber app example again a feature area could be “Request a Ride” that has a lot of backend functionally but more importantly is directly observable and has great value for end users.

One last reflection, both techniques can be combined to narrow down the displayed items, for example we could filter the Product Backlog to only see items that correspondo to the feature area “Request a Ride” and that will be used by the “Driver”.

When and How to Test Hypothesis

The Scrum Framework is not specifically prescribing when and how to test product hypothesis and perhaps that is one of the reasons why many teams and organizations out there are building entire products without incorporating stakeholders’ feedback.

The consequences of such practices could be severe as teams might build a product that is not serving stakeholders needs or not in the way stakeholders are expecting. 

If the hypothesis validation could be completed before starting Sprints then the team is in a much better position to plan. A word of caution though, waiting for all hypothesis and assumptions to be validated before starting a single Spring might be the equivalent of working in phases and that would lead to waterfall development.

A more dynamic approach could be that the Product Owners validates assumptions a Sprint or two ahead of the of the Development Team. This validation with stakeholders could be done using paper prototypes (see page 47) or any other technique.

It’s important to mention that regarding of the technique or tools that used for this validation this is just a resemblance of the “real thing” that the team would be building. The corollary of this is that paper prototype should be good enough to provide insights and allow feedback but then the team will need to build the “real thing” as fast and as good as they can.

The Scrum Team should align its Spring Goal to deliver results to really test the assumptions, otherwise the Scrum Team might end up building something that looks great from a technical stand point but that is not contributing to validate hypothesis that were formulated based on stakeholder’s needs. 

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