Los 8 grandes desperdicios del Top Management en TI

Estamos en tiempos disruptivos, los cambios saltan y avanzan por doquier, las innovaciones, el cambio climático, la inteligencia artificial, el Internet de las cosas, los virus (escribo esto cuando el COVID-19 está conquistando el mundo – por si lo lees en un futuro cercano o lejano –), la economía, la política entre otras cosas, se han vuelto impredecibles, bien etiquetaba el Ejército de los Estados Unidos esta era como VUCA (1), tiempos en los que el más rápido le quita el mercado al más lento.

Dado este contexto, la forma como hemos venido haciendo las cosas, aunque nos trajo hasta donde estamos hoy, no es muy útil para este presente ni para la supervivencia en el futuro, pues necesitas generar en tu organización la capacidad de adaptarte rápido a los cambios o de ser el causante del de ellos, es allí donde es necesario un liderazgo Lean-Agile: Lean (2) desde el enfoque de generación de flujo continuo de valor y eliminación del desperdicio, como Agile(3) desde su enfoque en la adaptación, mejora continua, generación de valor y colaboración.

Es desde la óptica Lean y su guerra sin cuartel contra el desperdicio, que quiero poner foco en este artículo, ya que desde TI y de las Áreas de Negocio “hoy en día” no podemos darnos el lujo de tener desperdicios a granel y no hacernos cargo de ellos, permitiéndole a la competencia ganar donde nosotros estamos perdiendo, ergo cualquier desperdicio tarde o temprano será valor que se dejó de generar, energía que dejamos ir y no podremos recuperar.

Los Ocho Desperdicios de Lean en Desarrollo y Mantenimiento de Productos de Software

Lean tiene identificado ocho desperdicios:

·     Sobreproducción

·     Inventario

·     Sobreprocesamiento

·     Defectos

·     Movimientos

·     Transporte

·     Esperas

·     Creatividad de los empleados no utilizada

Las áreas de TI no son ajeas a estos desperdicios. Seguramente han o has tenido que lidiar con algunos de los que enumero a continuación:

Sobreproducción: hacer más producto del que es requerido
Síntoma	Consecuencias	Sugerencias y Comentarios
Hacer más software o producto del que es requerido	·       Pérdida de dinero ·       Pérdida de tiempo invertido en hacer definiciones que no son requeridas ·       Pérdida de tiempo y dinero probando funcionalidades que no serán usadas ·       Pérdida de tiempo haciéndole mantenimiento a software que nadie usa ·       En el futuro, migrar a otros sistemas funcionalidades innecesarias ·       Software innecesario siendo causa de posibles errores y ocupando espacio en los servidores	·       Aplicar un enfoque ágil para el desarrollo de productos software ·       Construir MVP (Productos Mínimos Viables) (4) y validar hipótesis de valor lo antes posible ·       Comenzar a migrar a un paradigma enfocado en Valor y no en el Alcance. No se trata de hacer mucho, se trata de trabajar de forma inteligente ·       Priorizar los desarrollos de iniciativas, mantenimientos evolutivos y correctivos por valor, no le diga a todas las áreas ¡sí!

Inventario: almacenamiento de producto que no está siendo usado
Síntoma	Consecuencias	Sugerencias y Comentarios
Versiones o actualizaciones de software que se encuentran desarrolladas y probadas, pero “NADA” que pasan a producción, “NINGÚN” área de negocio las reclama, estan en los servidores de staging esperando que alguien se acuerde de ellas para pasar a producción	·       Costos y tiempos de actualización de versiones (ej: he visto pagar ingenieros por más de un año actualizando versiones que no salen a producción) ·       Costos y tiempos de pruebas de versiones que no están siendo usadas	·       Borre de su servidor las versiones que no han sido puestas en producción hace más de 4 meses, si nadie las reclama, es que nadie las necesita. ·       Priorice las versiones por valor (nuevamente no diga a todo sí, recuerde, no hay tiempo para construir desperdicio)
Software subutilizado o no utilizado	·       Millones de dólares en tiempo y dinero que no están siendo usados.	·         Identifique si el pareto (20%) de las funcionalidades le genera un 80% de impacto en el negocio. ·       Haga programas de gestión del cambio que le permita usar al menos el 20% de lo que compró.

