Agile 2016 – Atlanta: algunas estadísticas

Agile 2016 - Portada

Un evento Agile 20XX de la AgileAlliance es considerado algo así como un “mundial de fútbol” para los que estamos sumergidos en el mundo de la agilidad. Los más reconocidos exponentes, coaches, autores, gurús, practicantes y una comunidad mundial; se reúnen para compartir y aprender de Agilidad y todas sus expresiones.

A la distancia, estuve siguiendo de cerca el Agile 2016; a través de las redes y de las cuentas personales de varios amigos quienes tuvieron la oportunidad de asistir. Me llamaba mucho la atención sobre el contenido intelectual del evento; las charlas, los temas, las tendencias y demás. Cada día me ingresaba al programa del evento a intentar capturar las presentaciones (algunas veces con suerte, otras no) ó navegando el hashtag #Agile2016 para revisar las fotos y hallazgos de las charlas que habían transcurrido durante el día. Las charlas que más me llamaron la atención las estaba registrando en un excel para poder verlas más adelante.

Al final del evento me preguntaba: “Y bueno, ¿de qué se habló más?, ¿qué tracks fueron más populares?, ¿cuáles fueron los tracks con más charlas?, ¿qué charlas se dieron en un track determinado? ¿cómo puedo consolidar todo y accederlo fácilmente?”. A pesar de que toda la información está en Sched (la aplicación donde se plasma el programa completo); no podía consolidar fácilmente…y se me ocurrió crear una visualización para aquello a partir del excel que estaba llenando (copiando una a una cada charla del sitio web):

Agile 2016 - Talks Analytics (Laptop)

Antes que nada déjenme comentarles que no soy un profesional diseñador de dashboards,  visualizaciones o Tableau, así que disculpas a los que sí saben de estas cosas🙂

Mis hallazgos

277 charlas aproximadamente: muy buena producción

Es mejor decir alrededor de 277 charlas, porque las Lightning Talks no se muestran individualmente (fueron agrupadas en dos espacios durante los días del evento); y porque siento que hay charlas repetidas; algunas que tienen casi el mismo nombre, pero al final  hay algo que las diferencia; por ejemplo:

Unlocking Innovation in Product Discovery – Deuxième Partie (Dion Stewart)

Unlocking Innovation in Product Discovery – Première Partie (Dion Stewart)

Misma charla, mismo autor; pero una sesión diferente, incluso en días diferentes (quizás haga falta una revisión Data CleaningData Quality). Independiente de esto, más de 270 es una excelente producción que reafirma que Agile 2016 es el evento más grande del planeta.

“Enterprise Agile” fue el tópico más conversado en Agile 2016

En función del número de charlas, los cinco categorías más habladas fueron:

  1. Entreprise Agile (27 charlas)
  2. Culture collaboration & Teams (24 charlas)
  3. Experience Report (23 charlas) (aunque ésta es un formato de charla más que una temática; dentro de esta categoría en realidad hay mucho de Enterprise Agile, Culture collaboration & Teams, Project Program & Portfolio Management y Working with Customers, aunque no fueron clasificadas así).
  4. Leadership (23 charlas)
  5. Project Program & Portfolio Management (21 charlas)
  6. Coaching & Mentoring (20 charlas)

Y me voy a permitir incluir Coaching & Mentoring, ya que si separamos las charlas del track Experience Reports (por lo comentado anteriormente), pues es el siguiente en relevancia.

Enterprise Agile es el tópico más conversado en Agile 2016, algo que en verdad me esperaba. Indica una fuerte tendencia hacia abordar problemáticas reales de grandes empresas con Agilidad.

Tras los temas empresariales, los temas técnicos fueron los más populares

Casi en un empate tenemos:

  • Development Practices & Craftsmanship (19 charlas)
  • DevOps (18 charlas)

Interesante, hace uno y dos años atrás el escenario era al contrario, se hablaba mucho de aspectos y prácticas técnicas de ingeniería; más no tanto de temas empresariales. Refleja un cambio en la tendencia de la Comunidad.

“Learning”, un tema que se consolida

El tópico Learning (18 charlas) está enfocado a explorar conceptos y prácticas con el propósito de mejorar el aprendizaje a nivel individual, equipos y organización. Me llamó mucho la atención la inclusión de temas relacionados a: Neurología, dinámica del cerebro, mindset, aspectos de comportamiento, dinámica social e incluso sobre el humor. Y esto me encanta en verdad. Me indica que existe una conciencia creciente en los agilistas de comprender estas dinámicas humanas para lograr cambios sostenibles más allá del método.

Testing & Quality, Working with Customers, UX y Government: empate técnico

Un 40% de charlas dentro del track Testing & Quality exploraban el tema desde una perspectiva técnica (automatización, pruebas de exploración, pruebas de APIs, y así por el estilo). Junto con las charlas de DevOps y Development Practices & Craftsmanship; hacen relevante el contenido técnico dentro del evento. Según este dato, un aproximado de 8 charlas (de 277) enfocadas a presentar Calidad en un sentido amplio más allá del aspecto técnico; bajo para mi gusto.

Junto con Working with Customers (temas de Product Ownership, Product Management y prácticas de colaboración con Cliente), UX y Government; están en el tercer puesto en cuanto a contenido. Sin embargo, me llama mucho la atención de un crecimiento de charlas relacionadas a la aplicación de agilidad en empresas de Gobierno, lo que demuestra una penetración interesante en un sector muy complicado; es difícil pero se puede.

Se habló muy poco sobre el Futuro de Agile

