lunes, abril 06, 2020

La Guía de Scrum 2017 - En Mapa Mental

Hola a todos

La Guía de Scrum, la oficial, la publicada en https://scrumguides.org/, y en su versión en español para suramérica en 2017 https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf  traducida por mi estimado amigo Lucho Salazar, es un trabajo de sus creadores Jeff Sutherland y Ken Schawber de más de 20 años sobre ella.

Es bastante rica en conceptos, prácticas y sugerencias, fuera de ser muy, pero muy resumida.

Muchas veces al hacer una lectura de la misma, no somos conscientes de la cantidad de información allí depositada, y como nos pasa a muchos, cada vez que vamos a buscar un concepto, nos encontramos con perlas ocultas a nuestros antiguos ojos desprevenidos (los ojos del pasado) o tal vez sin el conocimiento para entender lo allí descrito, (me decía mi amiga Paola Becerra,  el ojo ve lo que es capaz de interpretar).

Bueno, con el fin de decodificar un poco la guía, me he animado a ponerla en formato de mapa mental.


Mapa Mental - Capítulos
Mapa Mental - Capítulos y Subcapítulos
El ejercicio no fue muy estricto desde las recomendaciones para crear mapas mentales, pero si con miras a ubicar fácilmente conocimiento clave.


Mapa Mental Completo - (lo sé, no se ve nada, pero es para que te hagas una idea de lo extenso del mapa)

De igual forma, he marcado en color verde y con (*) el texto relevante o las perlas ocultas a mis ojos del pasado.


Descárgalo y Úsalo

A continuación, pongo a su disposición varios formatos de descarga y visualización


Espero que esta decodificación les sea tan útil como lo fue para mí, en este entendimiento y reestudio de la guía.

Disfruten las perlas (las que estan con asterisco (*) y en verde)

Saludos ágiles

Jorge Abad

sábado, abril 04, 2020

Conversaciones del Scrum Master según la Madurez del Equipo


Hola a todos

Dentro de las charlas y acompañamientos que realizo a Scrum Masters y Agile Coaches, noto que muchos no conocen lo que se llama el liderazgo situacional, este fue propuesto por Hersey y Blanchard, y en el se explica que de acuerdo a la madurez del equipo, es la forma de delegar y empoderar  del lider (recomiendo ver (1)).

El Scrum Master es un lider servicial, que va llevando al equipo de desarrollo a ser cada vez mejor y más autoorganizado, para ser exactos la guía reza, en la parte del Scrum Master al servcio del equipo de Desarrollo, este debe  

"Guiar al Equipo de Desarrollo en ser autoorganizado y multifuncional" (2)

Por lo tanto, según la madurez del equipo se darán diferentes conversaciones que los Scrum Masters tendrán con sus equipos, a continuación un ejemplo:
  • Equipo en Formación - Conversación tipo: Comando y Control
    • "-Para que nos vaya mejor con los reportes de seguimiento que nos están pidiendo, vamos a dejar registro de la cantidad de horas que nos estamos gastando logrando una aprobación. ¿Quién se hace cargo? o sino, lo asigno."
  • Equipo en Conflicto - Conversación tipo: Persuación
    • "- ¿Les parece si revisan el log de transacciones?"
  • Equipo en Normalización - Conversación tipo: Participación
    • "-Yo he estado observando que hemos estado siendo más laxos con las pruebas no funcionales, ¿ustedes que piensan?
  • Equipo en Desempeño - Conversación tipo: Delegación
    • "-¿Qué creen que está sucediendo para que el desempeño de nuestro equipo no esté mejorando los últimos tres sprints?

Respecto a la Caducidad del Scrum Master

Ahora, en esa misma dirección, por lo general una pregunta asociada a este tipo de conversaciones es:
¿El Scrum Master caduca, o deja de ser necesario?
Es como si se afirmara,
como el equipo de fútbol llegó a ser campeón, ya no necesita director técnico
Obviamente, la respuesta es ¡No!, pues entre más maduro el equipo - aunque este requiere menos esfuerzo de facilitación-  las conversaciones cambian y están más ligadas al alto desempeño, y muy similares a las presentada en: Equipo en Desempeño - Conversación tipo: Delegación.

Para cerrar te comparto algo que me ha mostrado la experiencia,
  • En la mayoría de los equipos en los que el Scrum Master ha sido removido, desaparece la retrospectiva y por ende la mejora continua
Saludos Ágiles

