Cómo evitar la "Ingenuidad Ágil", o sobre como tener éxito en proyectos ágiles en entornos tradicionales

Tomado de (1)

Hola a todos


En este acompañar equipos y organizaciones hacia el mindset ágil, con frecuencia he observado a Scrum Masters, e incluso Agile Coaches, ser ingenuos respecto al entorno en el que se encuentran y creer que su iniciativa, proyecto o producto ágil va a salir adelante solo con el burndown, burnup, kanban, uno que otro tablero y compartir sus pedidos de forma verbal con el o los interesados encargados de ayudar a la gestión del entorno empresarial, en efecto, esto debería ser suficiente pero la noticia cruel es que la mayoría de nuestros proyectos ágiles se desarrollan al inicio en entornos tradicionales, no amigables con el mindset ágil, por lo que  es necesario emplear herramientas de la gestión tradicional a modo de interfaz, como lo llamaría Michael Sahota (2).

Adaptado de (2)

Adaptado de (2)

Una de las herramientas que comúnmente sugiero, y bastante poderosa en entornos tradicionales es un informe semanal o quincenal con el estado de

• la gestión de riesgos
• la gestión de problemas o impedimentos

Claro, claro esto se puede gestionar con dos tableros,

o incluso con uno solo, que tenga dos carriles, unos impedimentos sean problemas a resolver lo antes posible y los riesgos sean problemas a resolver en el mediano plazo

y post-it que indiquen:

• descripción del problema o impedimento
• fecha de identificación
• persona a la que fue asignado
• días que lleva sin resolverse (pueden ser solo líneas en el post-it)

Pero un informe de carácter frecuente, con esta información con seguridad pondrá en evidencia la necesidad de gestión por parte del entorno tradicional.

Igual que un tablero, un informe frecuente también es transparencia.

Informe de Problemas o Impedimentos (3)

Informe de Riesgos(3)

como lo comparto muchas veces

"hasta que el entorno y las personas no muestren indicios de mindset ágil, deberemos interactuar con ellos con las herramientas a las que están acostumbrados y ayudarles a transitar a nuestro mindset"

Adaptado de (2)

Nota importante:
Esta misma ingenuidad la he visto en proyectos de gestión tradicional.


Bienvenidos sus comentarios

Saludos Ágiles
Jorge Abad

Notas, Comentarios, Aclaraciones y Observaciones

1. Photo on Visualhunt.com
2. Una guía de supervivencia a la adopción y transformación ágil: trabajando con cultura organizacional. Michael Sahota-  http://www.lecciones-aprendidas.info/2017/08/una-guia-de-supervivencia-la-adopcion-y.html
3. No dudo que estos reportes podrán tener más o menos información, deberán ser adaptados de acuerdo al contexto, pero recomiendo fuertemente:
• tener a alguien asignado para su resolución
• tener el tiempo de "no resolución"
• la importancia para el "proyecto"
4. Por lo general pongo "proyecto" (entre comillas) debido a que en el mundo ágil no se gestionan proyectos, sino productos.

Criterios para la Selección y el Éxito del Proyecto Piloto en Scrum

Hola a todos

Con cierta frecuencia comparto tips sobre como elegir el Proyecto Piloto en el mundo ágil, aquí va la lista de tips actualizada.

---

Se recomienda iniciar con proyectos que cuenten con los ciertos criterios que nos permiten tener un mayor impacto en la organización:

• Duración estimada de máximo 8 meses
• Contratación del proveedor bajo esquema ágil - ver más aquí -.
• Seguimiento bajo métricas ágiles.
• burndown chart para los sprints
• velocidad
• burnup chart para el Release
• Dedicación una persona experta en el negocio de al menos el 50%, la cual esté empoderada y no denigre de la agilidad.
• Un Scrum Master o Facilitador experto 
• Los impedimentos identificados por el Scrum Master o Facilitador serán atendidos y tendrán prioridad
• Las evaluaciones de desempeño de quienes participan en el proyecto no sean en cascada
• Las áreas de soporte le den prioridad al proyecto
• Ejecución por uno o dos equipos ágiles (15 personas máximo en total)
• Se debe de considerar tecnologías conocidas por los equipos
• Las personas de los equipos deben: 
• Contar con los skill técnicos
• Dedicación al 100%