El track The Future of Agile Software Development (IEEE Software) sólo con 5 charlas, intentaba explorar las tendencias sobre Agile en el Desarrollo de software y en general. Pienso que quizás el nombre del track estuvo muy ceñido a desarrollo de software lo que pudo ocasionar que hubieran pocas charlas que se pudieran encajar en el track; debido a que Agile es más grande que desarrollo de software y más si hablamos sobre el futuro. Me hubiese gustado ver más conversación y contenido sobre el tema. No hay que perder la vista de cómo va la industria.

Un evento balanceado

Aunque existió una mayoría numérica de charlas en ciertos tracks que hacen que hayan sido los más discutidos, en realidad fue un evento bastante balanceado en contenido, temáticas y estilos de charlas. Un mérito del equipo organizador y por supuesto de la comunidad participante.

Saque sus propios hallazgos

Obviamente, los hallazgos comentados arriba son mi apreciación personal. Cuando estaba diseñando estas vistas lo vi como algo de mi uso para poder comprender lo sucedido en el evento y resolver mis propias inquietudes personales, sin embargo; espero en realidad que le sea de utilidad para hacer su análisis y localizar el contenido con mayor facilidad. Espero hacer lo mismo para Ágiles 2016…veamos cómo nos va!

Espero me comparta sus apreciaciones con respecto al evento. Gracias por leer y sus comentarios.

Un abrazo!

Johnny

¿Cuál es el siguiente paso después de Agile? Enterprise Agility

Captura de pantalla 2016-07-20 a las 7.01.44 p.m..png

El camino hacia la agilidad Empresarial. Tras 15 años de la firma del manifiesto ágil, Agile ha dejado de ser algo exclusivo para equipos de desarrollo para convertirse en un imperativo de negocio para compañías que desean mayor agilidad en la entrega de sus productos, competitividad de mercado y satisfacción de sus Clientes. A través de esta charla exploraremos la evolución de Ágil a través de los años, el enfoque de Agile hacia lograr la Agilidad empresarial y el rol de los Agile Coaches en este nuevo contexto.

El día de hoy tuve la fantástica oportunidad de participar en otro #DevHangout con los amigos de DevAcademy.la y la compañía de practicantes ágiles de la región. Muchas gracias por la invitación y las preguntas.

Dejo a continuación los enlaces a la presentación y al video para que puedan revisarlos y comentarlos:

Este es un tema que está despertando con cada vez más fuerza en las Comunidades de practicantes Ágiles; en las organizaciones y grupos de discusión relacionados. No significa que no se haya discutido antes sobre Business Agility o Enterprise Agility (de hecho son tópicos ya explorados de los cuales nos estamos empapando los agilistas); pero es importante comprender que Agile dejó de ser exclusivamente un tema para desarrolladores, construcción de productos o de áreas de TI. A medida que esta conciencia avanza, nos exige como practicantes y coaches comprender estos aspectos desde la perspectiva ágil para ayudar a los equipos y compañías para las cuales trabajamos.

Da mucho para conversar y escribir, pero dejémoslo para más adelante.

Muchas gracias sus comentarios.

Un abrazo!

Johnny

El problema con las estimaciones no son las estimaciones

Captura de pantalla 2016-06-15 a las 6.35.01 p.m.

“La propia palabra ‘estimación’ deja en claro que no calculamos un valor exacto, determinístico. De hecho, toda estimación tiene supuestos, y estos supuestos suman incertidumbres.” – Carlos Fontela, Estimaciones y Estadística, CyS Ingeniería de Software (2007)

Hola! Por favor permítame expresar mi opinión con respecto al tema de las estimaciones, y #NoEstimaciones. El problema con las estimaciones no son las estimaciones. Las estimaciones son sólo eso, aproximaciones sobre la magnitud de algo. No son valores determinísticos que buscan exactitud sobre el sujeto de la estimación. Bajo este contexto, no existen “estimaciones equivocadas”.

El problema con las estimaciones (Estimates) -sobre todo en el ámbito del desarrollo de software- es que se usan como fechas de finalización de los proyectos (deadlines), sobre las cuales se asocian costos y se asignan equipos para lograr cumplir un alcance que por naturaleza es variable, en un entorno complejo completamente alterable en función de los cientos de factores que provienen de la misma naturaleza del desarrollo de software y de la naturaleza de lo que queremos construir. Complejidad.

Sin embargo, el proceso de estimación (Estimating) desde mi punto de vista es útil. Y aquí hago una pequeña pausa para resaltar la diferencia entre Estimating (la dinámica de estimación) y Estimates (los valores resultantes de la dinámica de estimación). Quizás tengamos un problema en castellano, ya que ambas tienden a traducirse como lo mismo: “estimación” o “estimaciones”.

Desde mi punto de vista, el proceso de estimación es un ejercicio de entendimiento compartido durante el cual los participantes descubren y discuten aspectos que les permite comprender en mayor medida los desafíos de la construcción de lo que estén estimando. Por ejemplo -muy popular dentro del contexto Scrum-, cuando Usted observa a los equipos en una dinámica de Planning Poker, lo valioso es la discusión que se genera frente a la percepción de la complejidad de la cosa a construir y no por el número en sí mismo. Las estimaciones (estimates) pueden ser útiles o no, más el proceso de estimación es valioso.

“Una buena estimación es aquella que provee una visión de la realidad del proyecto suficientemente clara como para permitir a un equipo decidir correctamente cómo controlar el proyecto de modo tal de cumplir sus objetivos”. – Steve McConnell, Software Estimation: Demystifying the Black Art

Las estimaciones (Estimates) pueden ser expresadas en la unidad que el equipo acuerde: pueden ser horas, pueden ser puntos de historia o pueden ser bananas. Más adelante veremos cuántas bananas nos comimos en una unidad de tiempo. Son simplemente etiquetas de equipo que nos facilitan el proceso mental de comprender qué significa una banana.

