Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded

Hablemos de Deuda Técnica - El mal que puede acabar tu proyecto-producto ágil - Reloaded from Jorge Hernán Abad Londoño

DevOps sin Gestión por Valor También es Desperdicio

Podemos tener el mejor Pipeline de DevOps, pero si no existe: Priorización de Portafolio  Priorización de Product Backlog y validación de hipótesis a nivel de iniciativas y épicas. Seguiremos generando desperdicio y perdiendo costo de oportunidad.

---

Podemos tener el mejor Pipeline de DevOps, pero si no existe:
- Priorización de Portafolio
- Priorización de Product backlog
- y validación de hipotesis a nivel de iniciativas y épicas.

Seguimos generando desperdicio, y perdiendo costo de oportunidad.

— Jorge Hernán Abad L. (@jorge_abad) May 15, 2019

---

We could have the best DevOps Pipeline, but if it does not exist:
- Prioritization of Portfolio
- Prioritization of Product Backlog
- and hypotheses validation at level of initiatives and epics.
We will continue generating waste and losing opportunity cost. #Agile #DevOps

— Jorge Hernán Abad L. (@jorge_abad) May 15, 2019

---

Modos de Representación de las Historias de Usuario - Un Capítulo del Libro Historias de Usuario una Visión Pragmática

Hola a todos

En el pasado ScrumDay en Perú 2019, mi estimado compañero y amigo Lucho Salazar tuvo la oportunidad de presentar un poco sobre nuestra experiencia y visión sobre las historias de usuario en la charla: "Historias de usuario: todo lo que querías saber y no te atreviste a preguntar", la cual resumía algunos de los aspectos plasmados en el Libro "Historias de Usuario: Una Visión Pragmática" que publicamos en el pasado Ágiles 2018 en México. En esta presentación se toco uno de los temas que hemos observado que más genera polémica y es los diferentes modos de representación, todos creemos que el

"yo como usuario 

deseo esta funcionalidad 

para este beneficio"

es el estándar y no, no lo es, es solo una propuesta de formato hecha por Mike Cohn, en últimas lo que recomiendan muchos expertos, autores, al igual que nosotros es:

"cualquier modo de escribir o representar las Historias de Usuario sirve, siempre y cuando el Product Owner y el Equipo de Trabajo tengan la misma imagen mental de lo que se está requiriendo construir."(1)

Dentro de estos modos de representación Lucho y yo hemos identificado cinco modos de hacerlo, los cuales pueden ser usados de acuerdo al a madurez del Equipo y del Product Owner y del contexto en que se encuentren. A continuación presentamos un ejemplo desarrollado en el libro, y que sirve como base para esta explicación:

---

---

---

---

---

---

---

Aprovecho esta oportunidad para invitarlos a compartir su conocimiento y experiencias, de esa manera todos creceremos más.


Como siempre, bienvenida la retroalimentación.

Saludos Ágiles

Jorge Abad y Lucho Salazar

Notas, Aclaraciones, Comentarios y Referencias

1. La representación de Historias de Usuario no exime de cumplir las 3 Cs, el criterio Invest y muchas prácticas recomendadas en el libro y los post de Lucho y míos sobre este tópico:
• http://www.lecciones-aprendidas.info/search/label/Historias%20de%20Usuario
• http://www.gazafatonarioit.com/search/label/historias%20de%20usuario

Propuesta de preguntas para la reunión de Scrum de Scrums (Scrum of Scrums)

Hola a todos

A continuación les presentamos unas recomendaciones para una buena reunión de Scrum de Scrums (Scrum of Scrums), o de sincronización de varios equipos ágiles que están trabajando con un mismo Product Backlog o Iniciativa.

Este post fue redactado conjuntamente con mis compañeros:

• Augusto Miní
• Lucho Salazar
• Ricardo Cruz

Ahora sí al grano:


Frecuencia

• Al menos una vez a la semana, 
• Deseable diariamente.

Timebox

• 15 a 30 Minutos

Preguntas

• ¿Existieron problemas en la integración del código y en las pruebas integrales del producto el día anterior?
• ¿Qué impedimentos tienen que debamos gestionar a nivel de equipos? *
• ¿Qué dependencias o riesgos tienen o estan próximos a activarse?
• ¿que información consideran que debe ser compartida con todos los equipos?
• ¿Creen que van a bloquear a alguien?
• ¿Alguna mejora encontrada que deba ser compartida con todos los equipos?
• ¿Alguna ayuda adicional que requieran?
• ¿Pueden ofrecer ayuda?

