Balance organizacional: más allá de la conciencia de Equipo

1

¡Ya una semana y un poco más desde el Ágiles 2016! Esta fue una ocasión muy especial y gratificante para mí…sí algo cansada también; pero una experiencia muy satisfactoria al reunirnos nuevamente con los viejos amigos, hacer otros nuevos y juntarnos para compartir y aprender de lo que nos gusta: Agilidad, sobre ayudar a mejorar la vida de personas y organizaciones.

Al mismo tiempo muy complacido y sorprendido del nivel de los agilistas de la región. Observé y participé de muy buenas charlas, vi muchos reportes de experiencia y me enriquecí del aprendizaje compartido de los practicantes ágiles a partir de su experiencia de probar cosas en sus equipos y organizaciones; de seguir creciendo en agilidad. Esto fue muy bueno.

Mientras conversaba con varias personas y lanzaba algunas preguntas, pude constatar la madurez en la aplicación de prácticas ágiles a nivel de equipo y de proyecto: la aplicación de mejores técnicas para el tratamiento de backlogs, mejores retrospectivas, un enfoque más amplio del rol de Scrum Masters, Product Owners y Agile Coaches, patrones y técnicas para formar equipos ágiles y mejorar su auto-organización, contratos ágiles, sobre cómo mejorar el aprendizaje y demás. Esto fue muy chévere, sin embargo pude notar que la mayoría de argumentos fueron dados bajo una perspectiva de equipo.

cuk4z7jw8aexejl

Lori Leitgeb en Ágiles 2016 – Keynote speaker

Durante su Keynote, Lori Leitgeb hablaba de casos donde el equipo lograba ser tan auto-organizado, tan cohesionado y casi tan independiente que paulatinamente perdían el foco o no contaban con la claridad suficiente del impacto de lo que construían sobre el negocio y sobre la compañía a la cual pertenecían y de cómo soportaban la visión. Las decisiones que tomaban los equipos que mencionaba estaban enmarcadas dentro del contexto de ¿cómo podemos ser mejores equipos?, ¿cómo mejoramos técnicamente?, ¿cómo aplicar mejores prácticas? Y así por el estilo.

culcyu6w8aeavbj

Resumen de la charla ketnote de Lori Leitgeb en Ágiles 2016 – Facilitación gráfica gracias a Ana Betancur

Las organizaciones no son exactamente una democracia

Algo que hay que reconocer es, que hasta que lleguen enfoques como “Holacracy”, “Sociocracy”, organizaciones Líquidas y “Teals” a nuestras geografías; la mayoría de las organizaciones que conocemos y en las que participamos no son una democracia (sin embargo, felizmente existen notables excepciones en Latinoamérica). Comúnmente, el equipo no puede decidir sobre qué línea de negocio trabajará la compañía, qué mercados abordarán o qué sueldos van a ganar. Sí, no es que me guste mucho…no obstante es una realidad (y como agilistas trabajamos para lograr mejores matices).

De aquí que es necesario para equipos y los practicantes ágiles tomar conciencia que somos parte de un ecosistema, que estamos circunscritos dentro un entorno empresarial y social, y que hay vida más allá del código: gerencias, sistemas de gestión, estrategias de mercado, impacto de negocio, proveedores, inversionistas y demás; y que cada elemento de este gran sistema interactúa con muchos otros y afectan al comportamiento del todo. Los equipos -ágiles o no- no son islas dentro de la organización.

Menos ruedas de entrenamiento, más balance

Uno de los conceptos claves detrás de #ModernAgile (y que me enamora sinceramente) es: el de encontrar un balance. Una linda analogía de Joshua Kerievsky para ilustrar que más allá de las prácticas o marcos de trabajo, la Agilidad requiere balance para florecer. Y desde mi punto de vista, este balance debe lograrse en múltiples niveles: desde un nivel personal, de equipo, de departamento o grupo, de organización y de sociedad.

Balance organizacional

captura-de-pantalla-2016-10-17-a-las-12-55-18-p-m

