Ya no estamos en testing Kansas

Nota: El título hace referencia a "We're not in Kansas anymore", del Mago de OZ.

¿Dónde estamos?

La agilidad surgió como una revolución de una clase oprimida; la de los programadores que lucharon para liberarse de los Project Managers.

Han pasado 15 años desde el Agile Manifesto. La revolución ha cumplido su objetivo. Los programadores lograron ser reconocidos como miembros igual de importantes dentro de los equipos de desarrollo. Pero, ¿Qué pasó con los testers?

En el primer proyecto ágil en el que participó uno de los autores, el grupo estaba cambiando su forma tradicional de desarrollo de software a una dinámica ágil. Era inicialmente un grupo compuesto por tres equipos de programación y uno de testing.

Durante el cambio, algunas personas del equipo de testing se sumaron a los programadores para formar equipos de desarrollo que incorporen la calidad desde el inicio. Pero el cambio no fue completo, los testers se ocuparon en acercarse a los programadores automatizando pruebas. Pero en los últimos dos días de cada sprint, cuando se corrían las pruebas finales (automáticas y manuales) antes de liberar el producto, algunos miembros del equipo no tenían respiro (los testers), mientras otros miembros del equipo se dedicaban a jugar al Counter Strike. Eso sí, con auriculares para no molestar. En este contexto, donde la calidad esperaríamos que fuera interés de todos, las tareas de testing no las toman los programadores.

La historia que contamos muestra una implementación incompleta del enfoque Whole Team o equipo completo. Pero ¿qué pasa si logramos una buena implementación? Si todos los miembros del equipo se ocupan de la calidad, entonces ¿el tester desaparece?

El rol de tester en un equipo ágil

Si definimos lo que somos por lo que hacemos (testeo, por lo tanto soy tester) no sólo nos auto-limitamos en nuestro crecimiento personal sino que además limitamos la capacidad de nuestro equipo para encarar desafíos.  

El equipo debe tener los conocimientos y capacidad para testear, los cuales no necesariamente deben estar centralizados en una persona, sino que pueden ser parte de un rol y ese rol puede estar distribuido en varios miembros del equipo. De esta manera todo el equipo es responsable de la calidad.

El rol de testing ágil tiene algunas diferencias con el testing tradicional. En lugar de una persona exclusivamente preocupada por el detalle, el rol de testing ágil ajusta el nivel de detalle según el análisis que se esté realizando. En lugar de enfocarse en probar el producto, se ocupa en que el producto se construya con calidad.

En el testing ágil además de ser importante probar que hicimos lo que nos pidieron, resulta central considerar las razones y el contexto en el que nos lo pidieron. De esta manera, puede detectarse si estamos logrando el objetivo original, si tenemos la oportunidad de lograr un producto que exceda las expectativas y en general, sí mantenemos la mirada en la visión y los pies en la tierra. Luego, podemos distinguir el grado de importancia de los distintos temas identificados y tomar decisiones considerando esa guía: ¿Qué nos acerca a la visión? ¿Qué nos dificulta avanzar?

En resumen, consideramos que las siguientes características resultan centrales para el rol de testing ágil:

• Comprender la visión de negocio: ¿Que proceso de negocio es el prioritario? ¿Cuáles son los objetivos y sus métricas relevantes que cierta funcionalidad intenta mejorar?
  
• Conocer el proceso de desarrollo: Dentro del rol de testing ágil está trabajar continuamente para que la calidad esté incorporada al proceso de desarrollo. Si detectamos un problema en el ambiente de aceptación, tratemos de agregar un test para que la próxima vez se detecte en el ambiente de desarrollo. Optimizar el proceso muchas veces implica automatizar la prueba de regresión. Y avanzando por este camino, vemos que la calidad desde temprano nos permite más velocidad, como puede verse en Continuous delivery.
• Saber cómo diseñar experimentos: Esto nos sirve para validar hipótesis del negocio (Lean Startup), para probar que estamos haciendo el producto correcto y bueno para nuestros clientes, como para mejorar nuestro proceso de desarrollo. También tenemos hipótesis sobre aspectos que afectan la calidad y hacemos experimentos probando el producto.
• Conocer sobre testing en sí mismo: Es más fácil conseguir capacitación sobre programación o gestión de proyectos que sobre testing. Hay poca bibliografía y poco tiempo dedicado a la mejora del testing (katas, dojos, craftsmanship). Sin embargo hay mucho para aprender: evaluar las dimensiones de variación del sistema, identificar dimensiones válidas para probar, definir si es posible probarlas de forma independiente, etc. También resulta necesario conocer las diferentes heurísticas de prueba, los problemas comunes que dependen de la tecnología usada e identificar el conjunto que es posible probar en cada momento del desarrollo.
• Riesgos: ¿Cuál es nuestra peor pesadilla? ¿Cuáles son las formas en que se puede romper el producto?¿Qué podemos perder, vidas, dinero, clientes? Las respuestas a estas preguntas nos orientan tanto en la definición de alcance de las pruebas como para su priorización. Conociendo los riesgos podemos elegimos cómo manejarlos. Tomar riesgos en forma controlada nos permite ir más lejos más rápido y ser más innovadores, que si quisiéramos evitar todos los riesgos. Ver mi post anterior sobre el tema.