*Nota: los impedimentos, bloqueos y riesgos que se presenten a este nivel corresponden al programa entero, no deben ser presentados los que corresponden al equipo y al ámbito del Scrum master.

Recomendaciones
Estas preguntas deben tener la misma dinámica del daily:

• Solo se expone lo que se está preguntando.
• El facilitador debe generar este foco 
• Luego, en una reunión inmediatamente después (o Meet After) de este Daily de Scrum de Scrums, se resolverán los elementos factibles a resolver
• Se sugiere que los elementos que no puedan ser resueltos se plasmen en un kanban impedimentos y riesgos del programa, con responsable y/o responsables asignados.

Saludos ágiles
Jorge Abad

Referencias, Notas, Aclaraciónes y Comentarios

1) Scrum de Scrums en SAFe  - https://www.scaledagileframework.com/program-increment/

2) Scrum de Scrums en Nexus - https://www.scrum.org/resources/nexus-guide 

• ¿El trabajo del día anterior fue integrado exitosamente? Si no fue así, ¿por qué no? 
• ¿Cuáles nuevas dependencias han sido identificadas? 
• ¿Qué información necesita compartirse entre los equipos del Nexus? 

3) Scrum de Scrums en Scrum at Scale - Scrum@Scale - https://www.scrumatscale.com/scrum-at-scale-guide-read-online/

• What impediments does my team have that will prevent them from accomplishing their Sprint Goal (or impact the upcoming release)?
• Is my team doing anything that will prevent another team from accomplishing their Sprint Goal (or impact their upcoming release)?
• Have we discovered any new dependencies between the teams or discovered a way to resolve an existing dependency?
• What improvements have we discovered that can be leveraged across teams?

Malos Olores en Transformaciones Ágiles - Bad Smells in Agile Transformations - Scrumday Perú 2019

Bad smells in agile transformations comunitaria - v20190427 from Jorge Hernán Abad Londoño

De Colección: 51 frases motivadoras para trabajar en equipo

Hola a todos

Buscando información para una presentación me encontré con esta selección de frases, realmente es una joya (la copié para que no se me perdiera la referencia):