Durante mi charla en el evento, utilicé una metáfora del “ecualizador” de los aparatos electrónicos de música para ilustrar el concepto de balance organizacional. Y si bien no existe configuración perfecta, cada organización debe encontrar la apropiada “ecualización” para el ritmo que desea tocar. Cada “slider” afecta al sonido que se produce. Si cada slider fuera una etapa del flujo del valor o un área de la organización, el trabajar para subir ese único slider no necesariamente produce el mejor efecto a la organización. Desde un punto de vista sistémico, se estaría sub-optimizando el sistema. Imagine, que se lleva Agile y mejores prácticas al área de desarrollo y estamos creando mejor software y a un buen ritmo; y las subsiguientes etapas o antes de colocar a producción -por ejemplo: Certificación, Seguridad, Riesgos, Legal- no trabajan al mismo ritmo: ¿cuántas de aquellas historias de usuario están en producción generando valor o retroalimentación? ¿Qué tan ágiles somos en realidad?

Imagine que lleva Agile a TI o a las áreas de Delivery, pero áreas como Talento Humano, Proveedores, no están sintonizadas al ritmo que desea tocar la organización o que exige el mercado; en realidad no es una organización ágil por más prácticas ágiles que incorporemos.

Mientras Lori hablaba, vino a mi mente una imagen que se quedó grabada y que alguna vez viera de una presentación de Masa Maeda de su modelo Serious LeAP, estas piedras que representan el balance organizacional:

balance-masa-maeda

Prosperidad tomado del modelo Seriuos LeAP de Masa Maeda

Valor para los Clientes o el mercado, valor para las personas dentro de la organización y valor para la empresa o negocio; la idea es encontrar la armonía entre estos tres elementos, balance. Coincidentemente, un esquema muy similar al presentado por Lori en su charla para la toma de decisiones dentro de su compañía.

Balance integral

Lo único que podría añadir a esto, es que no hay que olvidar que somos parte y que afectamos a la sociedad en su conjunto: la comunidad humana, el ecosistema, la ecología y cómo hacemos de este un mejor planeta para todos.

Pensamientos finales

Lo bonito de la palabra balance es que no implica que uno de los elementos es más importante que otro. Lo que quiere decir que las prácticas ágiles a nivel de equipo son importantes y necesarias; y que los valores y principios del manifiesto deben vivirse e interiorizarse; todo esto sin olvidar las otras perspectivas. Pienso que si tenemos más conciencia de este ecosistema actuaremos de mejor forma y con mayor claridad en nuestro propósito de ayudar a las personas y organizaciones que acompañamos.

Gracias por leer, un abrazo.

Johnny

Referencias y lectura posterior

 

 

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

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

Escalando el Índice de Felicidad

Medir la felicidad es algo complicado. La felicidad es algo abstracto e íntimamente ligado al aspecto personal, es difícil establecer un valor determinístico que permita concluir “qué tan feliz” se siente alguien. La felicidad es una elección consciente más que una respuesta automática. Sin embargo, dentro de las técnicas aplicadas por los equipos ágiles, existen interesantes herramientas para obtener información relacionada al estado anímico de los equipos y su satisfacción en el contexto laboral. En este sentido, el Índice de Felicidad se concibe como una medida organizacional de la percepción de satisfacción y motivación de los equipos ágiles. 

¿Por qué medir la Felicidad?

“El Compromiso de los empleados es un imperativo de negocio; este es el eje fundamental entre la estrategia y los resultados de negocio.”

– Trends in Global Employee Engagement, 2013

1. Agile es acerca de personas

La Agilidad proviene de las personas, no de los frameworks (Scrum, SAFe o cualquiera). La Agilidad vive en los equipos y florece gracias a un entorno de confianza, transparencia y colaboración auténtica. El impacto de la motivación y la satisfacción de los empleados se ha venido estudiando con atención desde hace un tiempo. A continuación algunas cifras al respecto recopiladas por compañías como Gallup y otras:

Cifras sobre la Motivación en el trabajo

Cifras sobre el Impacto de la Felicidad en el Negocio.

La Felicidad es un asunto serio. Preocuparse por la motivación y el bienestar de las personas es un reflejo de la mentalidad ágil, de un nuevo estilo de gestión, de una práctica saludable y recomendable para Líderes de Servicio, Coaches, Managers, área de Talento Humano y otros.

2. Permite medir promesas de Adopción

En un proceso de transformación ágil en el que participé utilizando SAFe como framework referencial, uno de los desafíos al que nos enfrentamos fue el de cómo medir la “Promesa SAFe” expresada en el siguiente gráfico:

Promesa SAFe

Resultados de Negocio de SAFe – SAFe Foundations

SAFe ha podido obtener estos datos de sus varios casos de estudio documentados. Con relación al engagement de los empleados, sus cifras están alrededor del 10% de incremento. Las preguntas fueron: ¿y cómo lo midieron? ¿y cómo lo medimos nosotros?. El Happiness Index resultó una herramienta útil para este contexto. (Para los otros aspectos, espero publicar pronto algo que puede servir; tema de otro post.)

3. Información que permite enfocar acciones de mejora sobre los equipos

Información valiosa que le permite a Scrum Masters, Coaches y Managers; enfocar acciones sobre aquellos equipos que necesitan mayor atención y protección. Sirve para indagar sobre las causas de su estado anímico, conversar, identificar problemas y actuar en busca de mejorar el bienestar de los equipos.

Se me ocurren otras razones, pero quizás estas sean las más importantes.

Mecanismos para medir la Felicidad

He leído de varios; desde el uso de aplicaciones en nube, encuestas de Google Docs y hasta el conteo de pelotas de tenis; todas muy interesantes.

Mecanismos para medir la Felicidad

Algunos mecanismos para medir la Felicidad

Más que las herramientas, siempre me ha gustado que este tipo de actividades sean muy lúdicas  y divertidas; entonces me gustan más herramientas empleadas en Retrospectivas. Dos de las que más me gustaron fueron el Happiness Profit de mi gran amigo Hiroshi Hiromoto y la variación del Happiness Radar de mi otro amigo Paulo Caroli de su libro Fun Retrospectives.

Happines Profit y Happiness Radar

Happines Profit y Happiness Radar – Técnicas para Retrospectivas

Debido a la información relacionada a varios aspectos, el Happiness Radar fue la elección que tomamos junto al equipo de Scrum Masters. Lo personalizamos y aplicamos en cada retrospectiva para los equipos.

Happiness Radar - Evac 2

El Happiness Radar de la Retrospectiva de un Equipo

Equipos

Equipos en Retrospectiva – Happiness Radar

Escalando el Índice de la Felicidad

1. Recopilación de la Información

Nos pusimos a trabajar y ensayamos nuestro primer sprint con la nueva técnica. Luego de la recopilación en la herramienta física, cada Scrum Master la pasaba a un excel que diseñamos para este propósito, un archivo por equipo.

Radar de Felicidad por Equipo

Archivo de Registro del Radar de la Felicidad por Equipo

Cada archivo era subido a un repositorio de donde una macro en Excel leía la información y la consolidaba en un archivo que unificaba la información de todos los equipos. La periodicidad de medición fue de cada sprint (cada dos semanas). Teníamos que establecer un nivel de automatización para que el proceso sea repetible y que no se constituya una tarea que demande demasiado tiempo, volví a programar en macros después de muchos años 🙂

2. La fórmula

El Happiness Radar es un mecanismo de conteo, es decir simplemente cuenta la personas con un estado anímico sobre un aspecto particular. La idea fue obtener un indicador que represente de la mejor forma la sensación de todo el equipo. Entonces, me basé en la fórmula del Net Promoter Score, usada comúnmente para medir la satisfacción de Clientes sobre un servicio o producto.

Fórmula del índice de la Felicidad

Fórmula del Índice de la Felicidad

La escala es un rango de entre -1 a 1, cuyos valores representan: +1: Equipo Feliz, 0: Equipo Neutral, -1: Equipo Triste. Luego se podría profundizar los aspectos y su valoración.

3. Visualización y Publicación

Quería que estaba herramienta fuera vista y discutida a nivel Ejecutivo y compartida por toda la organización, entonces figuraba en mi mente la mejor forma de presentar esta información, que fuera dinámica, muy visual y al estilo de dashboard o Balance Scored Card y en lo posible vía web. Excel no me iba a ayudar mucho por lo que recordé esta fantástica herramienta (con versiones gratuitas) para la elaboración de vistas y análisis de datos: Tableau nos salvó; así que me puse a “monear” (término ecuatoriano que significa explorar algo sin tener la certeza de lo que realmente estás haciendo, hacer monadas).