¡Cómo que en la lista no está ...!

Algunas dudas surgen de esta enumeración: ¿qué pasa con la automatización de la prueba, la usabilidad, la seguridad?

En un equipo de desarrollo ágil es bueno que todos se ocupen en aprender sobre programación, testing, usabilidad, seguridad y probablemente otras cosas también. 
Automatizar, automatizar, automatizar: Es el mantra de todos los miembros del equipo. Es parte de lo que llamamos Conocer el proceso de desarrollo. Para ello es útil que todas las personas de equipo puedan escribir scripts al respecto, pero no necesariamente ser todos expertos en herramientas. Como testers, podemos trabajar de a pares con los expertos.
Pero no todos tienen que ser expertos en todo. Nos parece útil, por lo tanto, dejar esos temas en otros roles. Cada persona desarrolla su especialidad, profundizando y participando de comunidades de práctica. Además, aprende de sus compañeros de equipo sobre otras áreas. Entonces una persona que cubre principalmente el rol de testing, puede además conocer sobre programación lo suficiente como para automatizar situaciones normales y pedir ayuda ante problemas técnicos complejos.

¿Pero es tan distinto el testing en ambientes ágiles del testing tradicional?
Una pregunta que naturalmente surge es: ¿Cuáles de estas características no están en el rol tradicional?¿Son exclusivas del rol del testing en un ámbito ágil?

Consideramos que ninguna de las actividades es demasiado novedosa, por lo que podríamos identificar actividades equivalentes en el marco del testing tradicional. Y encontramos dos diferencias: 

No hay en el equipo una persona cuya única tarea sea probar y que concentre toda la prueba necesaria. Sí se encuentra definido un rol, que cubierto por diferentes personas, con distinto grado de involucramiento. Así es posible compartir más tiempo con otros y esto da lugar a más oportunidades de aprender, crear e innovar.

¿Y ahora qué?
Considerando la diversidad de conocimientos necesarios para cubrir de manera completa el rol del testing, es posible identificar quienes son los miembros del equipo más adecuados para cubrir esas necesidades y que ellos se interesen, no sólo por profundizar el conocimiento sobre esos temas, sino además compartirlos con los compañeros de equipo.

Una forma es a través de lecturas. Mi lista personal de libros: Agile Testing, More Agile Testing, Explore It!, How Google Tests Software, The Domain Testing Workbook, Continuous Delivery.

Además, junto con Natty y Ángel realizamos cursos on line de Agile Testing.

Origen del post y agradecimientos

Este post es uno más, dentro de mi búsqueda sobre el testing (ver lo que opinaba en 2009). Entre 2014 y 2015 presenté algunas de estas idea en JAIIO 43, Ágiles 2014 (en Open Space con Juan Diego Vasco Moncada), CAS2014 (ver la presentación más abajo) y Agile 2015.

Gracias a Natty Davidovich (@nattydavidovich), Ángel Nuñez Salazar (@Snahider) y Nico Paez (@inicopaez) por las discusiones, revisiones y aportes a este post y a mi comprensión del testing.

Difusión de las innovaciones

La difusión de las innovaciones o adopción de ideas y tecnologías sigue ciertos patrones. Distintos autores los estudiaron. El trabajo clásico sobre el tema es de Everett Rogers (Wikipedia).

En este post voy a comentar una versión alternativa que presentó Geoffrey Moore en 1991 en su libro "Crossing the Chasm".

El gráfico representa la cantidad de personas que adoptan a medida que avanza el tiempo.
En l propuesta inicial de Rogers, al principio lo adoptan los innovadores (Innovators), luego los primeros seguidores (Early adopters), la mayoría temprana (Early majority), la mayoría tardía (Late majority) y finalmente los rezagados (Laggards).
Un aporte importante de Moore es identificar que entre los primeros seguidores y la mayoría temprana se produce un quiebre importante, en el muchas innovaciones se detienen. Lo llama la brecha (the chasm).

La idea central es que las personas que adoptan ideas o tecnologías en diferentes momentos tienen necesidades distintas y que siendo conscientes del momento en que se encuentra el producto, podremos ajustar mejor la estrategia, tanto de mejora como de comunicación, para llegar a nuestros siguientes 'compradores' de la innovación:

