El peligro de los acuerdos baratos

No deja de sorprenderme la capacidad que tienen las empresas para adoptar buenas ideas, modificarlas a su gusto y convertirlas en terribles problemas. Lo peor de todo es que en general, todo este proceso está liderado por personas muy inteligentes y condimentado con buenas intenciones.

He aquí algunos ejemplos:

• Introducir métodos ágiles de desarrollo de software: la idea es buena si existe la necesidad. Muchas organizaciones adoptan prácticas sin saber para qué lo hacen. Muchas veces copian patrones y conductas sin entender el trasfondo. Comienzan practicando daily standup meetings y creen ser ágiles. Al final resulta ser una pérdida de tiempo y la organización queda con la sensación de que eso de la agilidad es una mala idea.
• Mezclar filosofías o prácticas incompatibles: Scrum es una buena herramienta. La única desventaja desde el punto de vista de algunas organizaciones es la falta de control y la dilución de autoridad y toma de decisiones. Qué tal si se mezcla Scrum con algo de autoritarismo, control y toma de decisiones centralizada. La combinación ideal? Mejor ni lo intenten!
• Scrum especializado: Es genial tener un equipo de desarrollo de software capaz de entregar software cada 14 días. Para ello sólo se necesitan programadores. Se les encierra en una pieza y se les deja tranquilos. No hay para qué mezclarles con expertos del negocio ni testadores, pues podrían distraerlos. Horror!

No lo sé. Me encanta mi trabajo. Me encanta ayudar a organizaciones a mejorar la forma en que trabajan para producir software. Pero a veces la creatividad para convertir buenas intenciones en resultados desastrosos me sobrecoge.

Serie Scrum / Agile: Malos hábitos

Hoy en día todo aquel que desarrolla software dice hacerlo de manera ágil. Casi todos dicen usar Scrum, Lean, Kanban o alguna mezcla de dichos métodos. Muchos, quizás la mayoría, lo hacen sin saber lo que se esconde detrás de dichas palabras. He visto algunos fenómenos, algunos engendros de agilidad que vale la pena discutir.  He tratado de condensar dichos fenómenos en una serie.  He aquí la lista de temas tratados hasta ahora:

• Agilidad sin autonomía - Jefe: "¡Sean ágiles, pero el que decide soy yo!"
• Agilidad sin información - Jefe: "¡Sean ágiles, pero no les digo lo que deben hacer!"
• Agilidad sin disciplina - Equipo: "¡Seamos ágiles, así no tenemos que preocuparnos de documentación ni procesos!"
• Agilidad sin aprendizaje - Equipo: "¡Seamos ágiles, pero no perdamos el tiempo conversando de lo aprendido ayer!"

El desarrollo de software ágil requiere de algunos ingredientes para funcionar.  Requiere reglas, autonomía, confianza, información y disciplina.  Exige también vivir religiosamente ciertos rituales que ayudan a un equipo a comunicarse de manera efectiva, a detectar problemas y sacarlos del camino, a crecer como equipo, a desarrollar en conjunto nuevas estrategias que permiten mejorar los resultados.

Quienes creen que se puede "transformar un equipo" a metodologías ágiles en 10 días, sin consultar a los afectados y sin hablar de profundos témas valóricos y éticos, no han comprendido la profundidad del tema.

Pretendo seguir publicando más de estos fenómenos a futuro, espero que ayuden a alguien a evitar los errores que yo he tenido la suerte de cometer.

Scrum / Agile: Malos hábitos IV - Agilidad sin aprendizaje

Todos dicen que desarrollan software de manera ágil.  Algunos hablan de lean o de scrum.  En las últimas  semanas escribí acerca de la importancia de la autonomía e información para los equipos que desarrollan software, esta vez escribiré acerca del aprendizaje y las retrospectivas:

IV. Agilidad sin aprendizaje

Eso de desarrollar software en iteraciones es una buena cosa.  Ayuda al cliente (o al usuario) a ver resultados parciales y decidir los próximos pasos a seguir. En Scrum se les llama "Sprint" a estas iteraciones. También se asocia con desarrollo ágil el sentar a todos los participantes del proyecto en un lugar y darle todas las herramientas que necesitan para resolver el problema.  Mucha comunicación, muy fluida y caminos cortos.

El peligro de tener a todos sentados todos los días trabajando juntos, es que se tiene la impresión de estar bien comunicados con los demás participantes, sin estarlo realmente.  También ocurre con frecuencia que se posponen las conversaciones que ayudan al equipo a crecer y mejorar, pues lo operativo tiende a ahogar a lo estratégico.