Jorge Abad



Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. Como enseñando a montar en bicicleta - Cómo llevar a tu equipo a la autoorganización - clic aquí -
  2. Guía oficial de Scrum- https://scrumguides.org/
  3. Comenzando con un equipo en Scrum: Parte 2 - Ciclo de vida de los equipos - clic aquí-
  4. Las Preguntas Poderosas como Herramientas para Generar Autoorganización y Autogéstión - clic aquí -.
  5. Lecturas recomendadas:
    • La caducidad del Scrum Master… y por extrapolación del coach ágil - clic aquí-.
    • El objetivo de Scrum Master, NO PUEDE SER, dejar de ser necesario para el equipo - clic aquí -.




Sketch - Explicación de Scrum

Hola a todos

les comparto este boceto que realicé hace poco explicando el marco de Scrum





les comparto este boceto que realicé hace poco explicando el marco de Scrum


También puedes descargarlo en png de alta resolución del siguiente link - clic acá- .

Saludos ágiles

Jorge Abad

lunes, marzo 30, 2020

De colección: What’s the difference between Scrum and Agile? by Jeff Sutherland

Source: https://www.quora.com/What-s-the-difference-between-Scrum-and-Agile/answer/Jeff-Sutherland-1?srid=hJUg


At the Agile Manifeso Meeting in 2001 we wrote a set of 4 values backed up by a dozen principles. This is Agile.
There were 3 experts on Scrum present and 4 founders of eXtreme Programming. These were the only two widely deployed processes. They are related because the founders of both processes were communicating in the internet newsgroups as they were formed and reusing ideas from one another as early as 1994.
The other experts at the meeting had written books and papers on more adaptive and flexible development processes to replace the Rational Unified Process which was dominant at the time in software, but too heavyweight.
So Scrum and XP are the parents of Agile which is not a framework or an operational implementation. The operational implementation of Agile in over 80% of teams today is some variant of Scrum. The fastest teams implement XP practices inside the Scrum.
An extremely important XP practice implemented in the first Scrum teams is continuous integration and deployment at least once a sprint if not more often. The DevOps movement has evolved to promote this practice which was part of the original Scrum and XP teams.
Over 50% of “Agile” teams cannot deliver at the end of a sprint and are late, over budget, with unhappy customers according to Standish Group data on hundreds of thousands of projects. So beware of fake Agile.





Traducción



En la reunión del Manifiesto Ágil en 2001, escribimos un conjunto de 4 valores respaldados por una docena de principios. Esto es ágil

Hubo 3 expertos en Scrum presente y 4 fundadores de eXtreme Programming. Estos fueron los únicos dos procesos ampliamente implementados. Están relacionados porque los fundadores de ambos procesos se comunicaban en los grupos de noticias de Internet a medida que se formaban y reutilizaban ideas el uno del otro ya en 1994.

Los otros expertos en la reunión habían escrito libros y documentos sobre procesos de desarrollo más adaptables y flexibles para reemplazar el Proceso Racional Unificado (Rational Unified Process - RUP) que era dominante en ese momento en software, pero demasiado pesado.

Entonces Scrum y XP son los padres de Agile, que no es un marco o una implementación operativa. La implementación operativa de Agile en más del 80% de los equipos de hoy es una variante de Scrum. Los equipos más rápidos implementan prácticas XP dentro del Scrum.

Una práctica de XP extremadamente importante implementada en los primeros equipos Scrum es la integración y el despliegue continuos al menos una vez por sprint, si no con mayor frecuencia. El movimiento DevOps ha evolucionado para promover esta práctica que formaba parte de los equipos originales de Scrum y XP.

Más del 50% de los equipos "ágiles" no pueden entregar al final de un sprint y llegan tarde, por encima del presupuesto, con clientes insatisfechos según los datos del Grupo Standish en cientos de miles de proyectos. Así que ten cuidado con el falso Agile.


domingo, marzo 29, 2020

Product Owner's Views - Explicación

Hola a todos