La herramienta debería contestar varias preguntas:

  • ¿Cuál es el nivel de motivación general de la compañía?
  • ¿Cuál es el equipo más “feliz” o motivado?
  • ¿Cuál es el equipo más triste?
  • ¿Con qué aspecto están más descontentos?
  • ¿Cuál es la tendencia de la felicidad en el tiempo?
  • ¿Qué equipo o equipos necesitan mayor atención?

De esta forma, el diseño de vistas debería responder de forma rápida estas cuestiones. Luego de mucho café y varios tutoriales en línea, logré crear algo como esto:

Puede explorarlo en línea en este link.

4. El proceso resumido

A modo de referencia, el resumen del proceso en la siguiente imagen:

Proceso

Proceso de Consolidación y Publicación del Índice de la Felicidad

Analizando la Información

1. ¿Mayor Felicidad = Mayor productividad?

Al principio la iniciativa de medir la felicidad fue vista como algo muy romántico, muy abstracto. Obviamente no era muy común escuchar de esto y no se había intentando algo similar antes. Si bien es cierto, se tenía en mente como algo que permitía medir la “Promesa SAFe”, el staff Ejecutivo no veía mucho valor…hasta que resaltamos lo que decían los estudios: “Un empleado feliz es más 31% productivo”. Recuerdan las cifras de arriba. Veía como empezaba a brillar una luz en los ojos de algunas personas.

Nuestra hipótesis fue: “A mayor felicidad mayor productividad”. Aunque productividad es un concepto que se presta a discusión, sobre todo hablando de Agilidad (quizás un término del siglo XX como bien lo dijera Ángel Medinilla) el reto ahora es expresar desempeño en términos de agilidad. Como eran equipos Scrum, la respuesta fue muy obvia: “Velocidad” (otro concepto discutible, pero se escapa a este post). Al inicio no me gustaba usar la Velocidad, pensaba en que se prestaría a comparación entre equipos, y más significativamente uno de los motivos fue que no hay homologación entre los puntos o velocidades de los equipos, es decir, cada equipo tiene su propia definición de qué es un punto y sus velocidades no son comparables. Una de las formas de lograr una comparación más homogénea fue utilizar la Velocidad promedio de todos los equipos.

De esta forma, contrastamos Felicidad vs. Velocidad. Recuerdo que moría de ansiedad por ver los datos, en verdad esperaba que se cumpliera la hipótesis. Pero, oh sorpresa!…no fue así. Encontramos que podíamos tener equipos tristes con mayor desempeño, y equipos felices con una entrega inferior. ¿Por qué? Me rompía la cabeza tratando de encontrar explicación. Investigué y me encontré con el trabajo del Dr. Charles Kerns, PhD por el 2008 y que despejó mi mente.

Lo más interesante fue la siguiente matriz:

Felicidad vs Desempeño

Matriz de Felicidad vs Desempeño – Dr. Charles Kerns, PhD

Cada cuadrante corresponde a un grupo que poseen sus propias características y lo más interesante, el autor propone acciones de mejora específicas para ayudar a los equipos en cualquiera de las categorías. Esto fue revelador para mí. Lo discutimos con los Scrum Masters y podíamos enfocar acciones de mejora más claras con los equipos. Compartimos los hallazgos con los managers y los invitamos a generar acciones en conjunto. Estábamos muy felices! La herramienta sirvió en ayudar al crecimiento y bienestar de los equipos. Esto destapó la creatividad de los Scrum Masters, surgieron nuevas técnicas de retrospectivas, más actividades lúdicas, campañas y actividades interesantes para lograr mayor motivación. Gracias equipo! (a Katty, Andrés, José Manuel, Polo, Luis, Ana María, Stephanie y Ximena).

Pensamientos finales

Aprendí mucho de implementar esta herramienta. Espero que este post le brinde la guía y motivación para emprender una iniciativa similar en su compañía, y que por favor me comente cómo le fue. Obviamente, fórmulas, visualización y demás pueden mejorarse; pero más allá de eso, mi mensaje final es que considere el aspecto de la Felicidad como algo importante, y realzar su enfoque hacia cuidar y cultivar le bienestar en sus equipos y su organización.

“Las empresas a menudo se olvidan de la cultura, y en última instancia, sufren por ello porque no se puede entregar un buen servicio con empleados infelices.”