• Innovadores: los que siempre buscan lo nuevo, les interesa ser "los primeros en ...". Es fácil lograr que usen nuestro producto o idea, pero no les dura mucho ya que pasan a algo nuevo rápidamente. Pero mientras lo usan, lo hacen conocido a más personas y alguno de ellos se vuelve un primer seguidor. Nuestra tarea es entusiasmarlos con la potencialidad y lo novedosa que es la innovación. 
• Primeros seguidores: a los que nuestra innovación les genera mucho beneficio. No se detienen ante los riesgos o las imperfecciones que seguramente tiene la innovación en esta instancia. Nuestra tarea es escucharlos y ajustar la innovación para que les genere más y más valor aún.
• La brecha: es un momento de decisiones difíciles. Si seguimos ajustando la innovación a lo que nos pide cada uno de los primeros seguidores, nunca llegaremos al gran público. En tecnología, seguiremos agregando más y más funcionalidad o detalles, cada uno de ellos relevantes solo para un pequeño número de interesados. Necesitamos un cambio de foco, que nos alejará de nuestro soporte actual (los primeros seguidores) y quizás pase un tiempo hasta que ganemos a la mayoría temprana. Nuestra tarea es trabajar en hacer la innovación sencilla de comunicar, de adoptar y de usar, confiable, con soporte ante inconvenientes.
• Mayoría temprana: a los que nuestra innovación les genera valor, pero no están dispuestos a tomar riesgos elevados. Los convencen las historias de éxitos de otros que ya pasaron por la adopción. Están dispuestos a pagar por la innovación. En esta etapa el crecimiento de la adopción es explosivo. Moore escribió sobre esto en su libro "Inside the tormado". Nuestra tarea es escalar para sostener la demanda. El limitante para el crecimiento en adopción es nuestra capacidad para escalar.
• Mayoría tardía: los que incorporan la innovación cuando ya no es innovadora. Son los adversos al riesgo. Cuando más del 50% adoptó una idea, empieza a ser más riesgoso no adoptarla. Es muy probable que haya aparecido competencia. Nuestra tarea es mostrar que somos la opción más segura y trabajar en optimizar los procesos operativos (por ejemplo, tener costos bajos).
• Rezagados: lo reticentes. Es un mercado relativamente chico, difícil de alcanzar y con poco margen.

Sobre Retrospectivas

Les paso una lista de recursos sobre retrospectivas, que por supuesto no leí, salvo un par.

Video

• Sprint Retrospective by Michael James 

Libros

via Michael James

• Project Retrospective, Norm Kerth 
• Agile Retrospectives: Making Good Teams Great, Derby & Larsen
• Facilitator's Guide to Participatory Decision-Making, Kaner, Lind, Toldi, Fisk, Berger
• Crucial Conversations, Patterson, Grenny, McMillan, Switzler, Covey
• Getting To Yes, Fisher & William Ury
• John Gottman - alguno de sus 40! libros

via Pierre Fauvel

• Collaboration Explained, Jean Tabaka
• The Art of Focused Conversation,  R. Brian Stanfield (disponible en gooble books)
• Time To Think, N. Kline

via Bas Vodde

• The Skilled Facilitator, Roger Schwartz

via Jean-Charles Meyrignac

• Coaching Questions: A Coach's Guide to Powerful Asking Skills, Tony Stoltzfu

via Hubert Smits

• Facilitating with ease, Ingrid Bens
• Advanced Facilitation Strategies, Ingrid Bens
• Grove Consultant's books on facilitating and drawing (drawing pictograms and whole process displays)

via Jean Richardson

• Do I Have to Give Up Me to be Loved by You?, Paul and Paul
• The Handbook of Conflict Resolution:  Theory and Practice, Deutsch and Coleman
• Discussing the Undiscussable, Noonan
• Christopher Argyris - 20 libros!
• The Deep Democracy of Open Forums, Arnold Mindell
• The Leader as Martial Artist, Arnold Mindell
• Working on Yourself Alone, Arnold Mindell

via Diane Larsen

• Solving Tough Problems, Adam Kahane & Senge
• Power and Love, Adam Kahane

via Josef Scherer 

•  57 SF Activities for facilitators and consultants, Peter Röhrig & Jenny Clarke (SF: Solution Focused)

via Ilja Preuss

• The 9 Disciplines of a Facilitator, Jon C. Jenkins & Maureen R. Jenkins

Intro al desarrollo ágil