Movimientos innecesarios: movimientos innecesarios por parte del equipo de trabajo
Síntoma	Consecuencias	Sugerencias y Comentarios
Demasiados procesos manuales de parte de su equipo	·       Emerge un gran número de errores durante los procesos debido a esos procesos manuales	·       Reemplace y priorice toda tarea repetitiva en su equipo por otra automatizada, de manera que tenga foco en la generación de valor, no tiene sentido que un desarrollador de software esté haciendo trabajo manual en pleno siglo 21. ·       Adopte una mentalidad y cultura de DevOps en su equipo, “automatice todo lo automatizable” ·       Genere pipelines de CI, CD ·       Cree macros que ayuden a poblar datos ·       Automatice las pruebas (de todo tipo) ·       Use bots ·       Tenga herramientas que le den tracking de todo su ciclo de desarrollo de software

Sobreprocesamiento: se está volviendo a realizar un proceso sobre un componente de forma innecesaria.
Síntoma	Consecuencias	Sugerencias y Comentarios
Las versiones no salen oportunamente debido a cambios en el entorno	·       Las versiones deben ser construidas de nuevo. ·       Pérdida de tiempo y dinero de todos los involucrados.	·         Ver las sugerencias de “desperdicios por inventario”
Se especificaron requisitos o historias de usuario que ya no son necesarias porque el negocio cambió, y es necesario volver a hacer definiciones	·       Pérdida de tiempo y dinero de todos los involucrados	·       Abandone la idea de tener en productos de software “todo” definido a priori, avance hacia realizar una definición progresiva de las funcionalidades, en vez, de una definición “completa” desde el inicio.
Refactor por componentes mal desarrollados (deuda técnica)	·       Pérdida de tiempo, dinero y performance del producto	·       Monitoreé y reduzca la deuda técnica, la Agilidad dependerá de ello. ·       Exija excelencia técnica tanto de sus colaboradores como de proveedores
Rediseño por componentes mal concebidos	·         Pérdida de tiempo, dinero y performance del producto.	·        Aplique principios de Arquitectura Evolutiva y Arquitectura Ágil que le permita ser resiliente a los cambios

Espera: tiempos muertos mientras se espera el próximo paso del proceso
Síntoma	Consecuencias	Sugerencias y Comentarios
Controles de cambio demasiado lentos	·       Pérdida de tiempo y dinero de los involucrados ·       Falta de generación oportuna de valor	·       Automatice su proceso de control de cambios, si es necesario ponga puntos de control, pero que no dependan de un comité, sino de un experto, y que este experto pueda aprobar sobre la herramienta directamente
Procesos de aprobación de paso entre plataformas demasiado lentos	·      Ibídem	·         Ibídem
Al cliente le llega el producto cuando: ·        no lo necesita ·        la  competencia le quito la porción de valor que esperaba ganar ·        ya no es necesaria la solución	·        Íbidem	·        Adopte una forma de pensar ágil en su organización ·        Aprenda a salir a producción con MVP lo más temprano posible (ojala al segundo mes ya tenga software funcionando en manos del cliente)

Defectos: defectos visibles e invisibles de los productos
Síntoma	Consecuencias	Sugerencias y Comentarios
Deuda técnica (defectos invisibles)	·       Pérdida de tiempo y dinero de los involucrados en la corrección ·       Impacto en el negocio por mal desempeño del producto	·       Monitorée y reduzca la deuda técnica, la Agilidad dependerá de ello. ·       Exija excelencia técnica tanto de sus colaboradores como de proveedores
Defectos en el producto (defectos visibles)	·        Íbidem	·        Exija excelencia técnica tanto de sus colaboradores como de proveedores ·        Es una buena estrategia que el equipo que desarrolla el producto sea el mismo que le da mantenimiento en producción, esto genera responsabilidad con lo construido. ·       Adopte DevSecOps, o el concepto de ShiftLeft y rete constantemente a su equipo de operaciones y desarrollo.