– Tony Hsieh, CEO de Zappos

Gracias por leer.

Referencias

La Definición de “Ready” es tan importante como la Definición de “Done”

Ready

Usted no puede empujar a nadie a subir la escalera a menos que esté listo para subir por él mismo. – Andrew Carnegie

Uno de los conceptos más importantes y conocidos en el desarrollo de software ágil -utilizando varios sabores como Scrum y Kanban- es la Definición de “Hecho” (o Definition of Done, o DoD). La definición de Done es un acuerdo del equipo, y en muchas ocasiones de la organización. Mediante el criterio de Done se puede conocer cuando una Historia de Usuario se encuentra “Hecha” para ser presentada al Producto Owner o Stakeholders. Brinda una guía al equipo sobre las condiciones necesarias que debe cumplir una historia para ser decentemente terminada presentada durante o al final de la iteración. Es una herramienta que brinda transparencia y permite un entendimiento común de lo que significa “Hecho”.

Ya en la práctica, consiste en una especie de checklist que reúne los criterios acordados por el equipo al que se somete cada historia antes de ser colocada en la preciada columna de Done en el Taskboard. En muchos tableros he visto también la columna “Done Done!” o “Accepted” dando así dos niveles de aprobación de la historia de usuario, Done significa que cumple todos los criterios establecidos por el equipo que normalmente incluyen: el código en el repositorio, todas pruebas unitarias y de aceptación en verde, documentación si fuera necesario, integración en el ambiente de pruebas, revisión por el tester en el ambiente de pruebas, etc.; y “Done Done” o “Accepted” cuando ha sido revisada y “firmada” por el Product Owner.

Varios agilistas sugieren  lo mínimo que debe contener la definición de Done, y les dejo algunos artículos para su revisión un poco más abajo; sin embargo, quiero con este post hablar de otra definición quizás no tan conocida pero desde mi punto de vista bastante útil; la “Definición de Listo”.

La Definición de “Ready” o DoR

Análoga a la Definición de “Hecho”, la definición de “Listo” es un acuerdo entre del equipo, especialmente entre el Product Owner y el equipo de Desarrollo donde se colocan los criterios por las cuales una historia se encuentra lista para ser implementada dentro de un sprint. Básicamente, es un conjunto de condiciones -y un checklist también- a la cual se somete una historia para ser tomada en un Sprint Planning.

¿Por qué es importante?

Varias razones. Desde la práctica, una historia de usuario no está lista a la primera. El product Backlog es orgánico y necesita un tiempo de maduración. Significa que mientras el equipo de desarrollo está trabajando en las historias comprometidas en el Sprint Planning anterior,  el Product Owner está trabajando en refinar su backlog y poner a punto las historias para la siguiente y subsiguiente iteración (pienso que un buen PO prepara historias para un par de sprints adelante). Esto es, comprender el objetivo y el alcance funcional con los usuarios, expertos del dominio, UX designers, Product Managers; priorizar la historias usando técnicas apropiadas, descomponiendo historias en un tamaño apropiado para el equipo, estableciendo criterios de aceptación, identificando dependencias entre los items de su backlog y otros backlogs, colaborando con otros POs, entendiendo y revisando desafíos de arquitectura o técnicos con el arquitecto o Líder Técnico y trabajando junto con el equipo en el grooming del backlog, revisando y priorizando Bugs cuando aparecen. Así es, mucho trabajo para nuestro PO.