Hace un tiempo armamos con Ricardo Colusso una introducción breve al desarrollo ágil de software. 
El objetivo es tener material de lectura suplementario a un curso, ya que nuestros cursos tienden cada vez más ppt-less, siguiendo las ideas de Training from the back of the room. La intensión es ser un primer paso, con links para seguir el aprendizaje. No una enciclopedia.
Dudamos entre hacerlo en formato de pequeño libro con copyright, luego decidimos hacerlo con CreativeCommons, y lo implementamos en knol.
Knol fue el intento de Google de contrarestar Wikipedia, permitiendo que queden indicados los autores de los artículos vs editores anónimos. No funcionó. Siguiendo la política de fail fast, lo discontinuaron, ofreciendo la posibilidad de mudar los knol a mano (pueden ver el mío de testing aquí), o a Wordpress, donde pueden acceder a Desarrollo ágil de Software.
A los que les sirva este pequeño texto, comenten para que lo mejoremos.

Revistas gratuitas sobre Testing y otras yerbas

Hace unas semanas estuve hablando con Rodrigo Guzman sobre la profesionalización de los testers, y surgió la necesidad de leer y aprender contínuamente.
Derivamos en que, además de los libros y foros, en las publicaciones periódicas, normalemnte todas con registración, pero gratuitas.

• http://www.softwareguru.com.mx/ - No necesariamente testing ni ágil. Español.
• www.testingexperience.com - No necesariamente ágil. Inglés.
• Better Software - No necesariamente testing. Inglés.
• SD Times - Noticias IT & desarrollo software. Inglés.
• Software Test and Performance - Normalmente ágil. Inglés.

Que lo disfruten (¡y sepan manejar el exceso de información!)

Artful Making

Al pensar usamos nuestro lenguaje. Así el lenguaje limita lo que pensamos o al menos podemos decir que es mucho más dificil manejar conceptos o abstraciones sobre los que no tenemos palabras apropiadas. Cada tanto tenemos la suerte de agregar nuevas palabras a nuestro lenguaje, que nos permiten expresar más sencillamente algo que teníamos dando vuelta en la cabeza.
Esta vez me pasó con el libro “Artful Making”, de Rob Austin y Lee Devin (pueden ver gratuitamente el prólogo y capítulo 1).
Este libro, entre otras cosas, me dió las palabras-conceptos Artful Making e Industrial Making. El nuevo modelo mental es poderoso (“Mindbending” lo llama Kent Beck). Me hicieron replantear parte de mis ideas de CMMI y Agile con resultado parcialmente reflejado en parte 1, parte 2.
Artful making es el proceso de creación de valor en el cual la innovación es un factor importante. Pero no siempre se puede o no siempre es bueno. Los ejemplos dados en el libro son la preparación de las obres teatrales, el desarrollo de software y la planificación estratégica. Pero es probable que estas ideas sean aplicables a la mayoría de los trabajadores del conocimiento, simpre que se den condiciones necesarias. Y la tendencia es que los trabajos son cada vez más asimilables a trabajo del conocimiento.
Industrial making es el proceso de creación en el que se replica lo hecho, mientras que en artful making se reconcibe, nunca se hace lo mismo. Es la forma en que se trabaja en las fábricas.
¿Cuáles son las características para poder hacer artful making?

• Necesidad de innovación
• Iteraciones cortas
• Repeticiones confiable

Para que las iteraciones sean cortas (alta frecuencia de entrega), deben ser baratas. El costo de iteración tiene dos componentes:

Exploración: probar caminos y soluciones alternativas. En una automotríz podría ser hacer un nuevo modelo a escala o un prototipo de un nuevo modelo.
Reconfiguración: cambiar el producto/proceso para mejorar el producto u obtener otro producto. Por ejemplo, en una automotriz, los cambios necesarios en las herramientas, layout, etc. necesarios para producir otro modelo.

También es interesante descripción y progresión descripta en el libro (con justificación económica) entre la forma de trabajo del artesano medieval, del ingeniero de procesos industriales (“white collar”) seguidor del scientific management y, por último, el trabajador de conocimiento, con sus puntos de contacto con el trabajo de los artistas. Tendría que revisar el post que hicimos hace unos meses sobre Ingeniería vs Artesanía.
Hay que tener en cuenta que el público objetivo del libro son los gerentes, de ahí el subtítulo “What managers need to know about how artists work”. Para ver la relación de la innovación con las personas que hacen el trabajo, es más apropiado el libro Free Play.
Hay algunos conceptos del libro que resuenan en la forma en que Tobias Mayer y Alan Cyment realizan las capacitaciones CSM. Y no es extraño, ya que ambos tienen background teatral. Y durante la organización de Ágiles 2008, Tobias se puso en contacto con Lee Devin, para que viniera. Lee estaba de acuerdo, pero lamentablemente no teníamos dinero confirmado en el momento en que lo hablamos. Volviendo a las coincidencias, la idea de trabajar al límite, sentirse ligeramente incómodo. No tan incómodo como para trabajar stressado y tan cómodo como para caer en la complacencia y no mejorar.
Otro punto que me parece muy bueno es el control liberando (Control by release), un concepto complejo de entender y transmitir. Creo que está bien implementado en Scrum: definir claramente los objetivos (tema e ítems en el backlog), imponer ciertos límites (iteraciones de duración fija con entregables definidos y calidad de producción) y dejar libre al equipo.