1. “No hay reto que no podamos alcanzar trabajando unidos con claridad de los objetivos y conociendo los instrumentos”. -Carlos Slim.
2. “La fuerza está en la unidad. Con la colaboración y el trabajo en equipo es posible conseguir cosas maravillosas”. -Mattie Stepanek.
3. “Nadie puede silbar una sinfonía. Se necesita una orquesta completa para tocarla”. -HE Luccock.
4. “Este mundo no es un campo de batalla. Algún día te darás cuenta de cómo tu éxito depende de un montón de otras personas y ese día serás más sabio. Tú sabrás que todos estamos conectados. O lo hacemos todos o ninguno de nosotros lo hace”.-Jasleen Kaur Gumber.
5. “Ten presente que el destino de todos depende de la conducta de cada uno”. -Alejandro Magno.
6. “Jamás pongas en duda que un pequeño grupo de personas comprometidas pueden cambiar el mundo. En efecto, es lo único capaz de lograrlo”. -Margaret Meade.
7. “Ninguno de nosotros es tan bueno como todos nosotros juntos”. -Ray Kroc.
8. “El talento gana partidos, pero el trabajo en equipo y la inteligencia ganan campeonatos”. -Michael Jordan.
9. “Cuando las arañas tejen juntas, pueden atar a un león”.-Proverbio Etíope.
10. “La fortaleza del equipo está en cada miembro por separado. La fortaleza de cada miembro es el equipo”. -Phil Jackson.
11. “El trabajo en equipo es el secreto que hace que la gente común logre resultados increíbles”. – Ifeanyi Onuoha.
12. “El trabajo en equipo es la capacidad de trabajar juntos hacia una visión común. La capacidad de dirigir los logros individuales hacia los objetivos de la organización. Es el combustible que permite que la gente normal logre resultados poco comunes”. –Andrew Carnegie.
13. “El trabajo en equipo permite que los sueños se cumplan”. –Bang Gae.
14. “Si un equipo quiere alcanzar su potencial, cada miembro debe estar dispuesto a doblegar sus metas personales para el bien de todos”. -Bud Wilkinson.
15. “Si estamos juntos no hay nada imposible. Si estamos divididos todo fallará”. -Winston Churchill.
16. “Con un equipo lleno de entusiasmo puedes conseguir casi cualquier cosa”. -Tahir Shah.
17. “Un barco no avanza si cada uno está remando en una dirección”. – Proverbio Swahili.
18. “El espíritu de equipo es lo que da a muchas empresas una ventaja sobre sus competidores”. -George Clements.
19. “Mejor perder con el equipo adecuado que ganar con el equipo equivocado”. Ogwo David Emenike.
20. “Los cinco dedos separados son cinco unidades independientes. Ciérralos y el puño multiplica la fuerza. Ésta es la organización”. -James Cash Penney.
21. “No existe un hombre hecho a sí mismo. Alcanzarás tus metas con la ayuda de los demás”. -George Shinn.
22. “No hay equipo sin los miembros individuales; un individuo nunca puede ser un equipo”. -Michael Joling.
23. “Es mucho más gratificante llegar a la cima de la montaña y compartir tu experiencia con otros que mostrarte tu solo exhausto”. -Shandel Slaten.
24. “Solos podemos hacer muy poco; unidos podemos hacer mucho”. -Hellen Keller.
25. “Llegar juntos es el principio. Mantenerse juntos, es el progreso. Trabajar juntos es el éxito”. -Henry Ford.
26. “Trabaja en equipo. Unos inofensivos copos de nieve juntos pueden desatar una avalancha de destrucción.” – Justin Sewell.
27. “Si podéis reír juntos, podéis trabajar juntos”. – Robert Orben.
28. “Nadie puede conseguir el éxito solo”. -Ifeanyi Enoch Onuoha.
29. “Sólo llegando a estar unidos, como una sola fuerza, nos mantendremos fuertes e inconquistables”. –Chris Bradford.
30. “El ego es el asesino definitivo en un equipo”. – Patrick Lencioni.
31. “El mejor trabajo en equipo proviene de aquellos hombres que trabajan de forma independiente para conseguir una meta en conjunto”. –James Cash Penney.
32. “Tienes que ser consciente de lo que están haciendo los otros, aplaudir sus esfuerzos, reconocer sus éxitos, y animarlos en sus metas. Cuando todo el mundo se ayuda, todo el mundo gana”. – Jim Stovall.
33. “El trabajo en equipo comienza por crear confianza. La única forma de hacerlo es superar nuestra necesidad de invulnerabilidad”. –Patrick Lencioni.
34. “Construye en tu equipo un sentimiento de unidad, de dependencia de uno para el otro, de fortaleza derivada de la unidad”. -Vince Lombardi.
35. “Yo hago lo que tú no puedes, y tú haces lo que yo no puedo. Juntos podemos hacer grandes cosas”. -Madre Teresa de Calcuta.
36. “Hay que unirse, no para estar juntos, sino para hacer algo juntos”. – Donoso Cortes.
37. “Algunas veces, el mayor desafío de un jugador viene en relación con su papel en el equipo”. -Scottie Pippen.
38. “Los equipos comparten la carga y dividen el dolor”. -Doug Smith.
39. “Es increíble lo que se puede conseguir cuando a nadie le importa quién se lleva el crédito”. -Robert Yates.
40. “Es literalmente verdad que puedes tener éxito mejor y más rápido al ayudar a otros a tener éxito”. -Napoleon Hill.
41. “Un equipo es una combinación de miles de factores humanos y psicológicos encaminados hacia el mismo objetivo: La victoria”. -Manuel Gomez Brufal.
42. “No importan cuantos logros hayas conseguido, alguien te ayudó”. -Althea Gibson.
43. “No hay problema que no podamos resolver juntos, y muy pocos que podamos resolver por nosotros mismos”. -Lyndon Johnson.
44. “Invito a todos a elegir el perdón en lugar de la división, el trabajo en equipo en lugar de la ambición personal”. -Jean-Francois Cope.
45. “El talento gana juegos, pero el trabajo en equipo y la inteligencia ganan campeonatos”. -Michael Jordan.
46. “Con un equipo entusiasta se puede lograr casi cualquier cosa”. -Tahir Shah.
47. “El trabajo en equipo es el secreto que hace que la gente común logre resultados poco comunes”. -Ifeanyi Onuoha.
48. “La velocidad del jefe es la velocidad del equipo”. -Lee Iacocca.
49. “La colaboración no tiene jerarquía. El Sol colabora con el suelo para traer flores a la tierra”. -Amit Ray.
50. “Mi trabajo es hacer a todo el equipo ejecutivo lo suficientemente bueno como para que sean mis sucesores”. –Steve Jobs.