Un equipo de desarrollo de software debe juntarse periódicamente a reflexionar acerca de la forma como trabajan y buscar caminos para mejorar. A esta clase de reuniones se les llama "retrospectivas".  En mi experiencia hay que hacer una al final de cada iteración, sin excusas.  No hay ningún momento en el transcurso del proyecto, ni ninguna situación que justifique no tomarse unas horas para que todos los participantes de un proyecto piensen como pueden llegar más rápido a la meta.  

En las retrospectivas se trata principalmente de solucionar problemas interpersonales, de coordinación, optimizar la dinámica del grupo, mejorar el uso común de recursos (entre ellos el tiempo), evitar desperdiciar el tiempo en tareas innecesarias o repeticiones y en algunas situaciones, hablar acerca de como mejorar la infraestructura.  En todo caso, lo más importante de las retrospectivas es descubrir los problemas e identificar aquellos cuya solución produzca el mayor beneficio para el equipo.

He visto fracasar prometedores proyectos dotados de inteligentísimos miembros y experimentados líderes, porque en el calor de la batalla se han olvidado de conversar de lo realmente importante: de qué manera debe cambiar el equipo y su forma de trabajar para llegar más rápido y mejor a la meta.

Si trabajas en un equipo y en las últimas semanas no han "tenido tiempo" para conversar acerca de la forma en que trabajan y no han dedicado tiempo a pensar como mejorar, entonces es el momento de parar y hacerlo.  Nunca es tarde para empezar, y verás que dentro de poco el equipo comentará a cosechar frutos y a trabajar con mayor intensidad y satisfacción.

Uso de métricas en el desarrollo de software

Crees que es buena idea medir la eficacia y velocidad de tu equipo de desarrollo de software? Es bueno medir cuánto tiempo trabajan los programadores y cuántos errores encuentran al día los testadores? Cierto? No, la idea no es buena!

Si bien toda información puede ayudar a aprender y tomar decisiones, hay informaciones útiles y otras que conducen a decisiones erradas. Por qué no medir la satisfacción de los clientes? O quizás la de aquellos que trabajan día a día desarrollando el software? Será posible que exista una relación entre la satisfacción de un programador y el resultado de su trabajo creativo?

La era de las métricas materiales y tangibles está llegando a su fin.

Les recomiendo este excelente video de TED que habla tangencialmente acerca del tema.  No directamente relacionado con desarrollo de software, pero sí con las métricas y aquello que de verdad vale la pena medir.

Scrum / Agile: Malos hábitos III - Agilidad sin disciplina

Siguiendo con la serie de "malos hábitos" en desarrollo de software ágil que inicié hace algunos días, donde he escrito acerca de la importancia de la autonomía e información para los equipos que desarrollan software, me referiré hoy a lo importante que es la disciplina:

III. Agilidad sin disciplina

Hay quienes creen que basta con tener en el cajón del escritorio una carpeta que define el proceso o tener a alguien en el equipo que lleva el título de scrum master para tener garantizado el éxito en el proyecto de desarrollo de software.  Pero no se trata del nombre del proceso, o si se llama Scrum, Kanban o V-Model XT. Lo importante es que no es posible hacer software de calidad sin disciplina, y menos aún si se utilizan técnicas ágiles para el desarrollo de software.

En el Manifiesto por el Desarrollo Ágil de Software dice entre otras cosas que "Software functionando tiene más valor que documentación extensiva". Esta frase ha sido malinterpretada al punto que he oído muchas veces gente decir que el desarrollo Ágil de Software no es más que hacer software sin hacer planes ni escribir documentación. Lo cual no puede ser más falso!

Desarrollar software de manera ágil significa permitirle al equipo que la desarrolla encontrar los mejores caminos para hacerlo.  Implica también tener en el equipo gente capacitada y con experiencia, que sepa que el camino más corto no es siempre el más rápido ni el mejor.  Un equipo de software ágil sabrá por lo tanto:

• Que hay que documentar todo lo que sea necesario, pero no más. Hay que hacerlo de manera eficiente. No se trata de cumplir con una aburrida obligación, sino de guardar suficiente información para futuras decisiones.
• Que hay que testear desde el principio al fin, pues esa es la única garantía de que lo que el producto final cumpla con los requerimientos de calidad y que el usuario pueda hacer con el software lo que tiene que hacer. Idealmente, el equipo debe pensar como automatizar las pruebas de testeo para reducir el esfuerzo a futuro.
• Hay que respetar los acuerdos, pues esa es la única forma de trabajar eficientemente en equipo.
• Hay que imponerse metas agresivas pero alcanzables.
• Que si se tiene información o experiencia, hay que usarla y si no se tiene, pues primero hay que buscarla.  

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. 