Muy recomendable, ¡no solo para los gerentes! (ajustado por el comentario de Nico :) )

¡Gracias a Diego Fontdevila que me lo prestó originalmente!

Panel CMMI vs Ágil (2/2)

Voy a comentar algunas de las preguntas que nos hicieron al panel (parte 1: resumen de las presentaciones del panel) y algunos pensamientos y situaciones que tuve luego del evento.

asistente: ¿Puede aplicarse ágil en grupos grandes?
yo: ¿qué es grande para vos?
asistente: El sistema de defenza de China
(no conteste, alguien más lo hizo)
Ugh? ¿acaso estaría esa persona en ese equipo? ¿si no, que interés práctico puede tener una pregunta así? Mi hipótesis es que hay una suposición subyacente: lo que es bueno a un proyecto enorme, debe ser bueno para un proyecto chico. Según esta hipótesis, los problemas de escalamiento sólo se darían al agrandar, no al achicar.

asistente (otro):¿cómo logro con ágil que todos los equipos trabajen en forma similar?
yo: ¿Por qué querés que trabajen en forma similar?
asistente: la compañía tiene que tener una forma definida de hacer las cosas
yo: ¿Qué valor de negocio tiene eso? (y comenté el caso de Toyota, en el que cada planta que hace el mismo vehículo tiene layout diferentes, y cada uno es óptimo en cuanto a condiciones locales)
asistente: pero los trabajos que hacen deben tener algo en común ...
(perdí la atención del asistente, y el hilo del diálogo fue hacia otro lado)

¿Por qué la unificación de las formas de trabajo es visto cómo una verdad indiscutible?

La semana pasada estábamos en una clase de la facultad, en la simulación de una retrospectiva. El problema a resolver era: requierimientos muy cambiantes.
alumno: una mejora sería "estandarizar el proceso de elicitación de requerimientos"
yo: ¿Por qué te parece que esto resolvería el problema?
alumno: está muy estudiado como deben obtenerse los requerimientos. Deberíamos incorporar esto a los procesos.
yo: ¿Pero eso ya se hace en la compañia?

alumno: ...

yo: Digo, porque si decimos que queremos estandarizarlos es porque en algún área o grupo ya se están aplicando y queremos llevarlo a otros, no?

alumno: ...

yo: Si no se usaron nunca, quizás debiérmos probarlos en algún grupo, antes de estandarizarlos

alumno: (cara de no estoy de acuerdo con lo que decis pero sos el docente)

Ya no es sólo la unificación dentro de una compañia, sino la unificación a nivel industria. Implísita está la idea de que debe haber sólo una forma de manejar los requerimientos.

Paréntesis

Recientemente me prestaron Artful Making, espero postear más extensamente sobre el libro, pero para este post basta con comentar que los autores plantean que hay dos formas de hacer las cosas: Artful Making, muy ligada a la innovación, con costo de iteración y de error bajo (ejemplos: teatro, software, estrategias corporativas); e Industrial Making, que es lo que ha tenido tanto éxito (revolución industrial), que nos parece como natural e innegable (producción en serie, economía de escala).

¿Qué encuentro en común en las sitiaciones descriptas arriba?

La idea de "la mejor solución". Esta es una visión Taylorista, en la que alguien pude analizar el problema y encontrar la mejor forma de hacerlo. Por lo tanto, los operarios deben seguir al pié de la letra esa solución, ya que es la mejor.

Esto tiene dos problemas: por un lado, si estamos en una situación que permitiría usar Artful Making, lo estamos perdiendo. Por otro lado, si estamos en una situación de Industrial Making, nos quedamos con métodos de principios del siglo XX. Todo lo aprendido a partir de los '60 por los japoneses, y a partir de los '80 por el resto del mundo, no lo aplicamos: Lean Production.

¿Es esto un problema?

¿Es un problema que algunas personas mantengan la idea de "la mejor solución"? Vuelvo sobre mi post CMMI y Agile, y le doy otra vuelta de tuerca, porque voy a tocar el proceso de evaluación.

En una charla con Mary Poppendieck, ella comentó los efectos nefastos y no deseados de las certificaciones: se incian tomando las buenas prácticas, se estandarizan, se instruye a los evaluadores y se los controla para evitar desvios y subjetividades, esto pone restrincciones externas a las empresas, que para no perder su status (certificación) establecen áreas internas que replican la idea de evaluadores que controlan el cumplimiento.