Movimientos innecesarios de los productos: el producto es movido a una fase anterior o a un punto innecesario
Síntoma	Consecuencias	Sugerencias y Comentarios
El producto se devuelve a la fase previa por mala calidad o problema en los requisitos.	·    Pérdida de tiempo y dinero de los involucrados Falta de generación oportuna de valor	·       Exija excelencia técnica tanto de sus colaboradores como de proveedores ·       Tenga una aproximación ágil en la construcción de productos, haciendo definición progresiva de los mismos.
El producto debe ser “bajado” de producción porque la versión salió defectuosa	·         Pérdida de tiempo y dinero de los involucrados ·        Mal impacto ante el cliente	·       Use estrategias de DevOps como: “Canary Releases” (5), “Dark launches” (6) , “Feature Toogles”(7). ·        Desacople Release (Liberación) de Despliegue (8), le dará más maniobrabilidad

No emplear el talento de las personas
Síntoma	Consecuencias	Sugerencias y Comentarios
Solo su voz es la que importa y usted es el dueño de la estrategia	·         Está perdiendo la oportunidad de recoger recomendaciones importantes de su equipo de trabajo	·       Reúnase una vez al mes con su equipo y encuentren 2 a 3 cosas a mejorar para el siguiente mes.
Estamos demasiado ocupados para sentarnos a conversar y mejorar	·       Íbidem	·       Rompa el círculo vicioso y frenético de: “no mejoramos porque no tenemos tiempo, no tenemos tiempo porque no mejoramos” ·       Reúnase una vez al mes con su equipo y encuentren 2 a 3 cosas a mejorar para el siguiente mes y en efecto mejórelas (sino esta reunión tambien será desperdicio)

Llamado a la acción

Si desde TI o las Áreas de negocio vamos a generar desperdicios, que estos sean experimentos controlados de productos rápidos y baratos, que nos permitan capturar aprendizaje y nos den pistas sobre cómo avanzar en este terreno de volatilidad, incertidumbre, complejidad y ambigüedad, pero que no sean pérdidas de energía que terminen dando oportunidad a la competencia.

Si como CIO, o parte del Equipo del Top Management de TI has identificado al menos uno de estos síntomas, priorízalo, haz de la mejora continua la costumbre de tu equipo, toma métricas y comienza tu camino hacia la excelencia operativa y de negocios de una forma decidida y constante.

Como siempre, bienvenida la retroalimentación

Saludos Ágiles

Jorge Abad.

Notas, Aclaraciones, Comentarios, Referencias y Observaciones.

1.      VUCA es un acrónimo utilizado para describir o reflejar la volatilidad, incertidumbre (uncertainty en inglés), complejidad y ambigüedad de condiciones y situaciones. Más información en https://es.wikipedia.org/wiki/VUCA

2.      Lean es la forma como Jame Womack acuño la esencia del Toyota Production System. Más información en https://en.wikipedia.org/wiki/Lean_thinking

3.      Agile es la forma como es conocido el Agile Software Development, comprende varios enfoques para el desarrollo de software bajo los cuales los requisitos y las soluciones evolucionan a través del esfuerzo colaborativo de equipos autoorganizados y multifuncionales y sus clientes / usuarios finales, es representado condensado en cuatro valores y doce principios. Ver más en https://en.wikipedia.org/wiki/Agile_software_development.

4.      Un Producto Mínimo viable (MVP – Minimum Viable Product por sus siglas en Inglés ) es una versión de un producto con características suficientes para satisfacer a los primeros clientes y proporcionar comentarios para el desarrollo futuro del producto.  Ver más en https://en.wikipedia.org/wiki/Minimum_viable_product.

5.      Canary releases: Técnica que proporciona un mecanismo para lanzar la solución a producción a un segmento de Cliente específico y medir los resultados, antes de expandirse y lanzar a más clientes. Ver más en https://www.scaledagileframework.com/release-on-demand/.

6.      Dark Launches: Esta técnica proporciona la capacidad de desplear en un entorno de producción de forma “apagada” sin liberar la funcionalidad a los usuarios finales.

7.      Feature Toogles: Esta es una técnica para facilitar los “Dark launches” mediante la implementación de conmutadores en el código, que permite cambiar entre funcionalidad antigua y nueva. Ver más en https://www.scaledagileframework.com/release-on-demand/.