51 (Bonus) . "Si quieres ir rápido camina solo, si quieres llegar lejos ve acompañado". Proverbio Africano




Tomada de: https://gananci.com/frases-para-trabajar-en-equipo/

De colección: Un excelente tweet sobre estimación, esfuerzo y capacidad

Sea lo que sea que uses para estimar esfuerzo en equipos ágiles, que sea relativo, porque el esfuerzo fijo al igual que el costo fijo, es un engaño de nuestra necesidad de control. Estimamos para conocer nuestra capacidad, no para cumplir la estimación. #adaptation #agilemindset

— Claudia Toscano Varg (@claudytoscano) April 18, 2019

Una pequeña reflexión sobre los radares, las métricas y los modelos de madurez ágiles

A ratos veo tantos "modelos" ágiles, radares, métricas, modelos de madurez ágil para organizaciones, equipos, personas, roles, etc. que me da la sensación que terminamos pareciéndonos más CMMi, y a marcos tradicionales que a la agilidad que promulgamos. Tendemos a parametrizar todo, es nuestra inclinación innata, tratamos de generar fórmulas, y estandarizar y generar patrones.

Pero olvidamos que el "driver" principal es la generación de valor al cliente, llegarle con mejores servicios y de forma temprana y continua; los radares, las métricas, los modelos de madurez son secundarios.

Las únicas métricas importantes en todo esto son: si generamos valor y si estamos sobreviviendo en el mercado, el resto es informativo.

El Equipo Oculto de Scrum: El Equipo del Product Owner o Equipo del Producto

Hola a todos

Este corresponde a uno de esos post que tengo en mi lista de pendientes que por fin salen a la luz después de presionarme internamente una y otra vez por ser escritos.

Definitivamente el título del artículo es el "spoiler", pero aunque saben para donde voy, vamos a conocer las razones de esta afirmación.

Un Product Owner con Pleno Conocimiento

En primer lugar, tenemos equipos scrum, con esquemas muy simples de trabajo donde el Product Owner (PO), es alguien que tiene todo el conocimiento sobre el producto y le es fácil tomar decisiones sobre lo que se esta construyendo.

Desde mi punto de vista esta es la configuración más simple pero muy escasa, principalmente en espacios corporativos, pues muchas veces para diseñar un Producto un PO debe interactuar con muchos interesados; y eso nos lleva a la siguiente configuración.

Un PO Interactuando un Grupo de Interesados

En este caso el PO, posible que tenga conocimiento de una parte del universo del problema pero requiere de áreas adicionales para diseñar el producto correcto.

En este caso, cada una de esas áreas proporciona conocimiento y decisiones claves sobre el mismo, y le ayuda a entender al PO, como gestionar las dependencias, y diseñar estrategias para hacer exitosa la construcción del producto.

El Equipo del Producto

Bajo el contexto anterior en la medida que los productos son más complejos, los PO deben interactuar con más áreas y esas áreas son de contacto frecuente, adicionalmente estas terminan volviéndose lo que en muchos entornos se denomina "El Equipo del Producto".

Este Equipo del producto, debido al rol que desempeñan se podrían definir como son un grupo de personas que  proporcionan información estratégica, táctica, operativa y técnica sobre el producto y que debe ser considerada para la elaboración y refinamiento del Product Backlog.

Este Equipo del producto,es muy probable que:

• sea con el que se realice el Inception y el continuo refinamiento del producto
• tenga un ciclo de reuniones para hablar sobre el producto, su presente y futuro.
• algunos de sus integrantes hagan parte de los stakeholders a los cuales después de cada sprint se presenta incremento del producto cada sprint
• se presenten conflictos entre ellos, pues donde donde hay restricciones y diferentes intereses, lo más natural es que aparezca el conflicto
• tengan necesidades de un facilitador, es decir,  de alguien que les ayude a coordinarse, resolver sus conflictos para no perder su foco. 

El Equipo del Producto ¿Es realmente un equipo?

Lo cierto, es que este Equipo del Producto permanece oculto a la vista de todos, pero es frecuente escuchar por parte del PO, del SM y hasta del Equipo de Desarrollo, quejarse de problemas de:falta de coordinación

• involucramientos tardíos
• falta de compromiso
• conflicto de intereses
• entre otros

Y aunque este grupo de personas tengan un interés común, no implica que se vean como un equipo, pero esto no los exime de las necesidades de que exista un facilitador entre ellos que permita la fluencia de los diferentes temas que ellos tratan. Este rol de facilitador podría ser ejercido por:

• El Product Owner (aunque sería viable por su ubicación estratégica entre el equipo Scrum y los Stakeholders, es probable que no cuente con las habilidades de facilitación)
• El Scrum Master
• El Agile Coach del ecosistema ágil al que pertenece el producto

Este facilitador, determinará si avanza a formarlos como equipo, o los sigue gestionando como un grupo con un interés común.

Unos consejos: Al menos una Sincronización Semanal y una Retrospectiva Mensual

Ahora, sea que ellos se vean o no como equipo, es altamente recomendado:

• Ejecutar al menos una sincronización semanal para identificar avance de pendientes y necesidades de ayuda, esto podría ser apoyado por la gestión visual que proporciona un tablero kanban.  
• Realizar una retrospectiva cíclica, al menos una vez al mes que busque mejorar tanto las interacciones al interior como con el Equipo Scrum.

Estas dos dinámicas serán de gran valor y sumarán bastante a la dinámica de la construcción del producto.

Cerrando

Por último unas preguntas:

• ¿tienes un "equipo del producto"?¿realmente son un equipo?¿les interesa serlo?
• ¿ya lo identificaste?¿o justo ahora te haces consciente de el?
• ¿necesita facilitador?
• ¿podría ser el scrum master del equipo scrum?
• ¿podría ser otro scrum master?¿o un agile coach?
• ¿que cadencia de sesiones tienen?
• ¿sería útil una sicronización diaria, semanal?
• ¿sería valioso tener al menos una retrospectiva mensual para corregir problemas y lograr responder a a las necesidades del equipo scrum?

Hasta acá este compartir, bienvenido el feedback.

Saludos ágiles

Jorge Abad.

Saludos Ágiles
Jorge Abad

Entendiendo el Costo del Retraso - Cost of Delay

Hola a todos

Debido a la explicación recurrente que últimamente hago de este concepto, les comparto esta presentación que me ha ayudado bastante en este propósito

Espero les sirva tanto como a mí.

Entendiendo el Costo del Retraso - Cost of Delay from Jorge Hernán Abad Londoño

Para la comprensión rápida del ejemplo he extraído algunas unas imágenes

------

------

------

------

------

------

------

------

Saludos ágiles

Jorge Abad

Ágil Apestoso (Crappy Agile) vs Ágil de Valor: Una invitación a no perder el foco

Hola a todos

Hace unos días se suscitó en la comunidad de Ágiles Colombia (1) una interesante discusión sobre:

agile (ágil)  = output (entregables o salidas)

agility (agilidad) = outcome (resultados)

Y el punto que quiero compartir es que ágil (agile) nunca ha estado desligado de la generación de valor, ni de los resultados de negocio (outcomes), entendiendo la generación de valor como ingreso y o beneficio para quien lo construye. A continuación comparto dos interesantes definiciones de valor.

Tomado de (2)

Tomado de (3)

Adicionalmente,en el siguiente video de Henrik Kniberg, uno de los referentes en el mundo ágil presenta en el 2012 que un equipo ágil produce salidas (outputs) que deben traducirse en resultados de negocio (outcomes) para los Stakeholders



Si estas salidas que produce el equipo ágil no están orientadas a producir valor, es decir resultados de negocio, estaríamos haciendo

• iteraciones cortas (sprints) para producir desperdicio o software apestoso (en el caso de Scrum y XP) o 
• flujo continuo de software apestoso (aplica tanto para Kanban como para DevOps)

que se vería más o menos así:

No quisiera entrar en discusión si agile (ágil) o agility (agilidad) - no es mi foco en este post -, no, mi punto es que si usted no esta haciendo software de valor que:

• le genere ingresos,
• le reduzca costos,
• le mitigue riesgos o 
• le de más capacidad a su organización,

simplemente esta perdiendo el tiempo, le esta haciendo perder el tiempo a su equipo de trabajo y a su empresa  y está dándole oportunidad a su competencia que lo alcance, lo rebase o le tome más distancia; y considerando los tiempos disruptivos (4) en los que nos encontramos, estos no nos permiten darnos el lujo que antes nos solíamos dar de construir grandes soluciones para luego echarlas a la basura, ¡NO¡, hoy experimentamos rápido, fallamos barato, aprendemos rápido, inspeccionamos y adaptamos, y estamos altamente enfocados en generarle valor al negocio y en consecuencia a nuestros clientes con nuestros productos y servicios.

