miércoles, julio 03, 2019

Un mal líder puede estropear la cultura y el sistema

Quisiera aprovechar el blog para compartir algo que he visto y que todos sabemos

"Un mal líder puede estropear la cultura y el sistema"

Me explico, en este trasegar acompañando organizaciones en su transformación hacia la agilidad he visto de todo, tal como:
  • organizaciones llenas de procesos con equipos muy dinámicos dando excelentes resultados
  • organizaciones sin procesos detallados con resultados lentos
  • organizaciones con procesos de adorno
  • organizaciones con líderes inspiradores y líderes desmotivadores
  • y toda clase de combinación pervesa, positiva y mediocre de las anteriores
Llevándonos a decir con Deming

Resultado de imagen para a bad system beats a good person

Resultado de imagen para un mal sistema deming

Y en esa misma dirección recordé ésto que publiqué hace un tiempo en linkedin.




Cosa cierta, pero cada vez creo que esto de culpar al sistema, la cultura, los incentivos, los procesos, las métricas, los kpi, etc. es una excusa frecuente, cuando muchas veces una de las causas raíces a muchos problemas sistémicos son:
  • el liderazgo
  • y la forma como interactuamos
Es por tanto clave intervenir tanto el liderazgo como la forma como interactuamos, pero primeramente el liderazgo, sino será muy poco lo que podamos mejorar en el sistema y la cultura.

Hasta acá este compartir

Saludos ágiles

Jorge Abad

De Colección: Culpamos el sistema, pero el sistema somos nosotros

Me encanta esta cita de Seth Godin

https://seths.blog/2016/06/the-problem-with-complaining-about-the-system/


The problem with complaining about the system

…is that the system can’t hear you. Only people can.

And the problem is that people in the system are too often swayed to believe that they have no power over the system, that they are merely victims of it, pawns, cogs in a machine bigger than themselves.

Alas, when the system can’t hear you, and those who can believe they have no power, nothing improves.

Systems don’t mistreat us, misrepresent us, waste our resources, govern poorly, support an unfair status quo and generally screw things up–people do.

If we care enough, we can make it change.


Que podría traducirse como:


El problema de quejarse acerca del sistema


... es que el sistema no te oye. Solo la gente puede oir.

Y el problema es que las personas en el sistema a menudo se sienten inclinadas a creer que no tienen poder sobre el sistema, que son simplemente víctimas de él, peones, piñones en una máquina más grande que ellos mismos.

Por desgracia, cuando juntas que el sistema no puede escucharte, con aquellos que creen que no tienen poder, nada mejora.

Los sistemas no nos maltratan, no nos tergiversan, no malgastan nuestros recursos, no gobiernan mal, no apoyan un status quo injusto y, en general, no arruinan las cosas, las personas lo hacen.

Si nos importa lo suficiente, podemos hacerlo que cambiar.

lunes, junio 24, 2019

Mi opinión sobre SAFe (Scaled Agile Framework): sí, es un buen comienzo y resuelve ciertos problemas de escalado



Constantemente leo y escucho dentro del mundo ágil: fanáticos, detractores, amigos por conveniencia, amigos con derechos, relaciones casuales y relaciones duraderas, affairs, mercenarios, fundamentalistas y todo tipo de relaciones con los frameworks, métodos y metodologías que caen en la sombrilla del Manifiesto Ágil (clic aquí) y eso es bueno, pues genera interesantes discusiones, conclusiones y fuentes de aprendizaje.

En este camino he aprendido que no hay recetas únicas para resolver problemas que tienen los equipos de trabajo que hacen soluciones de software. Desde el punto de vista ágil me declaro Scrum por fuera y Kanban por dentro - pongo de manifiesto que cualquier framework ágil sin excelencia técnica es un desperdicio y dolor de cabeza -, de ahí en adelante lo que funcione será útil para mí, o sea, en pocas palabras soy un mercenario del escalado de ágil.

A nivel de frameworks he trabajado en el mundo ágil con:
  • Kanban
  • Scrum
  • Scrumban
  • Playbacks (para BPM)
  • Scrum de Scrums
  • Nexus
  • SAFe
  • Scrum@Scale
  • y en compañía con el equipo de profesionales que trabajo actualmente también hemos generado nuestros híbridos y combinaciones.