8.      Desacople el Release del Despliegue, estrategia de DevOps que permite poner código constantemente en producción y habilitarlo cuando este vaya a ser usado, reduciendo el impacton impacto la estabilidad del sistema por cambios realizdos. Ver más en https://www.scaledagileframework.com/release-on-demand/.

9.      Gracias a mis amigos Lucho Salazar- https://www.linkedin.com/in/luchosalazar/ -  y Ricardo Cruz - https://www.linkedin.com/in/ricardocruzmartinez/ -  por sus aportes y correcciones.

Agile Apesta | Ágil Apesta | Agile Sucks

¡Que bueno, atrapé tu atención! Al parecer varios estudios han demostrado nuestra preferencia por las noticias malas y todo aquello escrito en tono negativo es fuente de observación inmediata de nuestra mente, ya sea por instinto de supervivencia o por morbo, es una de las razones por las cuales las redes sociales y los periódicos tienden a volverse más tóxicos -les recomiendo ver las referencias (1)-.

Quiero aprovechar este comportamiento que todos poseemos para compartirte que Agile Apesta o Ágil Apesta o Agile Sucks bajo muchas circunstancias endógenas y exógenas, pues se volvió un objeto de deseo, mas eso no implica que se esté haciendo bien, se asemeja más a un jabón resbaloso que solo se deja atrapar junto a la esquina de la ducha, que a un concepto claramente entendido y dominado por todos.