Mi invitación con este corto post es a que dejes de hacer Ágil Apestoso (o Crappy Agile) y comiences ha realizar Ágil de Valor, tal y como fue definido en el Manifiesto Ágil (5) y tal como lo demandan estos tiempos tan competitivos.


Saludos Ágiles

Jorge Abad

Notas:

• Un saludo especial @MauroStrione a quien recordé mientras hacía este post con su clarla "Ass Driven Organizations"
• Entiéndase que el software de valor requiere de excelencia técnica.

Comentarios, Observaciones y Referencias

1. Meetup Agiles Colombia - https://www.meetup.com/es/AgilesColombia/
2. https://www.scrum.org/resources/blog/agile-value
3. https://jeronimopalacios.com/2016/10/metricas-agiles-fundamentales-ii/ 
4. VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
5. Manifiesto Ágil - https://agilemanifesto.org/iso/es/manifesto.html
6. Software Craftmanship Manifesto - http://manifesto.softwarecraftsmanship.org/#/es

Los ANS y la agilidad

"En muchos casos los ANS (Acuerdos de Niveles de Servicio) parecen estar ahí más para destruir valor que para construirlo

Recomendación:
Vea el ANS como el peor tiempo de su servicio, no como el estándar a cumplir." pic.twitter.com/VR2RXof5wB

— Jorge Hernán Abad L. (@jorge_abad) March 14, 2019

Tweet - Cita sobre Scrum

"Scrum es un buen lugar para empezar pero es un mal lugar para quedarse" @JonKernPA #ScrumDayCo2019 pic.twitter.com/UQ6Hly7NzI

— Jorge Hernán Abad L. (@jorge_abad) March 16, 2019

Agilizando con scrumban el proceso de talent acquisition y Agilidad para Áreas de Negocio

Agilizando con scrumban el proceso de talent acquisition y Agilidad para Áreas de Negocio de Jorge Hernán Abad Londoño

Entrenamiento: Management 3.0 Workshop Details

#LesComparto el próximo entrenamiento que impartiré en Management 3.0

Cuando: Abril 11-12

Ciudad: Medellín

Link del evento https://management30.com/events/details/?id=5386

¡Están cordialmente invitados!

Hablemos de Contratos Ágiles - Reloaded

Hablemos de Contratos Ágile - (reoloaded) de Jorge Hernán Abad Londoño

La transformación digital requiere de la transformación ágil (resumen)

Imagen de la película Minority Report

Hola a todos

Llevo varios días tratando de escribir este artículo, sustentarlo con una buena cantidad de referencias reconocidas y entre más escribo más me convenzo que se parece más a un ensayo que a un pequeño artículo de fácil y corta lectura.

Pero mientras sale el "casi ensayo",  quisiera dejar evidencia de este importante asunto sobre el que quiero poner foco, pues he observado que muchas empresas quieren hacer su Transformación Digital sin a la par trabajar en su Transformación Ágil, muy seguramente la empresa no esta lista para el cambio (que no es opcional por estos días de cambio acelerado, discruptivo o VUCA) pero quiere empezar "para ayer" - como decimos en Colombia- con este cambio, que ya le esta quitando clientes o pronto se los quitará. Lo simpático es que cuando comienzan con este tipo de proyectos:

• de IoT
• en la Nube
• de BigData
• con IA
• robotics
• customer centric
• etc, 

Sus personas, cultura, mindset y procesos, aun no están listos para gestionarlos- es decir, no tienen el mindset ágil- , correspondiendo al mindset de la gestión predictiva, en el cual toda su cultura esta ubicada - y que es de reconocer, les ha dado éxito hasta el momento- generando problemas como:

• creer que es un proyecto tradicional 
• no verlo como un experimento que puede ser exitoso o fallido
• no considerar hipótesis a ser validadas
• no medir el resultado esperado
• no priorizar alcance por valor
• contratar la construcción con los parámetros de cascada
• quieren presupuesto fijo
• el alcance es fijo con requerimientos detallados
• el tiempo para la ejecución es fijo
• utilizar métricas de cascada para proyectos ágiles
• al proyecto ágil se le asignan ANS o SLA de cascada (¿¡en serio!?)
• las personas no tienen tiempo para ejecutar los roles con el involucramiento que se requiere (ej: Product Owner)
• quieren en la primera versión todo el sistema y no comprenden que es un Producto Mínimo Viable (MVP - Minumum Viable Product)
• no se acompañan de gente que tiene experiencia gestionando este tipo de proyectos
• al gerente de proyecto que no tiene experiencia, pero que hizo un "curso de Scrum Master" le entregan la misión de sacar "el proyecto" adelante.
• los procesos de aprobación de "cualquier cosa" requiere demasiadas aprobaciones y comités
• entre muchas otras cosas