El verdadero problema es enfrentar la necesidad de “predictibilidad”

Imagine que Usted llega a la cola en una oficina de su banco (a veces es necesario ir allí hasta que tengamos una banca totalmente digital). Entonces Usted llega a la cola y puede apreciar que hay varias personas antes que Usted. En ese momento le llama su esposa y le pregunta: “¿En qué tiempo te desocupas? Mira que tenemos que ir a donde mi mamá.”; Usted responde: “Okay amor, en esto momento no puedo hablar porque estoy en el Banco, pero ya te escribo por Whatsapp o algo.”

Cuelga y se dice a así mismo: “Vamos; soy ingeniero, trabajo en proyectos, también sé algo de ágil…esto no debería ser un reto para mí…” y comienza. Recordará sus años de Teoría de Colas y dirá: “Ley de Little!!…claro”. El tiempo promedio de espera en la cola es igual al número promedio de personas en la cola dividido para el tiempo promedio de atención. Ya está! Cuenta: hay 20 personas antes que Usted, toma el tiempo desde que una persona llega a la caja hasta que sale (digamos 3 minutos) y listo, matemática simple: 20 personas + Usted (21 personas) / (1 persona cada 3 minutos) = 63 minutos, aproximadamente.

Pero espere, antes de que escriba a su esposa por la respuesta recuerde algo; el señor Little decía antes: “En un sistema estable el tiempo promedio de espera es….blah, blah.”. Un sistema estable, ¿qué significa? Serían 63 minutos si todas las personas realizarían el mismo tipo de transacción exactamente, y que la persona en la caja se demore exactamente ese tiempo de atención por cada transacción sin cansarse. Además, pasan cosas: “se fue el sistema!” (muy típico al menos en mi país), es el descanso de la persona en la caja, lo reemplaza otra persona que está aprendiendo a usar el sistema, una persona se cuela por la parte de adelante, se va la energía eléctrica, habilitan una nueva caja, etcétera.

En otras palabras: Variabilidad. Variabilidad interna y externa al sistema. Estos y otros posibles cientos de factores que influyen en el comportamiento general del sistema. Con los equipos ágiles es muy similar, la diferencia es que estos factores pueden ser muchos pero en verdad muchos más.

Imagine que el siguiente gráfico representa la Velocidad de un equipo ágil en el tiempo:

Captura de pantalla 2016-06-15 a las 6.14.54 p.m.

Fíjese que en los primeros sprints la distancia entre su mejor velocidad histórica (la línea superior del rango) y su peor velocidad histórica (la línea inferior del rango) es más ancha; y a medida que el equipo corre sprints, esta distancia tiende a estrecharse. Esto es gracias a varios motivos, pero obviemos eso por ahora. Estamos tranquilos allí en la oficina y nos hacen la pregunta típica: ¿y en cuánto tiempo estará la feature X si trabajamos con el Equipo 1? Vale, hagamos el ejercicio de proyección:

Captura de pantalla 2016-06-15 a las 6.23.03 p.m.

En función de su desempeño histórico, podemos deducir un rango de fechas en el que equipo puede entregar la feature: entre la fecha X y Z; y podemos contemplar escenarios: en un mejor escenario la fecha X, en un escenario esperado la fecha Y, y en un escenario pesimista la fecha Z. El rango de fechas será más grande mientras más temprano en el tiempo tome su desempeño para proyectar (más alta es la varianza). Entre más estrecho el rango, la probabilidad de entrega es mejor.

Pero no se olvide, complejidad y variabilidad: ¿este equipo conoce el dominio y las tecnologías de implementación?, ¿ha trabajado antes sobre esto?, te comento que la mitad del equipo se va de vacaciones por esa época, etcétera. Variabilidad externa e interna. No hay ciencia exacta.

Entonces, ¿qué le decimos a la esposa?: “Amor, ve avanzando…allá te veo.”🙂

¿Quiere ser predecible? Reduzca la variabilidad

Hay que reconocerlo: no se puede ser predecible en contextos complejos y sujetos a variabilidad como el desarrollo de software; entre más complejo el sistema y más elementos que añadan variabilidad menos preciso seremos. Es la realidad.

Si queremos lograr un mejor nivel de predictibilidad debemos trabajar sobre la variabilidad. La variabilidad interna (al alcance del equipo):

  • Reducir el batch size (reduzca el tamaño de los ítems de trabajo o Historias)
  • Revise el tamaño de la cola (ítems en el backlog)
  • Clasifique el trabajo (tipos de ítems de trabajo)
  • Establezca restricciones WIP (en cuántos ítems podemos trabajar en función de nuestra capacidad)
  • Enfocarse en generar flujo
  • Identificar cuellos de botella y supeditar el flujo a las restricciones
  • Equipo cohesionado trabajando junto durante un tiempo, no lo desarme
  • Otros.

La variabilidad externa (más difícil y a veces fuera del alcance del equipo):

  • Evitar distracciones organizacionales
  • Evitar multi-tasking o trabajar en varios proyectos al mismo tiempo
  • Contar con ceremonias de sincronización y alineamiento
  • Mucho feedback con Clientes y Stakeholders, entre otros.

Y nada, las cosas pasan…no se puede contener todo y no sabemos lo que sucederá hasta que pasa.

Con respecto a #NoEstimates

