Seminario el impacto de las metodologÍas agile-lean en chile y el mundo

Hola a todos

El día de hoy tuve la oportunidad de asistir al"SEMINARIO EL IMPACTO DE LAS METODOLOGÍAS AGILE-LEAN EN CHILE Y EL MUNDO" en el cual pude escuchar las participaciones de Mary y Tom Poppendieck, Agustin Villena y Janell Wellborn

A continuación les comparto algunas de mis anotaciones al respecto y algunos cuestionamientos que quedaron sonando en mi cabeza luego de las charlas:

  1. Mary decía algo como: El helpdesk apareció como una solución al problema que producía el que los productos sean defectuosos y en vez de preocuparnos por saber cual era el real problema, seguimos agregando capas al mismo, seguimos acumulando más desperdicio. ¿Cuántas veces seguimos planteando soluciones para las consecuencias sin antes preocuparnos por buscar la real causa raíz? ¿cuántas veces nos preguntamos si la solución a esa consecuencia le aporta valor al cliente?
  2. “Una carretera completamente utilizada es un estacionamiento”. Esto es una cuestión de flujo continuo y espacio para la flexibilidad.
  3. “La esperanza no es una estrategia”, al referirse a la capacidad en entrega de un equipo, Mary hizo esta observación y a mi me quedó sonando ¿cuántas veces he visto planes enteros cimentados en una “esperanza” como estrategia de lograrlos?
  4. “Los creadores necesitan conexión inmediata con lo que están creando” Mary hacía referencia a Bret Victor y lo importante de probar lo construido tan pronto como sea posible, es decir INMEDIATAMENTE.

Luego Agustín nos contó sobre Agilidad Esencial:
5. Agustín traía a colación algo que se ha estado planteando desde diferentes perspectivas hoy en día: La vigencia y pertinencia del Agile Manifesto; ¿han cambiado las condiciones al día de hoy?¿qué adaptaciones le debemos hacer?, el proponía una forma, yo prefiero aún dejar la pregunta abierta e irla respondiendo de forma reflexiva desde nuestras realidades.
6. ¿El Agile Mindset es solo aplicable al software? me encantó el ejemplo de “Agile Classrooms” y sobre como el obstáculo más grande es el mindset de los profesores.

Finalmente habló Janel Wellborn y me dejó dos ideas fijas en mente:

  1. Enfocarse en la mínima cosa a construir sobre la cual se pueda aprender. (esto en el contexto del ciclo de LEAN: Build -> MESURE -> LEARN ->Build)
  2. Hacer la transición de enfocarse en Outcome más que en el Output.

Les dejo el link a las dos primeras presentaciones a continuación, espero conseguir la tercera:

https://www.dropbox.com/s/mibg2zp602bm7p4/Una%20breve%20historia%20de%20Lean.pdf?dl=0
https://www.dropbox.com/s/tj3mlbugx6i4yy3/Agilidad%20Esencial.pdf?dl=0

Vi algunos de la comunidad en las sesiones, ¿se animan a compartir sus apuntes?

Un abrazo

Eso me gustó. Como yo lo hago:

máquina de desarrollo (equiop de cada desarrollador) -> Hg
-> máquina de integración
-> máquina de staging.

Staging se compila 2 veces al día y el usuario puede “meterse a probar” lo que viene.

La idea es ir y probar con él. ¿Se puede interrumpir al usuario? ¿Prefiere que le mostremos cada funcionalidad por separado o todo junto?

Ahí está la parte donde no me ha dado mucho resultado. Si es todos los días, se aburre de la interrupción. Si es una vez a la semana, le molesta que le interrumpas la semana y que tome mucho tiempo. Si es una vez al mes, lo interrumpes menos, pero la interrupción demora más.

Idealmente uno debería hacer prototipos en papel o prototipos digitales (pintados) y que te los aprobaran antes de construir.Eso no me ha dado resultado, quieren ver la cuestión de verdad.

Incluso cuando es un prototipo real (código Java) pero nada por detrás, no quieren verlo.

Y cuando estás a 2 semanas de entregar, no aceptan defectos… aunque lo estás mostrando sólo para que se vea la funcionalidad y corregir a tiempo…

Todo me ha fallado en ese sentido, por más que dicen que debes validar los requerimientos, los cambios llegan después y luego de 2 o 3 meses de trabajo, se espera tener todo listo en 2 semanas.

Creo que lo mejor es apicar Scrum estricto: 2 semanas para cualquier cambio. Nunca lo aceptan porque siempre aplican ScrumBut.

Debería haber una regla que indique que nada se puede hacer si no es con Scrum, porque de otra manera no se ordenan.

Comparto el video de Bret Victor que uso Mary Poppendiecken Agiles 2015, para hacer referencia a “Los creadores necesitan conexión inmediata con lo que están creando” .

1 me gusta

** “Una carretera completamente utilizada es un estacionamiento”. Esto es una cuestión de flujo continuo y espacio para la flexibilidad. **

Esto es lo mismo que menciona Tom De Marco en el libro Slack.

El gran problema en Chile no es técnico, los técnicos son de lo mejor que existe en el planeta, el problema es de administración, no existe una escuela de administración, y como indica Tom De Marco en el mismo libro, cuando a un administrador le pasas un pedal para controlar la velocidad del equipo de desarrollo, el tipo apoyael pedal hasta el piso… a esa velocidad no se puede tomar la curva y el auto choca… ¿no es obvio?

Si quieres llegar más rápido, lo más inteligente es planificar la ruta… Y es ahí donde la administración, al menos en Chile, falla estrepitosamente… cuando el proyecto más avanza es cuando puedes planificar la ruta y hacer modificaciones cuidadosas en la ruta para evitar chocar, corrigiendo paso a paso.

Es lo mismo que dicen todos los agilistas. Para llegar lejos y lo más rápido posible debes andar lento, o al menos, a un ritmo confortable. Otra manera de decirlo: sin prisa, pero sin pausa.