El Zen del Scrum Master: Self-Mastery

marzo 22, 2018marzo 22, 2018 / Johnny Ordóñez / 2 comentarios

dongzhi-419028

He notado que cuando se habla del rol del Scrum Master, siempre se lo expresa «hacia fuera», es decir; la descripción de aquellas responsabilidades que tiene hacia el equipo o la organización. Esto es importante sin duda, pero a mí me gusta también explorar este rol «hacia dentro»; y cuando lo hago uso una analogía -tomada de la representación del yin y el yang– a la que he denominado el Zen del Scrum Master.

El yin-yang es una representación taoísta muy conocida que se refiere a la «dualidad» existente en todo lo que habita en este universo. El círculo yin-yang es familiar (quizás unos de los conceptos orientales más difundidos). El yin corresponde a la mitad del lado izquierdo de la esfera, de color negro; representa la pasividad, la absorción, la tierra, la oscuridad, lo nocturno. Por su parte, el yang pertenece al lado derecho de la esfera, de color blanco y representa el principio activo, luminoso y diurno. No puede haber yin sin yang, o yang sin yin…y hay un poco de yang en yin, y un poco de yin en yang.

En el Zen del Scrum Master, el yin es el «self» o el «yo». Hace referencia al dominio del individuo, a la maestría personal; esto es: el conocimiento de ti mismo, el dominio y uso de tus emociones, al dominio de tu ego, el desarrollo de la escucha empática, a la consciencia y dominio de tus palabras…y como todo esto te ayuda a crecer como individuo y como Scrum Master.

5f136e918828b0934d4ca0cdc479ac6e-zen-meditation-concentration-camps

Exploración y conocimiento del «Yo»

El yang hace referencia al «mastery» o «dominio de la técnica». Esto es acerca al desarrollo de habilidades para crear espacios donde los equipos se habiliten a tomar sus propias decisiones para aprender y mejorar. Es sobre el dominio de técnicas para la introspección, ideación y solución, es sobre ayudar a elevar el nivel de consciencia de los equipos; y por supuesto- es sobre el dominio del método Scrum o otros métodos ágiles, técnicas de facilitación, retrospectivas, mentoring y guiar al equipo para ayudarlos a crecer.

Expresar a través de la técnica

Posiblemente lo siguiente sea una parte menos conocido en el yin-yang. En el yin-yang no existen sólo dos fuerzas, existen tres: el yin, el yang y el Tao…la fuerza que los une, la fuerza conciliadora, que no se ve pero allí está.

Taller de Scrum Masters que facilité en BBVA Colombia, 2017

En esta pequeña analogía, en el Zen del Scrum Master hay el«self», la«mastery» y el «Self-Mastery».

Ser Scrum Master (SM) es vivir en un ejercicio continuo de «auto-maestría» (Self-Mastery). Que si bien, hay un principio sobre el dominio de la técnica de Scrum y ágil, hay un principio sobre el dominio del ser, de las emociones, de la maestría personal.

Hay un poco de «Yo» en mi «Técnica», y un poco de «Técnica» en el dominio de mi «Yo»…y ninguno de ellos viven solos.

Posiblemente todo esto suene algo «esotérico» o «romántico» para la mayoría de agilistas, pero por experiencia en carne viva puedo compartir: ser un Scrum Master o Agile Coach es un camino de trabajo constante en uno mismo, de crecimiento personal que toca fibras íntimas, que replantea; y también de «expresar a través de la práctica», del dominio de la técnica. Un Scrum Master o Coach comparte y expresa lo que se lleva por dentro; y esto sin duda ayuda a crecer en el rol y ayudar a sus equipos. No subestimen el Zen del Scrum Master.

Gracias por leer.

El autodominio es un desafío para cada individuo. Sólo nosotros podemos controlar nuestros apetitos y pasiones. El autodominio no puede ser comprado con dinero o fama. Es la prueba definitiva de nuestro carácter. Requiere descender por los profundos valles de nuestras vidas y escalar nuestro propio Everest.

– James E. Faust

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