#NoEstimates es una perspectiva -y movimiento- que se enfoca en medir la entrega real de valor, por sobre obtener “medidas” a piori para saber cuánto trabajo se puede realizar y en qué tiempo. Es decir, en lugar de ponernos a obtener estas medidas (estimates), mejor hagamos el trabajo, entreguemos y luego sabremos realmente cuánto hicimos. En este contexto, las estimaciones (estimates) son desperdicio (“waste” desde el punto de vista Lean). De acuerdo, como mencioné: el número en sí mismo no es lo importante; más no así el proceso de estimación. Para #NoEstimates tanto el proceso y el resultados son desperdicio; yo simplemente discrepo con respecto al proceso. El proceso de estimación -independientemente del número obtenido- puede ser valioso para los equipos.

Pensamientos finales

A modo de resumen:

  • Las estimaciones (Estimates) pueden ser útiles, pero es mucho más útil contar con la información histórica de entrega real.
  • El proceso de estimación es un proceso de entendimiento compartido, ayuda a comprender la magnitud del problema, identificar riesgos y llegar a consensos.
  • El problema no son las estimaciones, es problema es enfrentar la necesidad de predictibilidad.
  • Los sistemas complejos poseen variabilidad, a mayor variabilidad peor predictibilidad. Nunca será 100% predecible, abrace la variabilidad.
  • Si desea ser predecible -en la medida de lo que eso signifique- entienda y trabaje con la variabilidad interna y externa.
  • #NoEstimates en un enfoque hacia medir el valor real logrado en lugar de obtener cosas medidas a priori, no podría estar más de acuerdo.
  • Nunca deje esperando a su esposa…o a su suegra🙂

 

Gracias por leer y por sus comentarios.

Johnny

Referencias

Ecos del Scrum Coaching Retreat Latinoamérica 2016

13147521_10155371117948084_7847866123802406753_o

Durante el fin de semana anterior tuve el privilegio de participar del Scrum Coaching Retreat Latin-American 2016 que se llevó a cabo en Cartagena de Indias, en el que un grupo de apasionados Agile Coaches de México, Costa Rica, Panamá, Venezuela, Colombia, Ecuador, Chile y Argentina; nos juntamos para aprender y compartir, en busca de continuar creciendo como mejores Coaches. Fue un tiempo fantástico de discusión, aportes, risas y descubrimiento personal junto al mar.

Al ser la primera vez que participaba, tenía mucha expectativa sobre el formato y sobre el objetivo general. Tras la bienvenida del Equipo organizador, arrancamos con una primera dinámica muy divertida facilitada por Luis Mulato, en verdad no sé si tenga nombre; pero tenías que construir una casa junto con un compañero, donde un tercero se albergaría, a la voz de “¡terremoto!!” se tendría que reconstruir casas con otro compañero y albergar a una persona diferente. Linda dinámica, muchas risas; excelente para romper el hielo.

13174076_10155371114323084_5573825229406206359_n

Después una presentación cruzada entre nosotros, para conocernos y saber de dónde veníamos. A continuación, la siguiente dinámica facilitada por el Hada de la Facilitación Gráfica, Claudia Sandoval; el Café del Mundo (World Coffee). Primicia para mí, no lo había escuchado antes, estaba emocionado. Claudia nos llevó en un viaje de reflexión y de propuesta a través de varias preguntas poderosas; que poco a poco me fueron aclarando sobre el propósito de las actividades que vendrían, básicamente: “¿Cómo podemos ayudar a los Coaches Ágiles de la Comunidad Latinoamericana en los desafíos de su labor y al mismo tiempo ayudarnos en ser mejores coaches?”. Me conmovió y me enganchó.

Luego de esta concientización, comenzamos con un Market Place de aquellos tópicos que quisiéramos abordar para ayudar a los Coaches Ágiles tomando en cuenta los desafíos a los cuáles nos estamos enfrentando y hacia dónde está yendo la Agilidad.

Fruto del agrupamiento, las ideas convergieron en cuatro grandes temas y al mismo tiempo en 4 grandes propósitos, donde cada uno sería abordado por un equipo. Así que nos nombramos, creamos nuestra identidad y arrancamos nuestros sprints. Los nombres de los equipos me parecieron sensacionales, comenzaba la aventura.

Yo estaba en el grupo Agile Inc. (cualquier parecido con Monsters Inc. es pura coincidencia🙂 ). Bajo nuestra responsabilidad: el brindar herramientas a los Agile Coaches para lograr convencer a altos Ejecutivos sobre los beneficios de la Agilidad e involucrarlos activamente en procesos de transformación. Debo reconocer que en nuestro equipo se respiraba mucho amor:

thumb_IMG_7665_1024

Arrancamos. Como era de esperarse, al final del Sprint deberíamos mostrar a los Stakeholders y al resto de los equipos nuestro progreso (Review plenaria) y tendríamos nuestra Retrospectiva individual por equipo. Durante el sprint noté algo interesante y que el gran Ricardo Colusso mencionara al iniciar; estábamos teniendo los problemas y comportamientos que tienen los equipos de desarrollo a los que nosotros acompañamos. Vivíamos las etapas de formación de un equipo y los desafíos que eso conlleva.

Lo que pasaría después me asombraría en una magnitud tal que me costaba creer que lo que estaba viendo haya sido concebido en el tiempo de un sprint. Totalmente sorprendido por la calidad, profundidad y conocimiento demostrados en los productos de cada equipo; de altísimo nivel, impecables, totalmente aplicables y útiles para muchos contextos. El poder de co-creación del grupo no tenía límites. Gratamente sorprendido.

El aporte a la Comunidad Latinoamericana

Nada resume mejor lo logrado en este evento que la siguiente imagen creada por Claudia:

Nuestro aporte a la Comunidad

Brevemente:

Agile Yoda: aportan un lienzo y más herramientas de colaboración en una caja de herramientas para el desarrollo de las competencias de un Agile Coach; enfocado en dos sentidos: el SER y el HACER. Lo que me encantó en este equipo fue que abordaron el lado “soft” que debe desarrollar un coach para su labor, el SER. Me conecté mucho con el trabajo de este equipo.

Ágil Cultores: aportan un framework para medir el nivel de Agilidad dentro una Cultura, basado en el modelo de Schneider; y al mismo tiempo proponer técnicas o herramientas al Coach para guiarlo en cada caso. Me encantó que su enfoque estaba basado en la premisa de que en cualquier tipo de cultura -incluso las más dura de Control- puede existir Agilidad, y que hay potenciarla o mantenerla. Como yo lo veo, este trabajo tiene una potencialidad de poder llevarse a todo el mundo, seguramente asistiré a charlas donde se hablará de este framework.

Agile Inc.: aportamos con el Agile Enterprise Coaching Toolkit Journey, una guía para el Coach ágil que desea llegar a altos Ejecutivos con los argumentos apropiados, en cada etapa existe un grupo de herramientas que pueden usar para prepararse antes o durante de una etapa adecuada. Me gustó mucho el enfoque que tomamos dentro el grupo de hacer empatía con el Directivo de Alto nivel, y modular nuestro lenguaje para ser asertivos; me gustó las discusiones que generamos y cómo complementamos nuestras experiencias empresariales. A partir de mañana, este journey es mi mejor amigo en mi labor del día a día.

Homo Sapiens Sapiens: aportan el Sapiens Sapiens Agile Learning Framework, además de lo fantástico del nombre, esta herramienta propone nuevos niveles y jornadas para lograr aprendizaje de forma efectiva y ágil. Me encantó que posee y demuestra sólidas bases científicas sobre cómo aprendemos los seres humanos, desde el punto de vista de funcionamiento del cerebro, motivación intrínseca basada en el trabajo de Daniel Pink, escenarios para el mejor aprendizaje; es muy visual y basada en tarjetas, es genial….casi un trabajo de doctorado!

Todos los recursos son accesibles aquí. Mi invitación a revisarlos, usarlos y entregar feeback hacia los equipos -y por supuesto sumarse; la idea es que el trabajo pueda evolucionar y refinarse.

Aquí y aquí podrán ver algunas las fotos del evento.

El Cierre

Durante la tarde del tercer día llevamos a cabo un Open Space algo diferente gracias a nuestros compañeros Homo Sapiens Sapiens; quienes la “hackearon” en buena manera para mostrarnos nuevos enfoques de aprendizaje, como bien lo mencionaron: “aprender a aprender”. Armamos varios tracks donde se propusieron temas muy actuales y de atención para coaches ágiles: el uso de Story Telling para influenciar la Cultura, Learning 3.0, escalamiento ágil con SAFe, siguientes pasos en la maduración de los productos generados, Soft Skills para Agile Coaches, entre otros. En este último participamos haciendo juegos de roles, simulando escenarios difíciles a los que se enfrenta un coach y jugando para intentar resolverlos; actuamos un poco y fue una gran experiencia. Recordé que sin importar lo que digan los libros, una cosa es leerlo y otra es vivirlo. Nada fácil ah! Muy divertido y altamente retador.

Lo más lindo del cierre fue hacer “hakas” entre nosotros. Nos creíamos jugadores de rugby antes del partido (estoy con una sonrisa gigante en mi rostro mientras escribo esta parte). Gritamos, hicimos coreografías y demás. En verdad que sentimos de corazón la identidad que generamos durante todo el evento, una relación de integración y colaboración que seguirá por mucho tiempo.

¡Muchas gracias a todos!

WhatsApp-Image-20160509

En lo personal fue una experiencia formidable. Muchos amigos apasionados con la Agilidad y su propósito de llevar bienestar a los equipos y organizaciones. Mucho talento y nuevo conocimiento. Y una introspección personal que me ayuda a reafirmar el rumbo de mi carrera. Muy enriquecedor desde el punto de vista profesional y personal.

Quiero agradecer profundamente al equipo organizador formado por: Lucho Salazar (el Ministro), Ricardo Colusso (El Sensei), Luis Mulato (El Dinamizador), Claudia Sandoval (el Hada de la Facilitación gráfica), Juan Daza (El Señor de los Medios) y Neider Tapia (El Guía). Quiero agradecer a mi equipo Agile Inc.: Víctor, Pedro, Wilmar, Rose, Linette, Andrés, Cris; el espíritu de equipo se mantendrá por mucho tiempo más. Y a todos los asistentes, por sus aportes y argumentos, por las sonrisas, por las cervezas y por ayudarme a crecer.

13040938_10155371123673084_7689850903519929114_o

Gracias, un abrazo gente!!

Johnny

Agilistas: Empatía con el Management

2_5

En los procesos de transformación ágil en los que he podido participar, he visto que generalmente las personas en las que se acumula mayor presión generada por proceso -y quizás mayor frustración y “sufrimiento”- son aquellas que pertenecen a la capa media de gestión, el middle-management: gerentes, directores, coordinadores, líderes.

Veamos un par de escenarios. En un proceso de adopción bottom-up, Agile y métodos como Scrum empoderan a los equipos y les invita a desatar todo su talento y autonomía. Toman sus decisiones, definen acuerdos, fomenta el compromiso y el desarrollo de sus habilidades tanto técnicas como de trabajo en equipo. Normalmente, están muy motivados y entusiastas…aunque no se tenga toda la certeza de algunas cosas.