Tomado de (1)

Si quieres conocer los post asociados a este tópico haz clic aquí - http://www.lecciones-aprendidas.info/search?q=piloto

Aclaraciones, Notas, Comentarios y Referencias

1. "Tips para una PMO perdida en el Mundo Ágil" - clic aquí - 

¿Cuándo usar Ágil? o ¿Cuándo se Comienza a Generar Valor un Proyecto Ágil (4)?

Hola a todos

Hace un tiempo vi el excelente video de Agustín Villena - LKES17: Agustin Villena - Alineamiento, flujo y exploración (clic aquí) - recomiendo verlo con papel y lápiz, - por allá en el minuto 16:00-  clic aquí-, comparte la siguente gráfica de Alistair Cockburn.

Develop for business value once risks are down (1)

Donde el mensaje clave es: "Antes de comenzar a generar valor debes bajarle el riesgo a tu proyecto"

Es obvio sino tu proyecto, producto o iniciativa estará torpedeado por impedimentos, retrasos, problemas, desconocimientos, complicaciones técnicas, etc., cayendo en una zona de mucha fricción y poca velocidad en el desarrollo y en consecuencia es difícil generación de valor. Es por eso que también que dentro de las sugerencias para realizar un piloto en ágil se sugiere que la tecnología sea conocida y dominada por el equipo (2).

Ahora también,  lo presenta el articulo de Alistair (1) en el apartado "Don’t confuse knowledge acquisition with BDUF -Big Desing Up Front(3)", es probable que debas asumir una velocidad baja de tu equipo mientras logran:

• entender mejor la arquitectura
• resolver dependencias
• realizar pruebas de concepto
• comprender mejor los frameworks

Y luego de esta zona, si ganar velocidad en la zona de generación de valor.

Hasta acá este cortísimo compartir

Saludos ágiles
Jorge Abad

Referencias, Notas, Aclaraciones y Comentarios

1. Design as Knowledge Acquisition by Alistair Cockbur - clic aquí- .
2. Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos. - clic aquí -.
3. Big Desing Up Front: the old habit of sitting at the desk and drawing up a big, fancy, full-scale design (BDUF = “big design up front”) (1)
4. Cada vez más me alejo del concepto de Proyecto Ágil, podria cambiar este título por ¿Cuándo se Comienza a Generar Valor en la Construcción de un Producto de Forma Ágil?

Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.(parte 2)

Imagen de la película: ¿Dónde está el piloto? - Idea de mi amigo Wilmar Hincapie

Hola a todos

En el pasado Ágiles 2017 en Chile, hablando con Leonardo Agudelo (@sweepnoise) sobre los proyectos piloto, me hacía ver que no solo eran importantes los puntos del artículo anterior (mira la primera parte de este artículo - Clic aquí):

• 3 a 4 meses de duración
• Con 1 a 4 equpos de trabajo
• Importante para la organizaicón
• Patrocinio ejecutivo
• La gente correcta
• Dominio de la tecnología

Sino que era necesario revisar el manifiesto ágil buscando los elementos para cumplirlo y para generar el ambiente propicio para que germine la agilidad, a continuación les comparto este análisis y algo de mi experiencia:

• Crear un contrato que permita la agilidad, seamos sensatos un contrato con todo fijo -alcance, tiempo y costo fijo- no nos permitirá tener éxito. (ver sobre contratos agiles - clic aquí- )
• No usar las tipicas métricas de cascada (CPI, SPI) para medir el proyecto (es un desastre tratar de acomodar ágil a esto - se los digo por experiencia)
• Permitir el cambio como parte natural del proceso (he observado que en proyectos que quieren hacer ágil, siguen con la política de control de cambios --¡¡OMG!! NO SE IMAGINAN EL DOLOR DE CABEZA. es necesario archivar este proceso para poder hacer el piloto)
• Cambiar las métricas de la evaluación de desempeño de las personas que participaran (es decir, en cascada a un analista le daban una buena calificación si tenía pocos controles de cambio, si este analista se va para el piloto de ágil, las historias de usuario las grabará sobre piedra - y me ha pasado -)
• Requerir que el negocio este involucrado y contar con su participación al 100% (con el ROL de Product Owner o de Interesado clave)
• Que exista la comunicación cara a cara (todos en el mismo sitio , co-location)
• Crear las excepciones - válidas a los procesos organizaciónales - que permitan la agilidad
• Prioridad en los despliegues
• Prioridad en los controles de cambio de ambiente
• Prioridad en las autorizaciones
• etc