Y aunque confieso que cuando vi el diagrama de SAFe - Scaled Agile Framework me asusté y me pareció algo complejo, quisiera compartir en este post lo que he vivido con el framework (1), cuándo recomiendo desplegarlo, los problemas que he visto que soluciona, y sus beneficios. Comencemos entonces.


Algunos problemas sistémicos escalando la agilidad

Cuando he trabajado escalando ágil con más de 3 equipos con el mismo Product Backlog, en grandes organizaciones me he topado con los siguientes problemas:
  • Product Owners que no están al menos tres sprints adelante de su equipo realizando definiciones y resolviendo dependencias
  • Product Owners reactivos (similar a la anterior)
  • Pobre gestión de dependencias entre equipos (consecuencia de la primera)
  • Crecimiento de la complejidad
  • Poca o nula comunicación entre equipos
  • Se excede la capacidad de los equipos de soporte (infraestructura, riesgos, pruebas no funcionales, legal, etc).
  • No se mejora sistemáticamente
y aunque todo esto se podría resolver sin el marco de SAFe, en organizaciones grandes cuesta generar este tipo alineación y sincronización debido a que su cultura actual - que es justo la que se quiere dinamizar y aumentar la colaboración - no les permite espacios para este tipo de coordinación

Cuándo recomiendo comenzar con SAFe

Considerando lo anterior cuándo recomiendo comenzar con SAFe:
  • Existe una cultura de gestión tradicional muy fuerte
  • Existen al menos 4 equipos trabajando con el mismo Product Backlog
  • Los Product Owner no tiene dedicación de al menos el 50% para ejecutar el rol correctamente.
  • Se están presentando problemas de gestión de dependencias y
  • Se están presentando problemas de gestión de la capacidad de las áreas de soporte


Algunos Beneficios

A continuación comparto algunos beneficios conseguidos en las implementaciones de SAFe que he acompañado, así como algunas que he conocido en la industria:
  • Beneficios Generales
    • Usa Scrum y Kanban como base, lo que permite una mejora sistemática
    • Mínimo cada dos semanas hay software funcionando
    • Se sale a producción por demanda
    • Se tiene al cliente como fundamento y validación de hipótesis
    • El latir de Program Increment comienza a dinamizar las organizaciones y a fuerza del hábito termina agilizando el entorno.
    • SAFe y cualquier marco ágil requiere de excelencia técnica y de DevOps, SAFe lo pone de forma explícita como insumo para su ejecución.
    • La demo gigante al final del ciclo del Program Increment genera un espacio de celebración que genera motivación a los participantes y a la par "presión" social para equipos que han decidido no trabajar con el profesionalismo mínimo que deberían tener.
  • Beneficios Asociados al Program Increment Planning  (PI Plannig)
    • Genera Product Owners proactivos, pues deben estar adelantados al menos 2 o 3 meses en su horizonte de tiempo para la sesión.
    • Durante los dos días de PI Plannig genera alineación entre equipos y la organización
    • Se resuelven dependencias entre equipos, áreas de negocio y áreas de soporte
    • Los equipos de un mismo programa se alinean con el propósito de la solución
    • Los equipos del programa se ayudan entre sí, pareciendo una gran tribu. He visto a estos equipos:
      • tomar historias de usuario de otros equipos
      • probar software que otros equipos hicieron
      • expresar su disponibilidad para ayudar a otros
      • inquietarse como programa
      • celebrar juntos como programa
    • Existe validación de capacidad por áreas de soporte
    • No permite avanzar con supuestos irreales,
    • Permite identificar un plan factible (no fijo) para el próximo ciclo de 2 a 3 meses, es decir un plan sobre el cual se puede hacer inspección y adaptacion.
Si deseas un ejemplo de resultados organizacionales generados con el framework de SAFe te recomiendo el link de la referencia (1).

Y las Conclusiones