Generalmente vemos al Dueño de Producto (Product Owner - PO ) trabajando en dos frentes, en el frente de la definición del producto y en el frente de la construcción del mismo, por medio de este artículo quiero compartir que la visual del PO debe considerar tres frentes(1)(2) para realizar una correcta construcción del producto.
  • Vista 1 - Descubrimiento (Discovery):
    • En este frente el PO trabaja con el Equipo del Producto (Product Team), que puede estar compuesto por:
      • expertos del negocio
      • arquitectos de software y arquitectos empresariales
      • Expertos en UX / UI
      • clientes
      • posibles suarios
      • expertos en Seguridad y Riesgos
      • expertos en Procesos
      • gerentes de Producto (Product Managers
      • otros PO e interesados claves
    • Para definir:
      • el producto,
      • la visión del producto
      • la lista ordenada del producto (Product Backlog)
      • el producto minimo viable (Minimum Viable Product - MVP
      • las versiones, 
      • los prototípos,
      • los indicadores,
      • los esquemas de ROI
      • las hipótesis, etc.
    • Para esto se vale de:
      • visitas a clientes y usuarios
      • conocer donde va a ser usado el producto (gemba walks)
      • investigaciones de mercado
      • análisis de la compentencia (benchmarks)
      • estrategias de construcción del producto
      • dependencia de otros productos o soluciones, etc.
  • Vista 2 - Desarrollo (Development): 
    • En esta vista el PO proporciona y explica del Product Backlog priorizado y refinado al Equipo de Desarrollo (Development Team) para que el producto sea creado según su conocimiento y capacidades, y basado en los lineamientos del Equipo del Producto.
  • Vista 3 - Producción (Production): 
    • En esta vista el PO observa si el producto esta siendo usado según las expectativas para las que fue creado y valida la generación de valor del mismo.
De cada uno de estos frentes el Product Owner obtiene valiosa retroalimentación sobre el Producto que debe considerar y balancear de acuerdo a los tiempos y propósitos que tenga identificados con las versiones a liberar; estas retroalimentaciones le sirven para generar una próxima mejor versión y por ende un mejor producto, estas son:
  • Retroalimentación 1 (Feedback 1) del ambiente producción y los usuarios, al Equipo de Desarrollo:
    • Uso del producto
      • funcionalidades más usadas
      • funcionalidades menos usadas
      • estadisticas basadas en uso
      • hipótesis que funcionaron y las que no
      • Funcionamiento del producto
      • incidentes y bugs a ser priorizados
      • problemas de rendimiento y funcionamiento
      • estadisticas de desempeño
      • problemas de seguridad
      • deuda técnica identificada y que debe ser priorizada
  • Retroalimentación 2 (Feedback 2) del Equipo de Desarrollo al Equipo del Producto. 
    • El equipo de desarrollo comienza a conocer tanto el producto, que se convierte en otro interesado clave (key stakeholder), proporcionando información para la construcción del mismo. Dentro de la retroalimentación brindada pueden estar las siguientes:
      • funcionalidades innecesarias
      • funcionalidades a adicionar
      • estrategias de implementación
      • deuda técnica identificada a ser priorizada
      • incidentes y bugs a ser priorizados
      • retos técnicos
      • estimaciones
      • nuevas dependencias técnicas
      • nuevas dependencias funcionales con otros productos o equipos de trabajo
  • Retroalimentación 3 (Feedback 3) del ambiente de producción y los usuarios al Equipo del Producto:
    • Uso del producto
      • funcionalidades más usadas
      • funcionalidades menos usadas
      • estadisticas basadas en uso
      • hipótesis que funcionaron y las que no
      • valor o ROI generado vs. el esperado
      • datos que se obtienen de la validación de hipótesis
    • Funcionamiento del producto
      • incidentes y bugs a ser priorizados
      • estadisticas de desempeño
      • problemas de seguridad identificados
      • problemas de experiencia de usuario identificados
      • deuda técnica identificada y que debe ser priorizada
      • estadísticas basadas en experiencia de usuario

Bienvenidos sus comentarios

Saludos ágiles
Jorge Abad


Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. El análisis acá presentado esta pensado está formulado para productos basados en software, para otro tipo de productos se sugiere realizar análisis similar y reemplazar roles, actividades y fuentes según sea la industria de solución.
  2. Este diagrama fue resultado del análisis del dual-track, algunas interesantes referencias a continuación:
  3. Gracias a mis amigos Jaime Icaza y Daniel Ramirez por sus valiosos comentarios para mejorar este artículo.


domingo, marzo 22, 2020

Reflexión; Un líder no es una víctima



Un líder no es una víctima, es alguien que desde su contexto busca y crea un entorno mejor para quienes lidera y para él/ella.

lunes, marzo 16, 2020

Algunas ideas sobre cultura



La cultura de una organización se conoce por la forma en que trata a sus proveedores.




Los valores y los principios son el mantra que se debe repetir a todo nivel dentro de la organización.




Cuando los procesos no están legislando sobre un determinado aspecto, los principios y valores lo harán.




Los líderes deben reforzar constantemente el conocimiento, difusión, y uso de los valores y principios de la organización.



Las organizaciones que maltratan, discriminan, o segregan a sus proveedores poseen culturas tóxicas.




Para elevar el estándar cultural de una organización el líder debe empoderar a los demás para exigir el cumplimiento de los principios y valores.




La cultura dentro de una organización o grupo de trabajo es la promovida y exhibida por los líderes.




La mejor forma de liderar una cultura es hacerlo con el ejemplo.




El líder debe incentivar y promover todo comportamiento que vaya en pro de la cultura, principios y valores de la organizaición.




El líder debe desestimular todo comportamiento que vaya en contra de la cultura, principios y valores de la organización.




Los procesos reales, es decir, como realmente la organización interactúa para generar valor, son el fiel reflejo de la cultura, principios y valores que tiene la organización, sin importar si estos han sido o no declarados, o si fueron o no documentados de forma correcta o incorrecta.

La forma como interactuamos gobierna sobre lo que esta escrito o declarado. .




"La cultura de cualquier organización está determinada por el mejor comportamiento que el líder está dispuesto a amplificar en su equipo de trabajo y toda la red de personas a cargo"(2)




"La cultura de cualquier organización está determinada por el peor comportamiento que el líder está dispuesto a tolerar en su equipo de trabajo y toda la red de personas a cargo"(2)





Los líderes promueven la cultura dentro de una organización, ya sea de forma consciente o inconsciente.
Corolario 1: Las personas a cargo del líder generalmente copiarán los comportamientos del líder independientemente de lo que diga o hace, pues imitar su comportamiento los "llevará a ser como él/ella y a tener su mismo poder", similar como los hijos copian a sus padres (consciente o incosncientemente).






Referencias

  1. Las referencias de este post se basan en muchas experiencias, lecturas y conversaciones, no es mi intención no dar crédito, es más el compartir comportamientos observados para que todos hagamos uso de ellos. Si alguien conoce la cita explícita, no dude en compartirmela, con gusto actualizaré el artículo.
  2. Antipatrón: Solo liderar la primera línea y no gestionar la red - http://www.lecciones-aprendidas.info/2019/08/antipatron-solo-liderar-la-primera-linea-y-no-gestionar-la-red.html

domingo, marzo 15, 2020

Frase: Alfredo Di Stéfano - Ningun Jugador es tan bueno como todos juntos





"Ningún jugador es tan bueno como todos juntos"

Alfredo Di Stéfano (1926-2014)




Resultado de imagen para ningun jugador es tan bueno como todos juntos

Reflexión: Empático mas no complaciente

tomado de (4)

En estos tiempos de VUCA (1) todos los líderes somos agentes de cambio, buscamos como generar valor mientras respondemos a un entorno cambiante. Es necesario entender que nuestras organizaciones (y las que estamos interviniendo) llegaron hasta donde están debido a las estrategias tradicionales, pero estas estrategias cada vez son menos eficientes.

Es necesario que todo líder, presidente, vicepresidente, director, gerente, gerente de proyectos, scrum master, agile coach sea:

Empático mas no complaciente

Empático, desde el punto de vista que comprende los paradigmas desde los cuales están ubicadas las personas de su entorno, cuales son los motivadores de sus decisiones, cuales son los elementos de juicio usados por ellos, siendo amable, condescendiente temporalmente, comprendiendo, hasta disculpando actitudes que no son exitosas actualmente tales como:
  • planeaciones rígidas, donde es requerido planeaciones adaptativas
  • gestión comando-control, donde es requerido un liderazgo servicial
  • documentación extensiva, cuando lo que se requiere es interacción entre los involucrados
  • uso excesivo de la comunicación jerárquica
  • procesos rígidos que rara vez son actualizados y no reflejan la forma de trabajo
  • y así muchos más casos
y No Complaciente (o Retador), aunque entiende el contexto, traza rutas cortas o a mediano plazo hacia entornos más adaptativos, siendo constructor de puentes, tales como:
  • generando procesos intermedios que luego retarán para que sean más Lean-Agile (2)
  • enseñando a otros como liderar el cambio desde el liderazgo servicial o liderazgo situacional
  • creando experimentos que demuestren como hacer mejor las cosas
  • proporcionando datos y hechos de que los paradigmas actuales deben ser cambiados
  • proporcionando datos y hechos de que los paradigmas adaptativos (lean-agile) generan valor más rápido y con menos costo en su entorno
  • retando a todos a su alrededor, generando un paradigma de mentalidad de crecimiento dejando atrás la mentalidad fija de procesos y formas establecidos
  • liderando con el ejemplo
  • haciendo de la mejora continua un hábito a enseñar a los demás
  • buscando como hacer a las organizaciones y equipos más adaptativos y colaboradores
  • usando herramientas del paradigma tradicional para comunicar expectativas, pero retando la búsqueda de mejores herramientas (3)
  • comunicando y demostrando constantemente que la generación de valor hacia el cliente final es más importante que la excelencia operativa de un area funcional

Hasta acá este corto compartir, bienvenidos sus comentarios.

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-Agile
    • 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
    • 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.
  3. Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales (http://www.lecciones-aprendidas.info/2019/09/como-evitar-la-ingenuidad-agil.html)
  4. Vector de Negocios creado por freepik - www.freepik.es

martes, marzo 10, 2020

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.