Desde una perspectiva top-down, los beneficios de la Agilidad hacen eco el staff Ejecutivo -Presidentes, Vicepresidentes y altos Directivos. Mejorar el Time-to-Market, incrementar la Calidad, procesos más eficientes, mayor satisfacción de los Clientes, alineamiento y visibilidad, flexibilidad; son cualidades deseables de un negocio saludable en vista de adaptarse, mejorar y crecer. Estos elementos coinciden con las expectativas de negocio y el lenguaje estratégico. Quizás con algo de escepticismo, pero el mensaje es muy bien recibido en este nivel.

De pronto, las personas del nivel medio de gestión se ven en una reunión en la que ya sea, por arriba o por abajo; el mensaje principal es: “Nos vamos hacia Agile!”. Al principio posiblemente no se tenga mucha conciencia de lo que esto significa: “Una metodología más, ¿no?”, pero no pasa mucho tiempo en evidenciarse que la propuesta hace cimbrar los cimientos en la forma de cómo se conciben el trabajo, los proyectos, la gestión; y los propios paradigmas respecto a la ingeniería y dinámicas de equipo; sin hablar de hábitos y de la cultura de la empresa.

Comienza entonces la tensión.

El sufrimiento en la capa intermedia

Enfocándome en los Gerentes de proyecto, al ser responsables por los resultados de la ejecución, sienten la presión de lograr las promesas de negocio sin contar con mucha certeza de cómo hacerlo en la nueva dinámica de trabajo. Y ven poco a poco como muchas de las funciones de las que se encargaban habitualmente se delegan a varios roles encarnados por otras personas (comúnmente): la gestión del alcance, monitorización y métricas, lineamientos de organización de equipos; etc.

Para empezar, en métodos como Scrum no existe de forma explícita el rol de Gerente de Proyectos, lo que hace pensar de que este rol -más no sus funciones-, es innecesario en entornos ágiles. No comparto, pero sí que hay consultores y coaches que así lo manifiestan. Lo mismo sucede con Arquitectos, Directores de Programa, Líderes funcionales, etc. Es claro, Scrum fue creado bajo una visión de trabajo creativo en equipo (no sólo de desarrollo de software), no estaba pensado para enfoques empresariales tradicionales.

Las destrezas y habilidades que hicieron grandes a estos gerentes ya no son requeridas de la forma como la venían desempeñando. La planificación a largo plazo y el levantamiento del detalle temprano no van más, adiós a la negociación del triángulo de acero como lo conocíamos, SRSs, documentos funcionales pesados, análisis y arquitecturas detalladas up-front quedan en el recuerdo. Técnicas, artefactos y métricas comunes (WBS, Gantts, CPI, SPI, etc.) son reemplazadas rápidamente con planes de Release, Burndown charts,  Velocidades, Story Maps, etc. Hay que re-aprender gestión de proyectos de software.

Los consultores y coaches comienzan a cuestionar su lenguaje, hábitos y estilos de liderazgo, “Ya no digas recursos, son personas” (comparto plenamente), algo tan arraigado en la cultura de gestión . Ya no se puede pedir al equipo que se queden hasta más tarde porque vamos atrasados, ahora el equipo decide, etc., etc.

La organización y el mismo Gerente comienzan a preguntarse sobre la relevancia del rol tal como se conocía, y definitivamente debe existir una transformación que tiene implicaciones a nivel funcional y por supuesto a nivel humano. Comienza entonces un estrés más profundo a nivel personal.

Empatía con el Management

¿Podría existir un milagro tan grande para nosotros, que el de mirar a través de los ojos de otros por un instante?

– Henry David Thoreau

Existe un cierto antagonismo entre una gran parte de agilistas y los roles de gestión. También me pasó. Recuerdo mis días de Scrum Developer y de Scrum Master que junto a los demás compañeros del equipo nos quejábamos de ellos y decíamos que deben desaparecer, “No Managers!”, nos auto-organizamos ya no son necesarios, no aportan valor, son dinosaurios, Holacracy y así por el estilo…todo mientras nos tomábamos una cerveza luego de la retro y andábamos en zandalias por todo el lugar. Sí, era divertido, era joven :)…pero les comento, que esto está alejado del propósito real de la Agilidad que es buscar mayor bienestar de las personas mientras entregan valor a través de su trabajo.

Yo no creo que los Gerentes sean malas personas. En verdad. No creo que digan “son recursos” porque vean a los equipos como baterías que se pueden reemplazar cuando se gasten (al menos los buenos Gerentes no lo ven así). Pienso que este lenguaje, mindset, hábitos y demás son producto de su formación y por supuesto de la organización, del sistema. Pienso que al igual que el resto, ellos quieren que el negocio mejore y que la empresa y los equipos crezcan. Se están enfrentando a una realidad que les desafía a re-aprender muchas cosas, crecer profesionalmente y mejorar personalmente…y es nuestra labor como coaches y agentes de cambio ayudarlos a encontrar su camino.

¿Qué se puede hacer? Aquí algunas sugerencias :

Ayúdelos a encontrar su lugar

Los roles y funciones se vuelven confusos en un proceso de adopción ágil, es un momento de transición. Como mencioné, Scrum no muestra de forma explícita un rol de gerencia, sin embargo hay compañías que mantienen el rol. Si existe, ayúdeles a comprender que el paradigma de gestión cambia profundamente con Agile, de Gerentes a Líderes de Servicio; las personas no se gestionan, el sistema se gestiona; ahora son habilitadores para que los equipos fluyan, preocuparse auténticamente en el bienestar de los equipos, entre otros.