A continuación comparto algunas conclusiones:
  • SAFe en su nivel esencial (o sea a nivel de programas) lo considero un buen comienzo, para agilizar la organización, los otros niveles (Portafolio, Grandes Soluciones, Full SAFe) contienen prácticas que son buenas guías, pero las organizaciones determinarán cuales implementar y cuales no.
  • No he conocido la primera gran organización que ha desplegado el 100% de SAFe
  • Es un buen comienzo, propone soluciones interesantes a nivel de portafolio y de priorización
  • Su orientación a flujos de valor - value streams -, propuesta por muchos en el Mundo Ágil, resuelve problemas sistémicos generados por los silos
  • Sugiero desplegar SAFe con Scrum@Scale para dinamizar la toma de decisiones, y acelerar el flujo de información a nivel organizacional, tanto horizontal como vertical.
  • SAFe es un medio, no el fin en sí, lo que se quiere es proporcionarle a la organización la capacidad de adaptarse al entorno de forma dinámica.
  • En caso de que la organización fuera proclive a la agilidad, prefiero un enfoque más orgánico con una combinacion de Design Thinking + Scrum + Kanban + DevOps y prácticas de Scrum@Scale
Por último, quienes no lo han vivido, los invito a experimentarlo,  ver las sinergias organizacionales que son consecuencia de implementar el marco y después compartan sus experiencias, de esa manera todos crecemos.

Hasta acá este compartir.


Saludos ágiles

Jorge Abad




Notas, Comentarios, Referencias y Observaciones

  1. Testimonio de uno de los clientes en los que he participado en el despliegue de SAFe -Innovación en Claro para beneficio de sus clientes (clic aquí), los videos juntos los puedes ver aquí.
  2. Agradecimientos a mi amigo Lucho Salazar por su revisión y feedback en este articulo

jueves, junio 06, 2019

Más de un millón de mejoras en el año en Toyota

Hola a todos

Con frecuencia citamos cosas por que las hemos escuchado de personas que son relevantes para nosotros y que son referentes.

Hace un tiempo escuché y constantemente compartía algo que varios referentes decían:

 "En Toyota se hacen más de un millón de mejoras en el año con su proceso de mejora continua o Kaizen"
Decidí averiguar la referencia a esa cita y un agilista, Hugo Suaréz me proporcionó la referencia exacta,


Kaizen, la clave de la cultura Japonesa por Masaaki Imai


y la Cita exactamente reza:
"Una de las características de los trabajadores japoneses es que usan tanto el cerebro como las manos. Nuestros trabajadores proporcionan 1.5 millones de sugerencias al año y el 95% de ellas se ponen en uso práctico. Existe un interés casi tangible por el mejoramiento en el aire de Toyota" 
Eiji Toyoda, Presidente del Consejo de la Toyota Motor.

Gracias Hugo por la referencia y esta es una invitación a no detenerse, quiero invitarlos a:
no caer en la tentación de realizar mejora continua por que lo dice el proceso, el framework, el marco, la metodología, o la norma, esta aproximación es una mala interpretación del método de Toyota y se aleja radicalmente del propósito del Kaizen, hay que hacer mejora continua por que es la única forma de hacernos inalcanzables.
Gracias a mis amigos y referentes que han compartido información que es verídica y comprobable, suena obvio, pero es importante saber a que líderes seguir en el mundo empresarial y de la agilidad.

Saludos ágiles


Jorge Abad

martes, junio 04, 2019

Una idea sobre cultura, propósito, principios, valores y procesos

Una conclusión a partir de tantas lecturas y observaciones:

"Los procesos no alcanzan a legislar sobre todo lo que ocurre en una organización y en ausencia de procesos: los valores, principios y cultura de la organización guiarán a lo colaboradores ante cualquier situación, incluso sobre cualquier proceso definido previamente.

Una buena cultura, principios y valores te guiarán al éxito, similar en caso contrario."

sábado, junio 01, 2019

Una versión de Casca-Agile(TM) o Casca-Scrum: tener "Sprint de desarrollo y luego Sprint de pruebas"




Hola a todos

Hace unos años en Ciudad de México dictando un entrenamiento de Scrum y Principios Ágiles, en el momento de hablar de malas prácticas, uno de los asistentes (y amigo mío Ulises Soriano), bautizaba como:

Casca-Agile (TM)

cuando se tomaban cosas del mundo ágil y del de cascada, pero con el pésimo resultado de que no se obtenía ni la "predictibilidad" añorada de cascada, ni la adaptabilidad de Scrum.