Bob Galen habla mucho del “Readiness Criteria” en varios artículos y en su libro Agile Reflections y sugiere una lista de Ready como la siguiente (a estos puntos les daré mi modificación desde mi criterio en paréntesis, pero la lista original la colocaré en las referencias):

  • Historias bien definidas y con al menos 5 criterios de aceptación (este valor es heurístico, igual se puede establecer un número máximo de criterios de aceptación);
  • Historias de un Tamaño apropiado, que entre dentro de un sprint (un tamaño adecuado con que el equipo se sienta cómodo y mejore su throughput, un buen tamaño que permita un mejor entendimiento, mejores criterios de aceptación, más fácil de probar, más fácil revisar, mejora la moral del equipo);
  • Que el equipo haya revisado las historias en una sesión de Grooming, donde se haya comprendido la naturaleza, el valor y desafíos técnicos;
  • De ser necesario, que la historia haya tenido un spike para explorar las implicaciones de diseño, arquitectónicas o tecnológicas (cuando el equipo no tiene mucha incertidumbre sobre lo que implica técnicamente la historia, es apropiado un spike; luego de eso la historia se puede revisar nuevamente, estimar y pasar a la columna de Ready);
  • Que la historia sea transversal, es decir que describa un comportamiento end-to-end (que sea “visible” para le negocio);
  • Que el equipo comprenda el enfoque para las pruebas tomando en cuenta aspectos funcionales y no funcionales;
  • Que se haya identificado dependencias con otras historias dentro del mismo backlog u otros backlogs a los que una historia pueda estar conectada;
  • Que la historia se alinee (y esté “enganchada”) a un objetivo u objetivos del sprint, que sean claramente visibles y demostrables.

Esta definición es bastante útil cuando tenemos a un PO que está desarrollando sus skills y su “olfato” para gestionar el trabajo para un equipo ágil. Ahora estoy trabajando con unos 29 equipos y un equipo de 14 POs; y acabamos de introducir esta práctica para lograr que las historias lleguen lo mejor trabajadas a los equipos; y estoy viendo varios beneficios de su aplicación (que espero que se sigan expandiendo):

  • Sprint plannings más rápidos;
  • Involucramiento y conocimiento temprano del equipo sobre los desafíos del siguiente sprint;
  • Gestión colaborativa del backlog;
  • Feedback temprano;
  • Levantamiento temprano de riesgos y necesidades (si se necesita del apoyo de un arquitecto, el SM ya lo puede buscar y planificar para el siguiente sprint);
  • Mayor conciencia del equipo sobre los objetivos de negocio y el alcance;
  • Ayuda al PO a comprender la visión sobre aspectos técnicos que le indica el equipo, y a sensar con qué tamaño de historias se sienten cómodos;
  • Historias mejor trabajadas en las cuales el equipo se siente parte y por ende mejora el compromiso.

Pensamientos finales

Pienso que el uso definiciones DoD y DoR claras y difundidas son herramientas muy útiles para la colaboración , claridad y “fluidez” de los equipos. Haga que el mismo equipo sea quienes revisen y definan estas definiciones, pero si están trabajando con varios equipos colaborando para construir juntos un “big working software” estas definiciones deben ser coherentes a través de todos lo grupos. Se puede crear comités y reuniones de trabajo para afinarlas. Igualmente, están sujetas a revisión y modificación tras cada iteración.

Coloque una columna “In Analysis” o “En Revisión” (o cualquier nombre, sea creativo) donde colocará aquellas historias sobre las que debe trabajar y refinar. Cuando estén listas y se cumpla con la DoR, agréguelas a la columna “Ready” o “Backlog” que son aquellas que se explicarán en el siguiente sprint planning.

Trabajar bajo estas definiciones brindará claridad y fluidez al trabajo de los equipos y aportarán a su crecimiento y madurez. Una vez lo que hagan, por favor compártanme sus experiencias.

Gracias, y que la agilidad esté con Ustedes.

Johnny

Referencias

http://guide.agilealliance.org/guide/definition-of-done.html

http://www.solutionsiq.com/what-is-the-definition-of-done-dod-in-agile/

https://www.scrum.org/Resources/Scrum-Glossary/Definition-of-Done

https://www.scrumalliance.org/community/articles/2008/september/definition-of-done-a-reference

http://www.allaboutagile.com/definition-of-done-10-point-checklist/

https://agilefaq.wordpress.com/2012/12/02/what-is-definition-of-ready/

http://www.batimes.com/robert-galen/user-stories-ready-set-go.html

El valor de la disciplina en entornos ágiles

HuHN5gg

“Es importante la constancia, el compromiso, la colaboración y la interacción entre individuos pues es lo que genera la máxima productividad.”

– Norberto Gaona 