Ágil según la propuesta de Alistair Cockburn (uno de los firmantes del Manifiesto Ágil) podría resumirse en 4 pilares (que él denomina el Corazon de Ágil - https://heartofagile.com ), todos trabajando a la vez, ninguno más importante que otro, complementándose y ayudándose:

• Entrega de Valor (entiéndase como lo que el cliente quiere y con calidad)
• Reflexión (Inspección y Adaptación)
• Mejora Continua
• Colaboración

Corazón de Ágil por Alistair Cockburn (2)

Cuando alguno de estos elementos falta o está mal concebido, lo que llamamos ágil, apesta y generará más problemas que soluciones.

A continuación te comparto un breve listado que he identificado cuándo Ágil Apesta y mucho.

Ágil apesta cuando:

• Exógenas a los equipos ágiles
• cuando es contratado con alcance tiempo y costo fijo (clic aquí)
• la PMO hace seguimiento tradicional a un enfoque ágil 
• a la empresa no le gusta la transparencia y "mata" al mensajero que trae las malas noticias, de que las cosas no funcionan
• la empresa dice que no necesita acompañamiento y cree que con dos días de entrenamiento de sus gerentes de proyecto es suficiente
• la empresa cree que es solo ponerle a los Gerentes de proyecto el rol de Scrum Masters, y a los Business Analyst el rol de Product Owners.
• la empresa cree que será ágil en 3 meses y exige un plan para hacerlo 
• cuando la alta dirección no está involucrada y delega el cambio 
• a las personas les siguen diciendo recursos 
• no se exige excelencia técnica, ni internamente ni a proveedores
• no se remueve la deuda técnica.
• tenemos a los equipos bajo presión y les imponemos lo que deben entregar y cuándo deben hacerlo 
• cuando creemos que sabemos más que el Agile Coach o el Scrum Master con experiencia y no se siguen sus recomendaciones
• cuando no dejamos madurar los pilotos ágiles (al parecer 6 meses es una buena métrica para empezar)
• Cuando mi jefe dice que es ágil pero no le puedo dar feedback, ni le puedo sugerir cosas.
• Endógenas a equipos ágiles
• no se entrega valor al cliente de forma temprana y continua
• no existe excelencia técnica 
• el alcance está fijo 
• no se reflexiona, es decir, no se hace inspección y adaptación.
• cuando tienes soluciones ahogadas en deuda técnica
• cuando no usas DevOps
• cuando la mejora continua se enfoca únicamente en los procesos y las personas y no se enfoca en resolver los problemas técnicos (clic aquí)
• Endógenas a Scrum 
• el 50% de los equipos Scrum apestan (se lo vi decir a Jeff Sutherland, pues no son capaces de generar valor y de lograr un desempeño del 400% - promesa cumplida por Scrum una y otra vez) 
• las historias de usuario demoran dos o más sprints en ser construidas y nos olvidamos que a lo sumo deben tomarnos entre 2 a 4 días en construirse totalmente, es decir, con pruebas y despliegue incluido.
• se tienen Scrum Masters (SM) con 3 equipos (lo mejor, es un SM por equipo, lo menos peor es un SM con 2 equipos, la pésima práctica un SM con 3 o más equipos, pues no alcanza a mejorar nada, solo corre de un lado para otro haciendo reuniones) 
• se tienen Product Owners con 2 equipos (la verdad, debería ser a lo sumo uno solo, 2 es demasiado riesgoso, y le resta foco en el producto que construye) 
• el SM solo se dedica a agendar reuniones 
• cuando el PO no va a los eventos
•  el PO no hace refinamiento y se convierte en un PO reactivo que solo trabaja para el siguiente sprint, debiendo estar avanzando en 2 a 3 sprints adelante
• el SM no enseña Scrum al PO o al Equipo y como hacerlo cada vez mejor
• el PO no se deja enseñar por el SM
• cuando creemos que 5 sprints mejorarán técnicamente a un equipo de inexpertos (nunca pasará)
• no hay retrospectivas, porque no agregan valor
• las retrospectivas no abordan temas técnicos (clic aquí)
• no hay dailys 
• no hay planning, solo trabajo impuesto a realizar por el equipo de forma cíclica
• tienes un equipo con varios proyectos (multitasking) y lo llamas equipo 
• existen equipos que los llaman células y son unicelulares (equipos de una persona - OMG, lo he visto varias veces)
• las pruebas son hechas por otro equipo diferente al que construye el producto, y en el sprint subsiguiente (casca-agile)
• el equipo no es multidisciplinario 
• el Product Backlog no está priorizado por valor 
• existe un product Backlog con un solo release y un MVP, o sea, sino se sale a producción con todo el sistema o producto, este no sirve 
• el PO no tiene autoridad sobre el producto 
• el PO es el jefe del equipo y no se le puede dar feedback 
• el SM es el jefe del equipo y no se le puede dar feedback 
• dentro del equipo hay subequipos 
• no existe incremento de valor potencialmente entregable al final de cada sprint
• dentro del equipo hay rangos y jerarquías (cosa que va en contra de la guía de Scrum)
• ni el SM, ni el PO, y el Team son orientados a resultados
• el SM no reta al equipo, ni le ayuda en su proceso de mejora continua
• no hay verdaderos profesionales haciendo parte del equipo Scrum
• En la comunidad ágil
• cuando los líderes de la propia comunidad lo atacan, en vez de avanzar de forma propositiva 
• cuando las conferencias se quedan sin feedback, y la falta de validación de expertos hace que se acepte todo, que todo valga, pero la verdad no todo vale, y algunas conferencias terminan perdiendo valor. 
• cuando dejamos que otros se hagan cargo, y solo caemos en el terreno de la crítica y no construimos responsablemente 
• cuando no vemos en la crítica de los otros una oportunidad de mejora 
• cuando dejamos que los líderes tóxicos prosperen y no compartimos los éxitos y las buenas prácticas
• cuando criticamos los eventos y los speakers, pero no vamos, ni nos proponemos como speakers
• cuando alguien que recibe un entrenamiento de 2 a 4 días es nombrado Master, Consultant, Coach y no hay validación de la práctica. 
• cuando quienes toman los entrenamientos creen que pueden dictarlo al día después 
• cuando como miembro un equipo ágil dejas de estudiar y aprender y buscar tu propia excelencia y reinvención.
• cuando no te conectas con la comunidad
• cuando es más importante la foto y llenar las redes sociales del entrenamiento, que la generacion de valor en el cliente y en el equipo
• cuando nos atacamos en vez de construir 
• cuando los que no entienden los marcos ágiles
• los critican sin conocerlos o haberlos usado
• cuando critican la forma (ej: los posit o dinámicas), pero no validan el fondo
• juzgan por las fotos, pero realmente no saben toda la movilización y cambios que están ocurriendo al interior del equipo o de la organización
• cuando los que creen entender los marcos ágiles
• empapelan de posit a la organización pero no generan valor 
• leen un libro o un post salen a vender entrenamientos sin entender, comprender y validar lo leído 
• instalan Jira pero no generan valor
• tienen un pipeline de DevOps pero el negocio no prioriza por valor, ni valida las hipótesis de los incrementos o releases que va lanzando al mercado, haciendo desperdicio ágil.
• confunden felicidad con esoterismo o chamanismo 
• confunden compromiso con explotación 
• comparten información que no está respaldada por datos o experiencias (al menos propias)
• ponen primero la felicidad que la generación de valor, el mensaje es diferente, los equipos felices o que tienen bienestar son más productivos.(https://hbr.org/2011/06/the-happiness-dividend) (aporte de Fabian Schwartz)
• comparten jubilosamente fracasos ágiles, pero no comparten el contexto y se les olvida que en cascada el factor de falla es mucho más alto. Pero para ser claros, es muy probable que dentro de las causa raíz de esos fracasos se encuentren algunos de los elementos enunciados en este post.  
• cuando cualquiera del ecosistema ágil, personas como usted o como yo, no elevamos o exigimos el estándar, no compartimos el riesgo o consecuencias de las malas implementaciones y somos complacientes con esas personas que desde su paradigma no lo entienden, o desde su esquema de poder no quieren que sea exitoso, y permitimos el FrAgile, Anti-frágil, FrÁgil, o Ágil Flácido.

Bien dice Sutherland, el peor enemigo de Scrum es un mal Scrum

Referencia (3)

parafraseánndolo un poco,

El peor enemigo de Ágil es un mal Ágil o si lo desean El peor enemigo de Agile es un mal Agile o también Agile's worst enemy is a bad Agile

Hagámonos cargo 

• No llamemos Ágil a lo que no lo es.
• No llamemos Scrum a lo que no lo es.
• Exijamos excelencia técnica de los equipos de desarrollo (tanto internos como de proveedores)
• Midamos y ataquemos la deuda técnica
• Si vamos a criticar un marco o framework ágil, hagámoslo desde la experiencia o desde el minucioso estudio.
• Valida lo que dice el autor, o entrenador que te acompaña, pídele datos y referencias.
• En las redes sociales no promuevas gente tóxica, por la razón que: "de vez en cuando dice algo bueno", pues terminarás aprobando su discurso tóxico, poco constructivo y poco empoderado.
• No confundas posición crítica, con una posición tóxica, la primera llama a la acción, la segunda destila veneno, señala lo malo y no propone acciones. 
• Hazte acompañar de expertos.
• Si vas a hacer Scrum al menos sigue la guía oficial de Scrum (el SBOK no es Scrum) 
• No caigas en el "borregismo", es decir, seguir a alguien sin objetar lo que dice (como borregos, o un cardúmen), todos erramos y todos tenemos oportunidades de mejora 
• Criticas porque otros critican, pero no compruebas nada de lo que afirman
• No te quedes con lo que te dicen, investiga, valida, busca datos
• Ten una actitud de continuo aprendizaje
• No seas complaciente con el FrAgile, Anti-frágil, FrÁgil, o Ágil Flácido, identifica disfunciones, corrígelas y exígelas.

Hasta acá este desahogo o diatriba.

Vamos juntos, vamos por más.

Bienvenidos sus comentarios y observaciones.

Saludos ágiles

Jorge Abad

Aclaraciones, Comentarios, Referencias y Notas 

1. links que apoyan esta afirmación
• Las noticias positivas están pidiendo primera plana
• Efecto de las malas noticias en el cerebro humano
• Consumer Demand for Cynical and Negative News Frames - Marc Trussler, Stuart Soroka, 2014
• ¿Por qué las malas noticias abundan más en los medios de comunicación?
• Psychology: Why bad news dominates the headlines
2. https://heartofagile.com/
3. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/

Antipatrón: Decirle historia de usuario a lo que no lo es

Que las historias de usuario sean de formato libre, no implica que todo requerimiento sea una historia de usuario.

Es en serio, “las historias de usuario tienen que ser pequeñas”. (ver más - aquí - )

Un buen tip: Que tome máximo 3 días de desarrollo, pruebas y despliegue.