octubre 17, 2016octubre 17, 2016 / Johnny Ordóñez / Deja un comentario

¡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.

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.

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:

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

junio 15, 2016junio 17, 2016 / Johnny Ordóñez / 6 comentarios

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

marzo 31, 2016abril 1, 2016 / Johnny Ordóñez / 5 comentarios

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

febrero 10, 2016febrero 10, 2016 / Johnny Ordóñez / 6 comentarios

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 Motivació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:

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.

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 – 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.

El Happiness Radar de la Retrospectiva de un Equipo

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.

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

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:

Happiness Index Dashboard

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 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:

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»

diciembre 12, 2014enero 15, 2015 / Johnny Ordóñez / 2 comentarios

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

octubre 15, 2014marzo 13, 2018 / Johnny Ordóñez / 1 comentario

“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 ceremonias, 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 se lleva mejor.

“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

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ó).

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/

The 7 Duties of Great Software Professionals (Reworked) from Jurgen Appelo

#ConversaAgil, Latinoamérica unida en la Agilidad

agosto 17, 2012abril 19, 2013 / Johnny Ordóñez / 3 comentarios

«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!

Pensadores y Hacedores: Pensando en la Altitud

marzo 9, 2012abril 19, 2013 / Johnny Ordóñez / Deja un comentario

Hace pocos días leí un gran artículo denominado Pensadores y Hacedores redactado por Francisco Sáez (@franciscojsaez), fundador y CEO de FacileThings. Francisco comenta acerca de la disposición de las personas en dos grupos: los «thinkers» y los «doers» y resalta las características de cada uno. Siendo ambos importantes para una organización, Francisco sugiere la búsqueda de un equilibrio en el cual se rescaten las cualidades de cada personalidad con el fin de lograr un objetivo.

Yo me sentí realmente identificado, ya que en ese preciso día había tenido feedback por parte los miembros de mi equipo con respecto a que sólo pasaba pensando y no haciendo. Esto no quiere decir que para hacer algo no haya que pensar, sino más bien, que me pasaba soñando mucho y pensando en estrategias en lugar de ayudar a cristalizarlas. Al sentirme así, mi comentario fue el siguiente:

Al día siguiente Gorky Estrella también comentó al respecto:

Gorky es un gran compañero y amigo, y junto a Mercy formamos este pequeño equipo lleno de ilusiones y ganas por hacer cosas geniales. Entenderán entonces su comentario, estaba enojado conmigo.

Reflexionando sobre el tema pensaba que el problema de los thinkers es que pasan (o en este caso pasamos) mucho tiempo en las nubes. En cambio, el problema de los hacedores es que se concentran tanto en el cómo hacerlo que se sumergen mucho en los detalles. Esto puede ser expresado con una cuestión de Altitud. Qué significa??.

Al pensar en nubes y en inmersión recordé un slide de una presentación de Jeff Patton (@jeffpatton) con la que ilustra que una definición de tarea de usuario o construcción de UX es sensible a la altitud en la que nos encontramos al momento de diseñarla.

Adentrándome un poco al desarrollo de SW, si el nivel de altitud es demasiado alto nos arriesgamos a un Big Design Up Front, en donde comencemos a pensar y a diseñar cientos de cosas, una arquitectura súper completa adaptable a todos los escenarios imaginables y que permita satisfacer todas las necesidades del usuario incluso las que todavía no tiene. Por otro lado, si el nivel es demasiado bajo, estaremos tan pendientes de los detalles de implementación: el objeto, la clase, el algoritmo, etc., que perderemos fácilmente la visión del para qué estamos construyendo esta funcionalidad o qué necesidad del usuario satisface. Tal como concluye Jeff Patton, es necesario que exista un balance, es decir; encontrar un punto medio que permita abstraer de forma más real e idónea una necesidad de negocio o el mismo UX.