Cerrando

Ya hemos perdido mucho tiempo y dinero haciendo proyectos en cascada, démosle la oportunidad a ágil, pero bajo las condiciones para que este tenga éxito, sino no tiene sentido.



Alguna otra recomendación

No dudes en compartirla en la zona de comentarios.

Bienvenido el feedback

Saludos ágiles

Jorge Abad

Mira la primera parte de este artículo - Clic aquí

Cómo elegir el proyecto piloto para Scrum. Mi versión de los hechos.

Hola a todos

Hace poco leí un gran post de Mike Cohn relacionado con como elegir el proyecto piloto: (ver el post  aquí) en donde reforzaba 4 variables (más un bonus):

• Duración: 3 a 4 meses
• Tamaño: Entre 1 y 4 equipos de trabajo (un equipo de máximo 9 personas)
• Importancia: Importante para la organización
• Patrocinio y Compromiso Ejecutivo: Alto
• y un Bonus: Contar con las personas correctas para hacer el proyecto (las que nos garanticen ganar esto funciona para cualquier escenario - agile o tradicional-).

El punto que quiero agregar (como fuente de mi experiencia) a esta lista de 5 puntos es:

• La Tecnología: la tecnología debe ser dominada por el (los) equipo(s) de trabajo

y ahí es donde va aporte, no tiene sentido (adicional a los 5 puntos anteriores) hacer un piloto en agile, o Scrum donde:

• la tecnología es nueva en el mercado, es decir, el proveedor nos están brindando la "valiosísima oportunidad" de ser de los primeros que la usan o implementan (¡OMG!),  o
• el equipo de trabajo no conoce la tecnología, es decir:
• no se domina la arquitectura
• no se conocen los componentes
• no se conocen los retos subyacentes, las características, 
• las premisas y supuestos no se dominan, 
• no se conoce como hacer el tunning del sistema, entre otros.
• y aunque el equipo recibió una "muy buena capacitación" y les funcionaron "todos los laboratorios" sabemos que eso no los hace expertos en algo nuevo (que al menos requeriría seis meses de trabajo continuo para comenzar a tener cierto dominio)

Sabiendo que el propósito es generar una victoria temprana y un gran impacto en la organización, de forma que sea comparable con los proyectos en cascada de similares condiciones.

No recomiendo hacer el primer piloto en agile con tecnología desconocida (y para ser sincero tampoco en cascada), pues no se verían resultados en el mediano plazo ni de la tecnología nueva ni del método.

Mi recomendación general sería:

• hagamos un proyecto piloto en agile con que cumpla las seis premisas:
• 3 a 4 meses de duración
• Con 1 a 4 equpos de trabajo
• Importante para la organizaicón
• Patrocinio ejecutivo
• La gente correcta
• Dominio de la tecnología

• y si, aun así desean el proyecto de la tecnología nueva y retadora, pues que sea otro proyecto adicional al primero, pero:
• que "este no sea el de mostrar" que Agile funciona (pero eso sí estoy seguro que si en este proyecto hacen correctamente Agile o Scrum les aseguro que avanzará más rápido que en cascada)
• que tenga e alcance pequeño 
• que cuente con alto acompañamiento al equipo de parte de expertos o personas conocedoras de la tecnología
• que la organización tenga paciencia este proyecto y su presentación de resultados,  
• y que los patrocinadores tengan alta tolerancia a la frustración pues este problema no corresponde a un escenario complejo (ni mucho menos predictivo) sino a una caótico donde es difícil tener victorias tempranas (1).

Hasta acá esta corta recomendación, reflexión y lección aprendida.

Saludos ágiles

Jorge Abad

(ver más en : Mira la segunda parte de este artículo - clic aquí )

Notas, aclaraciones, comentarios y referencias

1.  Ver el framework de Cynefin para entender el contexto de esta afirmación (clic aquí)