Todo esto genera una gran inercia. Si una empresa quiere innovar tiene que convencer a sus auditores, que tendrán que convencer a los evaluadores, que tendrán que convencer al organismo originador del estandar.

En el panel, yo noté exactamente esa dinámica. El movimiento ágil se desarrolló casi totalmente fuera del alcance del SEI y las empresas CMMI. Luego que tomó fuerza, se hizo notorio que es algo bueno, por lo que muchas empresas emprezaron a usarlo y el SEI se puso a trabajar (luego que las ideas llegaron al mainstream) en mostrar que CMMI no es incompatible con Ágil. Y ahora está tratando de convencer a sus evaluadores de esto (y le cuesta).

Replanteando la pregunta, ¿será que por construcción el CMMI refleja el mainstream, lo común, y no fomenta la innovación?

¿Puede incorporar el estado actual de las prácticas ágiles, pero inmediatamente lo congelará como el nuevo estándar, sólo para ser superado por las empresas que no son CMMI?

Técnicas para retrospectivas (resumen del libro Agile Retrospectives)

En las implementaciones de Scrum en las que participé, siempre usamos Keep/Change o alguna variante, para guiar nuestras retrospectivas.

Después de 4 o 5 sprints, cuando los problemas más obvios y fáciles están solucionados, las reuniones de retrospectiva empezaron a ser menos productivas. No siempre por la misma razón. A veces teníamos problemas difíciles de resolver, que siempre nos afectaban, pero a los que no le encontrábamos la forma de solucionarlos; en otros casos, surgían muchos temas para mejorar, los anotábamos pero con tantos temas, no poníamos foco, y muchos de ellos volvían a aparecer en la próxima reunión, y en otros casos, nos parecía que no había mejoras posibles.

En todos los casos, el empuje inicial disminuyó o se perdió.

Hace unos meses leí el libro “Agile Retrospectives”, de Esther Derby y Diana Larsen, que me dio muchas buenas ideas para mejorar las reuniones. Organicé actividades de retrospectiva incluyendo estas técnicas con algunos de los equipos con los que trabajo, incluso como retrospectiva de la materia con los alumnos de la facultad, donde fue la 2da mejor clase en la votación de los alumnos (la primera fue un Open Space). Creo que la mejor forma de aprender lastécnicas es probándolas, viendo que funciona en cada situación.

Pero es bueno tener una referencia rápida de todas las técnicas para, cuando uno está planeando una reunión, poder decidir cuales aplicar y cuanto tiempo llevará. Para eso hice un resumen de técnicas para retrospectivas es español, disponible libremente, gracias al permiso de las autoras.

Espero que les sirva y que me indiquen como mejorarlo (teniendo en cuenta que este resumen no reemplaza la lectura del libro).

Improvisación y Scrum

Hace unos meses estuve como co-trainer de Alan Cyment, en un curso de Scrum. Los asistentes pertenecían a una empresa que genera contenido multimedia que se publica en la Web. Los equipos son multidisciplinarios, e incluyen personas con skills en desarrollo de software, diseño gráfico, periodistas, expertos en video y comerciales. Una duda que surgió es si se puede ser creativo e innovador en un ambiente con limitaciones temporales, como cuando se aplican las reglas de Scrum. De la interesante discusión que siguió, Alan recomendó (y me prestó) el libro Free Play, de Stephen Nachmanovitch, que tiene una versión en castellano editada por Paidós.
Es un libro interesante, que recomiendo. Tiene muchas referencias a temas que no conozco: Tao, Zen, Judeo-Cristianismo y mitología griega, además de muchas citas a poetas y músicos. Pero eso no impide que la lectura sea amena, y que se puedan entender las ideas sin haber leído a William Blake, T.S. Elliot, Rimbaud, …
La alineación con ideas que se utilizan en Scrum es notoria. Van algunos ejemplos:
• La práctica: para poder improvisar es imprescindible tener dominio total de la técnica (por ejemplo el instrumento musical). Sólo cuando conocemos la técnica al punto de poder desentendernos y olvidarnos de ella, estamos en condiciones de crear improvisando, sin los planes y correcciones de una composición.
• El juego: Hay que disfrutar de lo que se hace, llegar a un estado lúdico. En este estado nos sumergimos en la actividad de una manera tal que se pierde la distinción entre lo que hacemos y nuestro yo. En el juego nos liberamos de preconceptos y podemos experimentar.
• El poder de los límites: es la referencia que surgió en la conversación que comenté al principio del post. La libertad absoluta no siempre buena para la creación. El tener límites nos obliga a focalizarnos y ser más creativos. A veces los límites son externos, a veces son autoimpuestos. Un ejemplo del libro son las improvisaciones de 1 minuto. Obvia correlación con el concepto de timeboxing.
• El poder de los errores: si experimentamos, estamos expuestos a tener errores. Pero los errores son una forma importante de aprendizaje y punto de partida para los próximos experimentos.
• El espectro que juzga: la idea de calidad es muy importante, pero si nos juzgamos de forma negativa, inhibidora, previa a tener sobre lo cual juzgar, llegamos a un bloqueo. En ese estado, nada es lo suficientemente bueno. Este espectro también aparece como miedo sobre la recepción que tendrá nuestro producto y trabajo. Puede originarse en un entorno negativo, pero finalmente somos nosotros los que permitimos que nos afecte.