Es evidente que en este punto medio se encontrarán las habilidades y fortalezas de Thinkers y Doers, trabajando juntos para alcanzar la meta: hacer brillar a nuestro cliente de felicidad. Esto no quiere decir que se deba permanecer siempre a nivel del mar. Seguramente nos adentraremos en los detalles y resolver el cómo realizarlo. De igual forma, es necesario subir y abstraer e imaginar nuevos escenarios y oportunidades. Ubicarnos entre el nivel de la cometa y el nivel del mar es el punto de partida que nos permitirá enfocarnos hacia una apreciación adecuada y hacia un trabajo dirigido hacia el usuario.

Thinkers y Doers: mismo equipo, misma meta!.

PD: Estimado Gorky, por favor tenme paciencia 🙂

Formando un equipo ágil

febrero 23, 2012abril 19, 2013 / Johnny Ordóñez / Deja un comentario

Luego de recibir un curso, charla o seminario de Agile o Scrum se genera un gran entusiasmo al conocer una nueva forma de crear software, un conjunto de nuevos principios y sobretodo al descubrir los muchos beneficios que la agilidad brinda sobre el enfoque de desarrollo tradicional. La energía crece al saber que Agile o Scrum no son las metodologías o frameworks de moda, sino más bien un movimiento que está empujando a la industria del software y a otras hacia nuevas direcciones en las que se garantiza productos de calidad y clientes deleitados (algunas estadísticas #mce_temp_url#).

Como resultado del estusiasmo, al siguiente día la oficina luce paredes llenas de post-its, varios StoryBoards y compañeros de pie ensayando su primer Stand-Up meeting. Toda esta buena energía es positiva, sin embargo debe ser correctamente canalizada. En el proceso de adopción de Agile muchas organizaciones comienzan velozmente al aplicar las prácticas sin tomar mucha atención en la interiorización de los valores Agile. Generalmente todos desean aplicar Scrum pero no se tiene un inicio claro del qué vamos a hacer, porqué o para quién.

En mi experiencia al comenzar a plasmar los conceptos de la agilidad, he resumido unos pocos pasos que están dando buenos resultados en el proceso de adopción en la empresa en la que trabajo y que deseo compartir:

1. Full Empowerment: contar con el respaldo total por parte de la organización (o instancias superiores) acerca del proceso de adopción de una práctica ágil como Scrum para el desarrollo; la organización debe estar convencida de los beneficios que brindará sobre la manera de crear software. Agile implica muchos cambios a nivel cultural y de procesos que deben ser auspiciados por la empresa. Este respaldo es importante ya que brindará autonomía al equipo y le dará espacios transparentes para la toma de decisiones. La difusión del inicio del proceso como un programa piloto es parte de este punto. Si Usted es un emprededor ágil debe comenzar a «vender» y generar confianza en los directivos de su organización.

2. Invitación a participar a las personas que lo deseen: Identificar e invitar a las personas que posean los perfiles apropiados, talentos y habilidades pero por sobretodo, estén con muchas ganas y entusiasmo de comenzar con Agile. Que su forma de pensar y de actuar sea de cierta forma coherente con los valores y principios de la agilidad y que estén deseosos de aprender y mejorar. A mi forma de pensar, pesan más las ganas, la capacidad de aprender, desaprender y reaprender por sobre el badaje técnico que se pueda tener.

3. Identidad: Cuando propuse este punto como parte del inicio de un equipo, muchos me preguntaron…para qué?. El sentido de identidad va más allá de un nombre para el equipo, consiste en brindar un sentido de pertenencia, unión y colaboración entre las personas que conforman el equipo. Identidad la entiendo como la definición de un nombre, valores, principios y acuerdos que constituyen la cultura del equipo y rigen su comportamiento. La siguiente pregunta fue: pero…no son los mismos valores y principios del Agile Manifesto??. Mi respuesta fue: hagamos de este equipo nuestro equipo y que represente lo que somos y lo que hacemos. La definición de la identidad es la primera reunión del nuevo equipo -nada formal-, donde todos aportan efusivamente y se llega a los primeros acuerdos. Cada nuevo miembro del equipo debe estar de acuerdo y comprometerse con lo acordado.

4. Lenguaje común: consiste en el manejo homogéneo de conceptos, términos y prácticas -tanto técnicas, tecnológicas, procedimentales y de agilidad- de los miembros del equipo; no necesariamente con gran nivel de profundidad o un manejo experto de cada tema; pero si una visión y comprensión de los conceptos que usará el equipo. Durante mi experiencia en este punto, se organizaron varias charlas informarles entre los miembros del equipo (no más de 40 minutos entre contenido y preguntas), en donde todos propusimos temas en los cuales se tenía ciertas dudas, deficiencias o simplemente temas que se querían conocer; además de los que todos considerábamos importantes antes de iniciar. Fue un proceso de aprendizaje bastante satisfactorio, ya que los que más conocían acerca de algo compartían su experiencia con los demás miembros. Se hicieron breves Coding-Dojos y talleres altamente participativos. En muchas literaturas se denomina a este punto como Iteración 0, sin embargo pienso que más que una evaluación de nuestra habilidad con herramientas y tecnologías, la formación de un Lenguaje común es un elemento que involucra otros aspectos y que no necesariamente están dentro del contexto de adquirir o conocer nuestro Velocity.

5. Envisionamiento del Producto: Okay, es aquí donde comenzamos a vivir más intesamente la agilidad. Básicamente la definición del qué vamos a hacer, el porqué y para quién se realiza en este punto. Qué es lo que vamos a lograr como equipo. Es la definición del norte acerca del producto que se desea construir. Como todos sabemos, en Scrum es el Product Owner quién acerca la idea al DevTeam a través del Product Backlog. Es vital contar un PO con las características adecuadas y el conocimiento que dirigirá el esfuerzo del equipo de desarrollo. El PO motiva al equipo. Su Product Backlog lo reta constantemente y le inyecta dinamismo. Si no se cuenta con un PO lo más recomendable para mí es emprender un proyecto al interior de la misma empresa, alguna solución que agregue valor en donde nuestros compañeros más conocedores del negocio al cual se quiere ayudar, nos entregue su enfoque de producto sin ser necesariamente un PO, podemos involucrarlos y juntos con el equipo emprender un proceso de discovering y crear una visión de producto compartida, en la cual poco a poco se vayan abordando prácticas como el Visual story Mapping con la participación y el conocimiento de todos.

6. Requisitos Operacionales: consiste en la definición de aspectos importantes para el desempeño diario del equipo:

Common workspace: Importantísimo. un ambiente de trabajo que fomente la colaboración, comunicación y comodidad del equipo, facilite las Daily Meettings y otras reuniones, se puedan ubicar StoryBoards, etc.
PCs, networking, ambientes de desarrollo, pruebas de usuario o de review, servidor de integración continua, herramientas de colaboración y comunicación.
DevOps: el primer acercamiento del equipo de infraestructura hacia la agilidad. El concepto de DevOps es acercar al equipo de desarrollo con el de infraestructura-operaciones de la compañía. Estos dos mundos que siempre han estado separados, ahora trabajan junto con el DevTeam para realizar una exitosa entrega continua. Las tareas de Configuration Management, Versionamiento y otras son manejadas en este contexto. Por lo general en equipos o empresas pequeñas estas tareas son manejadas por el mismo DevTeam, sin embargo cuando existen muchos proyectos o se requiere colocar entregables en ambientes de producción de ciertos clientes estas operaciones conjuntas son necesarias (hablaré más de DevOps en un siguiente post más adelante).

7. Y…creo que estamos listos para emprezar!!

Estos pasos no son una guía formal o rígida (tanto en el orden como en la forma de abordar cada punto). Crear un equipo ágil depende mucho del contexto de la empresa, las personas y de los productos a construir; pero espero que en un sentido general estos pasos sirvan de utilidad para aquellos que desean comenzar firmente el camino hacia la agilidad y hacia un crecimiento personal y profesional. Me gustaría conocer sus comentarios y/o sugerencias al respecto. No olvidemos que Agile involucra un aprendizaje continuo.

Muchos saludos.