Haciendo que la iniciativa "Digital" muera sin haber nacido.

Es aquí donde veo que es necesario el asesoramiento, el acompañamiento y crear las condiciones para el éxito o para el fracaso (pero que este fracaso o fallo sea rápido).

Estimad@ gerente:

"El tiempo sigue avanzando y usted sigue esperando que el proceso organizacional apruebe su proyecto digital, de forma que salga a buscar a su mejor proveedor en cascada, a decirle que haga ágil, pero con las condiciones de cascada, luego entre a negociar el alcance y las estimaciones - proceso interminable y desgastante -, perdiendo ROI y aumentando el costo del retraso de forma significativa, ¿En serio, va a seguir perdiendo mercado y costo de oportunidad, y permitiéndole a su competencia que le tome ventaja de su proceso lento? o ¿va a generar las condiciones de éxito para este piloto, que va a ser la puerta de entrada a esta nueva forma de trabajo? La decisión está en sus manos, nos vemos la próxima reunión"

Hasta áca este corto compartir

Saludos Ágiles

Jorge Abad

Algunas Referencias

1. Is Digital a Priority for Your Industry?. https://www.gartner.com/smarterwithgartner/is-digital-a-priority-for-your-industry/
2. El mundo ya cambió. https://www.youtube.com/watch?v=pPzS6gza9KQ
3. VUCA. Las siglas en inglés de Volatilidad, Incertidumbre, Complejidad, Ambigüedad. Más en https://hbr.org/2014/01/what-vuca-really-means-for-you
4. Economía Colaborativa - https://es.wikipedia.org/wiki/Consumo_colaborativo
5. Transformación digital, reto de empresas líderes globales - https://www.portafolio.co/negocios/empresas/transformacion-digital-reto-de-empresas-lideres-globales-524943
6. ¿Por qué NO DEBES contratar en Cascada un proyecto a ser desarrollado con metodologías ágiles?- http://www.lecciones-aprendidas.info/2018/11/por-que-no-contratar-en-cascada-un.html
7. Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos. http://www.lecciones-aprendidas.info/2017/08/como-elegir-el-proyecto-piloto.html

Invitación ScrumDay en Medellin Colombia - Marzo 15 y 16 de 2019

Invitación al ScrumDay a realizarse en Medellín Colombia el proximo 15 y 16 de marzo. Link del sitio - http://www.scrumday.co/ Link de la agenda - http://www.scrumday.co/#faq

[De Colección] Lo más importante de las historias de usuario no es el formato sino la esencia - Tweet de Colección

As an author of the Agile Manifesto
I want that stupid story format to go away
So that people can get to the essence of user stories.

— Ron Jeffries (@RonJeffries) April 7, 2016

Señor(a) CIO le comparto una noticia: "Su equipo le quiere despedir"

Imagen tomada de: https://unsplash.com/photos/nuvtfH-p1H8

Hola a todos

He tenido la oportunidad de conversar con agilistas(2) de varias latitudes y acentos en Latinoamérica y con frecuencia les pregunto esto:

¿Crees que el equipo de IT de esta organización en la que estas trabajando despediría a su jefe?

La mayoría de las veces la respuesta es un doloroso y rotundo

 "Sí, sin lugar a dudas"

y cuando indago las razones, encuentro expresiones como:

• No se involucra
• Nos dice: "hagan, tienen mi autorización", pero no ha entendido que su involucramiento es fundamental, cree que no estorbar es suficiente.
• No entiende la agilidad y lo que implica de parte de él (ella) y de la organización
• Cree que es solo asistir a capacitaciones
• Nos sigue midiendo en cascada, adicionalmente le gusta cumplir con lo que promete a otras áreas pero no esta centrado en el cliente, ni le importa si lo que hacemos genera o no valor para la organización.
• Quiere que seamos ágiles y colaboremos entre nosotros, pero hace que  nos relacionemos como silos que compiten entre sí.
• Quiere que seamos ágiles pero nos esta exigiendo contratar en cascada
• No entiende que la agilidad no es solo de IT y no nos está ayudando a llegar a otras áreas y vicepresidencias
• No esta predicando con el ejemplo y en su forma de interactuar y tomar decisiones sigue bajo el esquema tradicional de comando y control
• Vive en competencia con los otros CXO para ganarse el favor del CEO
• Sigue enfocado en la microgestión sin delegar en su equipo
• Habla de agilidad con todos, porque sabe que eso le va a servir para sus resultados pero no es un jugador de equipo
• Le encanta la estabilidad y no nos permite fallar y aprender, impidiendo el cambio y la verdadera innovación
• Vive en el presente (o hasta en el pasado) de la organización
• No ha permitido mejorar la calidad técnica de las soluciones