Algo que siempre decimos y percibimos los agilistas es ”que los equipos ágiles son muy disciplinados”. Disciplina, acuerdos y compromiso son -desde mi punto de vista- pilares para la ejecución y adopción ágil (y de cualquier trabajo, sea ágil o no).  Son clave para que el proceso ágil fluya, mejore y se entregue el valor en un ritmo constante en periodos cortos. Las prácticas ágiles fueron diseñadas a propósito para elevar el sentido de disciplina; por esta razón los timeboxes son fijos (pase lo que pase), los sprint plannings se basan en compromisos, las reuniones son llamadas ceremoniass, el código se sube todos los días, la definición de Done y los criterios de aceptación se cumplen, si hay que hacer documentación, se hace; y se respetan los acuerdos organizacionales y del equipo. Cuando un equipo ágil es disciplinado, incluso el trabajo remoto es se lleva mejor.

1406804729923_Image_galleryImage_Jamaica_s_Usain_Bolt_prac

“Agilidad requiere una dosis extra de disciplina, porque cada miembro del equipo es indispensable. El valor, el peso y la responsabilidad de cada uno es por lo tanto mayor.”

– Giancarlo Girardi

En mi experiencia, la moral del equipo se incrementa al ver software funcionando creado en un sprint luego de haber trabajado en una jornada dura, pero donde se demostró disciplina, ahínco, profesionalismo y compañerismo. Los equipos ágiles tienden a convertirse en equipos de alto desempeño, los miembros de un equipo son como atletas; para llegar a ser un gran atleta y competir en alto nivel, existe mucha disciplina en los entrenamientos, en su plan de nutrición, en su disciplina mental y física. Skills, Disciplina, Entrenamiento. Es lo mismo para los equipos ágiles.

131dcd4f-dcf9-4968-8107-772a4929e0f7

 “Disciplina para hacer lo que sabes que es correcto e importante, aunque difícil, es el camino real para el orgullo, la autoestima y la satisfacción personal.”

– Margaret Thatcher

article-2187195-1480BB74000005DC-77_634x425

Todos somos llamados a fomentar la disciplina a través de nuestro trabajo del día a día. Disciplina no es miedo, disciplina no es micromanagement, disciplina no es autoritarismo. Disciplina es un valor que expresa diariamente; es el puente entre las metas y los logros. El Agilismo está lejos de la anarquía de las que temen muchos managers, sobretodo en organizaciones grandes. Disciplina es un valor requerido en el Agilismo. A practicarlo!

(Buscando imágenes para este post me encontré con estas fotos sobre la Belleza de la Disciplina en el entrenamiento de monjes Shaolín; me encantó).

eFSyPr0

 

Referencias

http://www.futuresourcesummit.com/noticias/no-caer-en-la-indisciplina-clave-para-el-desarrollo-agil/
http://development-geek.blogspot.com/2011/11/scrum-agile-malos-habitos-iii-agilidad.html
http://www.thefirstmanscrapbook.com/%E5%B0%91%E6%9E%97-the-beauty-of-discipline-shaolin-monk-training/

#ConversaAgil, Latinoamérica unida en la Agilidad

Media_httpwwwthecreat_axzxa

“Nunca dudes que un pequeño grupo de personas comprometidas puedan cambiar el mundo. En efecto, es lo único que lo ha logrado” – Margaret Mead 

Hoy en la tarde participé de una experiencia fantástica. 


Agilistas de Venezuela, Chile, Colombia, Perú y Ecuador participando con sus tweets en el primer ConversaAgil; una simple pero poderosa iniciativa diseñada para compartir experiencias acerca de Agile y conversar sobre un tema específico propuesto; en esta ocasión “Técnicas ágiles aplicadas a proyectos que no son de software”. 

 

#ConversaAgil se asemeja a un OpenSpace habilitado sobre Twitter (algo como un TOS: Twitter Open Space) en el cual todos los participantes compartieron sus tweets llenos de valiosos aportes, links y consejos. Es un espacio para conocer y exponer puntos de vista sobre una problemática ágil y al mismo tiempo fortalecer las relaciones entre amigos agilistas de la región, que aunque no nos conocemos personalmente, compartimos este gran espíritu ágil y las ganas de ayudar. 

 

Todavía hay cosas por mejorar, pero para ser el primer intento, salió genial!! Pronto llevaremos a cabo otro #ConversaAgil. 

 

Gracias Gustavo Bonalde e Irwin José Franco por hacerme parte de esta maravillosa idea; un gusto colaborar con Ustedes. 

 

Saludos!