Esté termino lo he seguido usando desde ese entonces, y luego de tener la oportunidad de compartir con tantas organizaciones a nivel Latinoamérica he observado que hay una versión de Casca-Agile común a muchas empresas que no quieren adoptar la agilidad por completo: y es que contratan a un proveedor para que haga Scrum en el desarrollo del software y otro proveedor para que haga Scrum en las pruebas, olvidando lo que tanto se enuncia el marco Scrum en dos apartes:

"El Equipo de Desarrollo consiste en los profesionales que realizan el trabajo de entregar un Incremento de producto “Terminado” que potencialmente se pueda poner en producción al final de cada Sprint. Un Incremento “Terminado” es obligatorio en la Revisión del Sprint. Solo los miembros del Equipo de Desarrollo participan en la creación del Incremento."(1)

"Los Equipos de Desarrollo son multifuncionales, esto es, como equipo cuentan con todas las habilidades necesarias para crear un Incremento de producto;"(1)

Esa versión de Casca-Agile o Casca-Scrum, termina viéndose así:



Añadiendo al menos 3 sprints (pueden ser más) entre el desarrollo de la historia de usuario y el lograr la "certificación"por parte de pruebas

Las desventajas que esto genera

  • Largos tiempo de entrega del incremento (al menos tres sprints más)
  • La imposibilidad de revisar el incremento completo cuando se termina cada sprint de desarrollo por parte del PO.
  • Bajo involucramiento del PO
  • La Definición de Terminado o "Definition of Done" toma mucho tiempo para que sea completamente alcanzada por ambos equipos
  • la responsabilidad sobre el producto construido no existe.
  • Gestion de ANS (acuerdos de niveles de servicio) que no agregan valor y desfiguran el marco de Scrum.
  • El equipo de testing no esta sintiendo la construcción incremental del producto y por lo tanto no se sienten responsables del la buena construcción del mismo
  • Esto no es Scrum y se aleja de la agilidad pues no cumple ni con la definción de Scrum, ni con los valores y principios del manifiesto ágil (2)
  • A esto muchos se atreven a llamarlo Scrum, sabiendo que no lo es, o lo llaman "Scrum pero" (o ScrumBut (3)), y si no les funciona le echan la culpa a Scrum.

Las ventajas

  • Le pienso y le pienso y no lo encuentro, puede que saboreen un poco las mieles del desarrollo iterativo e incremental, pero deja mucho que desear.

Solución a este antipatrón

La "falsa sensación de seguridad" de tener dos contratos, uno para el proveedor de desarrollo y otro para el proveedor de pruebas, se resuelve sentándolos juntos en una sola mesa y siendo ambos responsables de la calidad del producto entregado, cada sprint.


Cerrando

Bien parafrasean muchos a Jeff Sutherland,

"el peor enemigo de Scrum, es un mal Scrum" 

o mejor como él lo dice:


Referemcia(4)



Hasta acá este compartir, bienvenidos los comentarios y experiencias.

Saludos ágiles
Jorge Abad


Notas, Aclaraciones, Comentarios y Referencias

  1. La Guía Oficial de Scrum - https://scrumguides.org/
  2. Manifiesto por el Desarrollo Ágil de Software -https://agilemanifesto.org/iso/es/manifesto.html
  3. Una excelente definición de ScrumBut - https://www.scrum.org/resources/what-scrumbut
  4. https://www.scruminc.com/jeff-suthlerland-launches-scrum-at-scale-guide/
  5. Si deseas ver más disfunciones de Scrum y de Ágil, haz clic aquí. http://www.lecciones-aprendidas.info/2019/04/malos-olores-en-transformaciones-agiles.html

martes, mayo 14, 2019

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.



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





sábado, mayo 04, 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:



lunes, abril 29, 2019

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:
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?



jueves, abril 25, 2019

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

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/

sábado, abril 20, 2019

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

jueves, abril 04, 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.

lunes, abril 01, 2019

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

viernes, marzo 29, 2019

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






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

------
------
------
------
------
------
------




Saludos ágiles

Jorge Abad









miércoles, marzo 27, 2019

Á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:





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

lunes, marzo 18, 2019

Los ANS y la agilidad

Tweet - Cita sobre Scrum

martes, marzo 12, 2019

Entrenamiento: Management 3.0 Workshop Details




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

Cuando: Abril 11-12
Ciudad: Medellín



¡Están cordialmente invitados!


jueves, febrero 28, 2019

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




sábado, enero 26, 2019

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