En el contexto estado actual (2019) la mayoría de los CIO (también denominados como vicepresidente, gerente o director), han llegado a sus puestos de la forma tradicional: con un estilo de gestión comando-control, por haber logrado cerrar proyectos muy grandes y complejos, algunas veces por sus habilidades técnicas, otras por sus habilidades de relacionamiento y muchas otras por su rudeza y mano dura -entendida como carácter y firmeza para sobresalir-, pero este estilo de management aun predominante en las organizaciones (pero que esta renovándose debido a los retos actuales hacia un management más humano, colaborador, empoderador, etc ) esta caracterizado por solo escuchar a los de su misma tribu, a los que opinan igual a ellos, y comúnmente no escuchar a nadie, sino a sí mismos, conductas completamente adversas a la agilidad, considerando que esta se basa en una cultura de cultivación y cooperación principalmente, ver las siguientes dos imágenes.

Modelo Cultura de Schneider (1)

Manifiesto Ágil plasmado en el esquema de cultura de Schneider elaborado por Michael Sahota(1)

Bajo este esquema, las expectativas de un equipo de TI que está batallando con la transformación ágil (y digital) de la empresa ve en su CIO su sponsor y miembro de equipo clave, requiriendo que:

• Ella (él) y su equipo lideren con el ejemplo para el resto de la organización
• Sea un aliado y un involucrado, no solo un espectador
• Este validando constantemente los resultados
• Trate a su equipo y proveedores como unos aliados y no como unas víctimas de su poder
• Sea autocrítico, con reconocimiento de errores, capacidad de adaptación, reinventarse y tenga una relación honesta (no de poder) con sus pares y equipo de trabajo.
• Permita espacios y presupuestos de innovación y creatividad, con una mirada en el futuro, la inspección y adaptación en el presente
• Este dispuesto a empoderar para generar grandes resultados,
• Entienda que en este nuevo entorno y reglas, el protagonista es su equipo y su capacidad de empoderarlos
• Negocie e involucre a otras áreas, 
• Deje de pensar en silos y vea como único fin, la generación de valor con productos y servicios customer-centric.
• Se convierta en habilitador y acelerador del cambio organizacional

Para cerrar este post una reflexión de mi estimado amigo Lucho Salazar y una nota realista

La reflexión

"Las organizaciones del siglo XXI quieren mejorar pero no quieren cambiar. Se mantienen en un estado de inmovilidad colmado de voluntades de cambio fingidas. A lo largo de mis años como agente de cambio me he encontrado con entidades cuyo propósito de renovación es simplemente un disfraz con el que ocultan su ánimo de permanecer estáticas en el tiempo. Lo que no saben estas compañías es que de no cambiar se exponen a su desaparición o al trágico rezago del que difícilmente podrán volver."@LuchoSalazarC (3)

La nota realista

"Estimad@ CIO, esta es una era del cambio y todos estamos cambiando, usted aun puede hacerlo, y es cierto, su equipo lo quiere despedir pues usted se ha convertido en su mayor obstáculo para lograr la transformación ágil y digital, por favor cambie antes que su jefe/líder se de cuenta que usted no esta emprendiendo este reto con la seriedad, compromiso e involucramiento que esto requiere"

Saludos ágiles

Jorge Abad

Notas, Aclaraciones, Comentarios, Agradecimientos y Referencias

1. Una guía de supervivencia a la adopción y transformación ágil: trabajando con cultura organizacional. Michael Sahota. http://agilitrix.com/wp-content/uploads/2018/08/Una-Gui%CC%81a-de-Supervivencia-a-la-Adopcio%CC%81n-y-Transformacio%CC%81n-A%CC%81gil.pdf
2. Agradezco a todos mis amigos agilistas que me proporcionaron importantes reflexiones para este artículo, no los puedo referenciar por temas de confidencialidad pero este post, no es mío, fue solo una compilación de muchos pensamientos.
3. Apuntes sobre transformaciones ágiles: la cultura organizacional y otros condimentos del cambio http://www.gazafatonarioit.com/2018/04/apuntes-sobre-transformaciones-agiles_1.html