En resumen, un libro para leer y releer. Ver también Artful Making

Reportaje a Mary y Tom Poppendieck

Este es un resumen de un podcast (entrevista hecha por Scott Hanselman). Espero tentarlos para que lo escuchen (al podcast) y para que vengan a Agiles 2008 para escucharlos en vivo (y quizás hacer el curso de Lean!)

Medida del éxito

Parten hablando de los criterios de éxito de los proyectos (y el famoso CHAOS report).
¿Es el cumplimiento de (costo, funcionalidad, tiempo) la medida del éxito? ¿Y por lo tanto el no cumplirlos es fracaso?
¿Qué pasa con la calidad, que pasa con el valor de negocio / satisfacción del cliente?

Podría ser mejor definir el criterio de éxito basado en:

• Éxito del negocio
• Para productos: participación en el mercado, rentabilidad
• Cuán rápido soy para generar soluciones (aprovechar oportunidades)

Para esto, debo armar el equipo para que trabaje desde el Análisis de la necesidad del mercado hasta la producción del producto rentable que cubra esas necesidades.

La trampa de algunas implementaciones de metodologías ágiles es que se limitan a la construcción de un producto basado en requerimientos, y esto es en muchos casos solo una parte de la cadena de valor.

Complejidad

Los P tienen una teoría llamada Measurement Up: si al triángulo el hierro (costo, funcionalidad, tiempo) no es suficiente para medir el éxito, y le agrego más variables (calidad, satisfacción) ¿cómo balanceo todas? ¿cuáles mido para administrar mi trabajo?

La propuesta es tratar de extraer alguna métrica más importante, que guíe a las otras. Por ejemplo, satisfacción del cliente, y el equipo debe derivar las otras métricas y sus relaciones y tradeoff. Esta complejidad es inherente al problema y no puede ser resuelta “mecánicamente”, con alguna receta.

¿Ágil es moda?

De los lenguajes compilados a estructurado a 4ta generación a CASE a objetos a CMM/I a Ágil ….

Cada 7 años (una generación de managers) tenemos una nueva “moda”, ¿por qué? Algunos por la búsqueda del Silver Bullet, otros por la mentalidad de crisis (ya que estamos mal, algo tenemos que hacer para mejorar). Pero lo más saludable es tener presente la complejidad y las tensiones inherentes a nuestro trabajo: arquitectura o entrega rápida, entender el problema (analizar) o explorar, etc.

Tenemos que buscar el balance que sea apropiado para nuestro caso. Pero tendemos a pasar de un extremo al otro.

¿Ayudan los consultores externos/tercerización?

Si nuestro negocio de resolver problemas de negocio/oportunidades de forma redituable lo hacemos a través de consultores o tercerizamos, porqué no podría hacer lo mismo nuestra competencia?

Entonces, como equipo, debemos aprender a resolver los problemas incorporando ideas, leyendo libros, etc, pero somos nosotros, los del equipo, los que sabemos que es lo mejor para nuestro negocio.

Es importante que el equipo hable de nuestro negocio, no “el negocio”, ya que eso pone al negocio como algo externo al equipo.

En algo pueden ayudar los consultores: trabajo adicional (cuando se hacen cambios, puede ser necesario hacer más que lo habitual), dar una perspectiva externa (incluye comentar ideas que funcionaron en otros lugares, recomendar libros), acelerar la adquisición de conocimiento (aprender de libro lleva más tiempo).

Pero es el equipo el último árbitro de que sirve en su contexto.

Para los que no lo leyeron aún, estos temas están incluidos en los libros de M & T

Self-directed work teams y Scrum. Comparando libros

El libro "Leading Self-Directed Work Teams", de Kimball Fisher, libro se refiere a la implementación de SDWT o Equipos de trabajo autodirigidos, en las organizaciones. Fisher prefiere el nombre High Performance Teams (HPT) o Equipos de alto rendimiento, ya que la idea de auto dirigidos o auto organizados suele interpretarse como sin líder, y no es así.