Scrum / Agile: Malos hábitos II - Agilidad sin información

Siguiendo con el tema de los malos hábitos en el desarrollo de software ágil iniciado la semana pasada con este post, donde escribí acerca de la agilidad sin autonomía, me referiré hoy a otro problema que frecuentemente he visto en equipos que han optado por utilizar técnicas de desarrollo ágil de software.

II. Agilidad sin información

Desarrollar software de manera ágil significa que individuos (programadores, testeadores, clientes, arquitectos) trabajan (colaboran) juntos para producir software.  Para hacerlo, utilizan herramientas y procesos, pero ellos, quienes hacen el trabajo, son más importantes que dichas herramientas y procesos.  También utilizan documentación, pero miden el progreso del proyecto con resultados (software) y no con papeles llenos de documentación que nadie lee.

El equipo que trabaja para producir el software toma decisiones, para lo cual no sólo necesita la autonomía mencionada en el post anterior, sino que también necesita información fidedigna, correcta y actual.

El primer paso, es que el equipo sepa hacia donde debe ir.  Sólo así podrá tomar buenas decisiones y encontrar las mejores respuestas a la pregunta de cómo llegar a dicho objetivo. Debe saber toda la verdad acerca de las expectativas que se tienen del equipo.

El siguiente paso, igualmente importante es que el equipo cultive un ambiente de honestidad y apertura, donde todos sientan que pueden hablar con la verdad y que pueden confiar en lo que los otros dicen. Si no es posible lograr esto, recomiendo sinceramente desistir de usar cualquier técnica de desarrollo ágil inmediatamente, pues el equipo no logrará obtener los resultados que se esperan de él.

Uno de los puntos más frecuentes que un equipo debe acordar en este sentido es la definición de "terminado" (done). Cuando alguien afirma estar listo con una tarea, es importante que todos en el equipo entiendan qué es lo que ello significa. Si alguien dice que terminó una tarea, por haberse comprometido a ello y pese a no haberlo logrado, estará poniendo en riesgo al equipo entero, pues éste basará sus decisiones en información errónea.

El tema de la honestidad y comunicación abierta debe ser tratado en retrospectivas, para encontrar acuerdos que ayuden a un equipo a crecer y mejorar sus resultados.

La comunicación hacia el exterior, por ejemplo el estado de avance del proyecto, debe ser realizado de la misma manera: en forma directa y transparente.  Pues todo lo dicho antes acerca de la toma de decisiones dentro del equipo, también se aplica hacia afuera: otros proyectos necesitan también poder tomar buenas decisiones.

Scrum / Agile: Malos hábitos I - Agilidad sin autonomía

Existen algunos hábitos que dificultan o impiden aprovechar las ventajas de sistemas como Scrum o metodologías ágiles en general. He recibido muchas preguntas al respecto e intentaré ir posteando algunos de estos malos hábitos con cierta frecuencia, para compartir con ustedes mi experiencia, además de recibir vuestras ideas y comentarios.

I. Agilidad sin autonomía

No basta con decir que se utiliza Scrum, que se tiene un Scrum Master y un Product Owner.  No basta con trabajar en iteraciones y hacer reuniones de pie (standup meetings). He visto equipos que dicen ser ágiles, donde alguien (un gerente de proyectos o arquitecto, por ejemplo) prepara el proyecto de tal manera que lo único que resta por hacer al equipo que ha de implementar el software es ejecutar el plan que otro diseñó. Andes de empezar el proyecto, la arquitectura ya está definida, las tareas asignadas, incluso con estimaciones.  Ejemplar, dirán algunos.  ¡Un desastre!

El equipo debe recibir toda la información necesaria para poder DECIDIR.  El equipo toma decisiones, el equipo ha de entender el objetivo y ha de recibir lo que necesita para poder alcanzarlo.  Pero es el equipo el que decide qué camino seguir para llegar a la meta.  Cuando alguien decide de antemano qué camino debe seguir el equipo, se le está quitando autonomía, se le está restringiendo la libertad necesaria para que el equipo se sienta responsable de lograr el objetivo.

Un equipo de desarrollo de software ha de recibir lo máximo de información posible y lo mínimo posible de restricciones. Sólo así aflora la motivación intrínseca y la creatividad.