Si este rol desaparece de la organización, ayúdelos a identificarse con los nuevos roles y hágale entender las destrezas y responsabilidades requeridas para ellos. Quizás le guste más el tema de ser Product Owner, o se enfoque más hacia el crecimiento del equipo y se convierta en Scrum Master; o sus equivalentes en escala (Product Manager/Chief Product Owner, Chief Scrum Master, etc.). Si usa otros frameworks, invítelos a revisar los roles y ofrezcan la guía necesaria donde con sus destrezas y mentalidad sean apropiados y se sientan a gusto.

Ayúdelos a prepararse

Haga charlas, hable sobre los valores y principios, métale Management 3.0 por los ojos, envíenles información, artículos, libros, hábleles de las certificaciones (muchos agilistas me matarán aquí por el tema de las certificaciones🙂 ), motívelos a aprender. Ayude a comprender lo subyacente detrás de los métodos. Explíquele los artefactos y ayúdelos a dibujar tableros para sus actividades, a ellos también les gustaría embarcarse en la onda de pegar papelitos y lo demás, apóyelos.

Involúcrelos

Hágalos partícipes de las iniciativas de cambio durante la transformación ágil. Trabaje junto con ellos en alguna de ellas y luego pídales comprometerse ellos solos, o en equipo de directores, como sea. Conviértalos poco a poco en agentes de cambio y en parte del equipo de transformación. Si logra de a poco cambiar su mentalidad y comportamiento, serán faros y guías para propagar la cultura que se desea en la organización.

Evite el “ellos” vs “nosotros”

Intégrelos al trabajo del equipo, invítenlos a las ceremonias y que perciban la agilidad de la mano de los equipos….por supuesto, hable con los equipos para que tengan apertura necesaria y que sean bien recibidos. Discutan los tableros, argumenten de forma sana y genere la cercanía necesaria para hacerlos sentir “parte de”. Ya basta de “los ágiles” y los “no ágiles”.

Acompáñelos

Hágales coaching. Converse con ellos, haga sesiones One-to-One, lleven una bitácora de coaching, entregue consejos para que mejoren sus destrezas personales y habilidades blandas. Ayúdelos a mejorar como Líderes y como seres humanos.

Pensamientos finales

Como agilistas siempre estamos hablando de empatía: empatía con el usuario, UX, Design Thinking y más. Mi invitación es aplicar esta misma habilidad de “empatizar” -e incluso las mismas herramientas y técnicas que usamos en los equipos- con las personas en la mitad del sánduche (¿por qué no?: haga un Empathy Map, cree Personas). Los procesos de transformación ágil representan un cambio trascendental y muy profundo dentro de las empresas, con impacto a nivel organizacional, cultural y personal. Póngase en los zapatos del management, mire a través de sus ojos, sienta con su corazón. Esta capa es fundamental para el éxito de la transición, para obtener los beneficios esperados y para generar la cultura ágil que queremos ver en todas las organizaciones a las que visitamos.

Como dirían acá en Colombia: ¡Hágale mija! o ¡Hágale mijo! :)

Gracias por leer.

Johnny

Thoughts on Agile Acceptance

“It’s the Agile Manifesto we should all be upholding. It’s adapting to change over following a plan which makes us agile, not which framework we choose or even which certifications for frameworks we hold. Let’s not forget our roots! What’s most important are those 4 values and 12 principles of the Agile Manifesto. In fact, the Agile Manifesto is framework agnostic. Basically, Scrum, SAFe, LESS, or whatever isn’t the only way to be Agile. There is no one right way!”

Great post and agree!

i.am.agile

Cara Penyak, an Agile Project Leader on my team, volunteered at the Global Scrum Gathering in Orlando last week and brought me back a new friend, Lee Allison.  Lucky me!  I don’t even need to attend a conference to make new friends.  Anyhow, Lee asked me to review his latest blog post “Agile Acceptance” and I thought what better topic to re-blog than this.
A framework is defined as “a basic structure underlying a system, concept, or text.”  Seems pretty straightforward but, among the agile community, frameworks are super polarizing for whatever reason.  If frameworks represent a “basic structure” then they are surely intended to be adapted.   Who cares which scaling framework you start or end with?  
It’s the Agile Manifesto we should all be upholding.  It’s adapting to change over following a plan which makes us agile, not which framework we choose or even which certifications for…

Ver la entrada original 51 palabras más

3 razones del por qué sin Agile Testing no está siendo Agile

3_stones_on_wood

Con relativa frecuencia -más de la que me gustaría- observo como las compañías y sus equipos adoptan Scrum para el desarrollo de software excluyendo deliberadamente a las personas de pruebas dentro de los equipos. Ellos consideran aún que el “desarrollo” significa únicamente codificación, manteniendo a las personas de testing alejadas del equipo, sin participar en las ceremonias e incluso en ubicaciones distantes físicamente. Cuando les pregunto sobre las pruebas funcionales durante el sprint, normalmente me responden: “Es que hacemos TDD…las pruebas funcionales las hacen al final y nos reportan los bugs en el sistema de tracking de incidencias.”

Lo que se puede observar es que se conserva el paradigma de que las pruebas es algo que viene después, realizado por un grupo de personas que está más allá, que es responsabilidad de alguien más; y no existe nada más alejado de la Agilidad verdadera.

Ahora quiero sintetizar en tres razones la importancia de comprender y asumir la disciplina de Testing y cómo ésta se evidencia en Agile:

1. Muchas de las promesas de Agile provienen del Agile Testing y de la automatización

El desarrollo ágil habla de mejorar el Time to Market, de aumentar la calidad, de incrementar la productividad y predictibilidad, y mejorar la motivación. Pues bien amigos, les aseguro: mucho de estas promesas provienen del ejercicio consciente del Agile Testing dentro de los equipos, más un nivel decente de automatización de pruebas e integración continua; todo esto en camino hacia habilitar Continuous Delivery. Agile no es magia, sigue siendo software que debe ser diseñado, construido y probado; el cambio está en el enfoque colaborativo y de integración en lapsos cortos a través de un equipo que combina sus disciplinas; es lo que marca la diferencia.