Por qué

El libro contiene una justificación de la utilización de HPT, un punto importante que tomo es que se incorpora a las empresas no porque es bueno para los empleados, sino porque es bueno para el negocio. Que además sea bueno para los empleados es un subproducto. Esto para mí es muy importante, ya que permite hablar con la dirección de la compañía sobre los temas de les importan (mejorar el negocio), y simplifica lograr que los empleados se sumen al cambio cultural ya que, al no depender de la personalidad de los mandos medios, tendrá más continuidad. Sobre este tema se vuelve cuando se describen las distintas formas de incorporar la cultura, desde la dirección, o desde los equipos.
A pesar de ser una parte interesante del libro, no es la más valiosa, ya que los ejemplos suelen estar alejados de la realidad de desarrollo de software e IT, y faltan ejemplos más recientes.

Cómo

Algunos temas particularmente interesantes son:

• Las cinco etapas de implementación del cambio (empowerment):
  Investigación (Entendiendo), Preparación (Aceptando), Implementación
  (Haciéndolo funcionar), Transición (Manteniéndolo), Maduración
  (Mejorándolo). En cada una de ellas se requieren cosas distintas por parte
  de los líderes. Se identifican 3 niveles de liderazgo: los directivos
  (Culture Leaders), los mandos medios (Management Leaders), los líderes
  operativos (Operational Leaders). Este último es llamado supervisor en la
  cultura de Teoría X y team leader en la cultura de Teoría Y.
• La descripción de la Teoría X (las personas sólo trabajan si alguien las
  controla y dirige) vs la Teoría Y (las personas se motivan y son más
  productivas si tiene libertad e información para actuar). Ver algo más de
  esto aquí.
• Mucho contenido sobre el impacto que tienen los mandos medios y los
  supervisores, como incorporarlos al cambio y cual es el rol en la nueva
  forma de trabajo, incluyendo las capacidades debe obtener, y ideas de como
  desarrollar esas capacidades. Incluso un cronograma de ejemplo de como
  evoluciona su foco y que tareas puede hacer para ejercitar. Dado que estos
  niveles son los más susceptibles a percibir negativamente el cambio
  ("pierden poder") y dado que son críticos para que el cambio sea exitoso, es
  importante incorporarlos.
• Ideas, concejos ejemplos sobre las actitudes que puede tener la gente
  ante el cambio (en cualquier nivel) y como puede ser manejada.
• Cómo lograr compromiso (Accountability). Fisher no toma la separación
  entre responsability/accountability (buena noticia para nosotros,
  hispanoparlantes, ya que tenemos una sola palabra para ambas), para él son
  una sola. Adhiere a la idea que una responsabilidad de muchos no es de
  ninguno, y plantea formas de lograr eso dentro de la idea de equipo.
• Cómo implementar HPT desde los equipos (nuestro jefe no está de
  acuerdo). Es posible, pero difícil. Esta parte es interesante, a pesar que
  no tienen recetas, al menos indica que debería pasar para tener éxito en
  esto. En muchos sentidos, lo veo similar a la situación de un consultor
  externo.
• Cómo hacer que el cambio sea sostenible. Esto incluye el esquema de
  remuneraciones y beneficios; el mantenimiento y desarrollo de capacidades
  técnicas en un ambiente en el que los se busca que los miembros de los equipos aprendan de los demás, tendiendo a ser generalistas; el mantenimiento en el largo plazo de esfuerzos en temas que son de larga maduración o contínuos (Start Point system) y que afectan a varios grupos.
• Los capítulos referidos a equipos de Information Workers y virtuales, no aportan tanto como algunos otros.

Comparando con los libros "The Enterprise and Scrum" y "Agile Project Management with Scrum", ambos de Ken Schwaber, encontré diferencias en el foco, no en el contenido.

• En Scrum, se dan reglas a los equipos, esto es equivalente a las Boundary Condition (condiciones de bordes) de Fisher, pero este último indica que se necesitan, da ejemplos, pero no las fija: interacción con lo que no es el grupo, organización interna en cuanto a avance, reuniones de planificación, demo, retrospectiva, reunión diaria, etc.
  
• Fisher da más detalle sobre como realizar el cambio cultural a nivel organización, aunque en esto hay superpocisión con el contenido de ""The Enterprise and Scrum".
• Fisher tiene mucho más tratado los temas relacionados con la inclusión y entrenamiento de los mandos medios y supervisores, para que sean incorporados a la nueva cultura.

En resumen, creo que las dos lineas de pensamiento y autores son complementarios y que la lectura de ambos enriquese la comprensión y da más herramientas para la puesta de práctica de HPT/Scrum :).