Mostrando las entradas con la etiqueta agilidad a escala. Mostrar todas las entradas
Mostrando las entradas con la etiqueta agilidad a escala. Mostrar todas las entradas

sábado, agosto 24, 2024

Registro de una conversación reveladora: características de los equipos y culturas de alto desempeño

Esta es una pequeña nota, donde dejo registro de una conversación reveladora que tuve con mi gran amigo Juan Andrés Ochoa, algoque hemos ido construyendo mutuamente:

Los equipos de alto desempeño cuentan con cuatro características:

  • Personas idóneas, es decir, son apropiadas para hacer la misión que se les va a encomendar.
  • Propósito.
  • Métricas que les muestren si están en el alto desempeño. Estas pueden ser tempranas y rezagadas, o un indice que combine ambas, es decir, en el caso de los equipos ágiles, soy un equipo ágil si impacto al negocio, entonces cuáles son las métricas que determinan que tengo agilidad (incluida, obviamente la excelencia técnica) y cuáles son las métricas que determinan que sí estoy impactando el negocio.
  • Una narrativa de cultura que proporcione un marco de actuación, que le cuente al equipo:
    • Lo que NO se espera del equipo, ejemplos: 
      • que no se gestione la deuda técnica, 
      • que no se asista a los eventos,
      • que no se respete a las personas.
    • Lo BÁSICO que se espera del equipo, ejemplos:
      • que cumpla sus compromisos,
      • entregue trabajo con excelencia,
      • se den retroalimentación mutua,
      • que reciban sin problema retroalimentación externa.
    • Lo EXTRAORDINARIO que se espera del equipo, ejemplos:
      • Investigar nuevas formas de hacer las cosas,
      • hacer de la innovación una forma de trabajo,
      • traer nuevos negocios a la empresa.
Lo anterior, se puede extrapolar al resto de la empresa cuando la vemos como un gran equipo conformado de equipos.

domingo, mayo 17, 2020

En Qué Radica el Éxito de la Transformación Ágil: Un Pensamiento Sobre la Batalla de los Frameworks de Escalado de Ágil

Te recomiendo visitar la versión mejorada de este artículo: http://www.lecciones-aprendidas.info/2020/06/en-que-radica-el-exito-de-la-transformacion-agil.html

Tomado de (1)

Hola a todos

Con varios amigos del mundo ágil con cierta frecuencia caemos en el lugar común de la batalla de los frameworks ágiles y en especial los de escalado, algunos temas recurrentes son:
  • organizaciones pagan millones de dolares a las consultoras top para que al final de tres meses que les digan que adopten el modelo Spotify (que en últimas no es un modelo) (2)
  • discutimos sobre cuáles son los beneficios y falencias de cada uno, cuál es más prescriptivo y cuál es más adaptativo
  • comparamos sus estrategias de gestión del cambio
  • confrontamos cual framework es más exitoso, o que autor prominente lo creo, promulga o defiende, 
Pero luego de desgastarnos un rato en discusiones bizantinas, pues todos los frameworks de escalar ágil cuentan en sus haberes con casos de éxito que publican orgullosos en sus páginas, pero que luego "despublican" cuando se vuelven fracasos, concluimos que son muchos los factores que compiten o colaboran entre sí, para lograr el éxito o el fracaso.

Factor
Hacia el éxito
 Hacia el fracaso
Compromiso del Top-Management
·       alto compromiso e involucramento
·         Delegación completa y desentendimiento
Gestion el cambio organizacional
·       Adaptativa, basada en comunicación de éxitos y ganar adeptos.
·       Fija y predictiva
procesos y contratos
·       Modificados y en continua mejora hacia la agilidad
·       Sin modificar y orientados a la culpa en vez de la colaboración
Respecto a los líderes y al mindset
·        Capacitados y empoderados para compartir el mindset
·        La difusión del mindset es de lagada en los consultores y algunos roles 
Tolerancia al fracaso
·       Alta
·        Baja
Comunicación
·       Fuerte y constante comunicación de la estrategia de cambio
·        Comunicación de la estrategia de cambio
·        Poca o nula comunicación
Espacios de trabajo y herramientas de colaboración
·        Acondicionados para la colaboración (los espacios moldean el comportamiento)
·        Limitados y restringidos
Silos organizacionales
·         Colaborando en torno al valor
·        Enfocados en optimizar la agilidad en su área
Métricas de gestión
·       Modificadas a promover la agilidad de personas, equipos, y la organización (recuerda, "como me midas me comporto")(4)
·        No sufren cambios
Agilidad Técnica
·       Adoptada como una estrategia organizacional buscando DevOps, Excelencia Técnica. 
·        Adoptada como la compra de herramientas
Cultura
·        incentivar los nuevos comportamientos.
·        Desincentivar estilos de gestión y comportamientos que degraden las personas y la cultura de la organización
·        No intervenidos
Respecto a los frameworks ágiles
·         Adoptados con acompañamiento y los lineamientos planteados por sus creadores
·        Adoptados con demasiadas adaptaciones, falencias y personalizaciones que terminan desfigurando y replicando el statu quo actual.
Mindset
·        Constante difusión y adopción del mindset lean - agile (5)
·        No intervenido
Respecto a los consultores (3)
·        Acompañamiento de consultores con experiencia que cultiven el proceso y transfieran el conocimiento
·        Consultores que comparten la estrategia y no hacen parte del proceso de cambio
Entre otros



Yo me quedo con mi conclusión
"Hay organizaciones que sin importar el framework ágil logran ser ágiles y otras que sin importar el framework nunca llegan a serlo"

Por lo tanto, el problema al parecer no radica tanto en los frameworks, el problema radica en las personas y su disposición a adoptar este cambio, que dada vez es menos opcional.

Saludos Ágiles

Jorge Abad.




Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. Photo credit: Fotodilletant on Visualhunt / CC BY-SA
  2. Yo también puedo hacerlo por la mitad del precio y mejor resultado
  3. Sugerencias de mi amigo Lucho Salazar
  4. Como me midas me comporto - http://www.lecciones-aprendidas.info/2019/11/una-conclusion-como-me-midas-me-comporto.html
  5. http://www.lecciones-aprendidas.info/2020/05/mindset-lean-agile.html

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

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?