Imaginen el escenario donde se codifican historias en un sprint y luego al final le dan a un Tester o equipo de Testing que las prueben. Probablemente se encontrarán errores que serán reportados y corregidos por los equipos durante el sprint que corre. Al final del segundo sprint la persona o equipo de Testing deberá verificar la corrección de los bugs anteriores más la revisión de las historias del nuevo sprint; y no sólo eso; sino hacer una regresión de los flujos de negocio más importantes que involucra también historias del primer sprint. Ahora imaginen este ritmo para el tercer, cuarto, quinto sprint. Es una bola de nieve, y esto es grave. Las personas de Testing estarán con trabajo acumulado que supera su capacidad, la presión hace que reduzca el ámbito de pruebas y que minimice sus casos tomando en cuenta lo que considera más urgente y no lo más importante, la calidad de los casos de prueba disminuye, los managers estarán encima de ellos porque se evidenciará retrasos al no tener historias probadas; la motivación de este equipo estará por lo suelos. ¿Y los developers, pueden ayudar? No, están ocupados haciendo más historias😦

Okay, esto no es Ágil. Son como cascaditas más pequeñas, nada cambió a excepción a que ahora generamos más código basura en sprints. Recuerdan aquel principio que dice:

“Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor.”

– Principios del Desarrollo de Software Ágil, Manifiesto Ágil

2. Las personas de pruebas no son ciudadanos de segunda clase, son profesionales talentosos

Existe una percepción generalizada en la industria de que los testers son un tipo de profesionales de segunda clase, que no son tan importantes o necesarios o geniales como los desarrolladores, tienen salarios menores, hay una proporción mínima de testers en las empresas comparados con los desarrolladores, hay muy pocas capacitaciones -incluso en la Agilidad- y normalmente están en una sala aparte donde su trabajo se reduce a encontrar bugs. Recuerdo alguna vez que estaba con un equipo de gerentes trabajando en la planificación de un proyecto y decían: “Necesitamos aproximadamente unos 50 developers.”, “Okay ¿y los testers?”, “con dos juniors ya tenemos!”. La disciplina en sí mismo está desvalorizada. Agile es contrario a todo esto, no puede seguir pasando. De hecho, cuando en las organizaciones veo este tipo de escenarios, son para mí olores de que su nivel de Agilidad está lejos de ser verdadero a pesar del uso de Scrum o cualquier framework.

Pues bien, la verdad es que sin nuestros amigos testers no podemos tener buen software ni software de valor. El testing de software es para mí una disciplina que requiere talento, preparación continua y un mindset diferente al de los desarrolladores para diseñar estrategias de mejor cobertura funcional y mejorar el diseño mismo del software. Las empresas y los equipos deben darse cuenta de lo trascendental de este rol.

3. Agile Testing es igual a colaboración

El Agile Testing es el pegamento entre las expectativas de negocio y la construcción. El tester es parte del equipo y es un puente de colaboración y comunicación entre el Product Owner, Stakeholders y developers más gente de operaciones, quienes codifican y mantienen los requerimientos para satisfacer esas necesidades.

Por ejemplo, el Tester trabaja junto con el PO y le apoya en:

  • Mejor comprensión de las necesidades
  • La preparación y revisión de historias
  • La definición de Criterios de Aceptación (a partir de los cuales se pueden generar Escenarios de Prueba)
  • Mejor entendimiento del Dominio de Negocio
  • Identificar dependencias entre Historias

El Tester trabaja junto con los Developers y les apoya en:

  • La definición estrategias de prueba para las historias
  • Apoya en la automatización de pruebas funcionales (ATDD)
  • Detecta y notifica bugs
  • Entrega feedback temprano de las historias
  • Sugiere mejoras funcionales y de usabilidad

Por su lado, el Tester trabaja en:

  • Preparación de la estrategia de pruebas del sprint
  • Preparación y mantenimiento del Ambiente de Pruebas
  • Preparación de Casos y Data de Pruebas de las historias del Sprint
  • Validación de “Done” de las Historias
  • Registro y notificación de Bugs
  • Aceptación de la Historia junto con el PO
  • Llevar las métricas de Calidad de Software

El Tester trabaja junto con otros Testers y equipo de operaciones en:

  • Diseñar y preparar la estrategia general de pruebas
  • Colaborar junto con los Stakeholders en las pruebas UAT
  • Identificar los escenarios y flujos de negocio más vitales
  • Difundir el Plan, Casos de Pruebas para Integración
  • Ayuda a conocer la salud del entregable
  • Identifica dependencias
  • Apoya en las pruebas de requerimientos No funcionales
  • Apoya en las pruebas de sistema end-to-end

Como pueden apreciar, son funcionales muy importantes.

Pensamientos finales

Nuevamente, Agile es más que adoptar y adaptar frameworks. Entiendo que existe un frenesí en la industria, pero sin una verdadera comprensión de los valores y principios detrás de las prácticas, sólo son cascarones. El Agile Tester es parte del Scrum y es el mejor amigo de los developers, se comporta como un compañero cuyo objetivo es ayudar a mejorar el software, dar feedback continuo y evitar a aparezcan errores en lugar de ser sólo un filtro para detectarlos, participa activamente en las ceremonias y es parte del éxito del equipo. En mi experiencia, es un rol vital y no puede existir agilidad sin este apoyo.

Gracias por leer y por compartir sus experiencias.

Johnny