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.

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.