Agilismo como proceso de innovación

Siempre he tenido bastante claro que el desarrollo de software es un proceso de aprendizaje. Los desarrolladores no podemos plasmar en código aquello que no hemos aprendido de un sistema o del dominio del negocio. Ahora también lo veo como un proceso de innovación. Todo desarrollo de software es en sí mismo innovador, por que no existe antes aquello que quieres construir, teniendo cada desarrollo particularidades, que precisamente, llevan a tener que construir de nuevo por n-sima vez, un ERP.

Ser ágiles nos proporcionará un marco para la innovación, y para el aumento de la productividad en pos de la misma.

Para innovar, algunas recomendaciones pueden ser:

1. Fomentar la creatividad. La creatividad no tengo muy claro cómo fomentarla, pero sí cómo liquidarla: con un poco de "command&control". Se debe permitir a la gente equivocarse, reforzar el poder de los equipos para que sean sitios seguros.
2. Excelencia como hábito de trabajo. Debes cuidar cada detalle, huir de la mediocridad en cada cosa que haces. Si no, nunca inventarás el iOS.
3. Orientarte a resultados: La innovación debe producir algo tangible, y en estos tiempos, cuanto más rápido mejor. Mejor producir valor poco a poco, que hacerlo tarde.
4. El feedback hoy en día es fundamental. Para a analizar cómo lo estás haciendo, y reorientate de nuevo, hacia el buen camino.

Si te encajan esas cuatro recomendaciones en busca de la innovación, también verás que están algo dirigidas hacia donde me interesa: los principios ágiles. Y es que refuerzan, o se apoyan, no sé en qué orden :), en los cuatro principios básicos de todo agilista.

Hay muchos más consejos alrededor de la búsqueda de la innovación que encajan como un guante en los principios. O quizás, es que los principios son una base sólida para fomentar la innovación.

Equipos autogestionados y liderazgo... ¿oxímoron?

27/Nov/2018: Paso por aquí 7 años después ^_^ ya que escribo un post sobre liderazgo mucho más actualizado. No ha llovido nada desde entonces... además, se completa con este sobre Sociocracia 3.0 y cómo permite el liderazgo desde la autoridad distribuida. (Qué es la sociocracia y Toma de decisiones razonada)

En la búsqueda del equipo perfecto, me preguntaba si la autogestión en un equipo y el liderazgo son cuestiones contrapuestas. Jorge me decía que pueden parecer por falta de comprensión de la palabra liderazgo, y JMBeas le ha dedicado un post, hablando más del liderazgo individual.

Mi pequeño tweet iba más bien por otro lado. A un equipo autogestionado le considero así, por que son capaces de organizarse cómo hacer su propio trabajo entre ellos. Pero cuando dentro de un equipo hay un líder, en cierta manera creo que se pierde la verdadera autoorganización. Se rompe un principio de igualdad que considero básico entre los miembros del equipo, para llegar a ser un equipo de alto rendimiento.

Considero que si hay un líder claro en un equipo, este no es un equipo de alto rendimiento. Pero atención, creo que para llegar a ser un equipo de alto rendimiento autogestionado, es casi imprescidible pasar por la figura de un líder. Precisamente hoy A. Medinilla lo ha explicado genial en un hilo de agile-spain.

La democracia está sobrevalorada, lo importante es la unanimidad.

Esta frase, que creo haber leído a Jim McCarthy (pero que ahora no soy capaz de encontrar la referencia), me parece que da alguna clave importante a la hora de evaluar equipos. Si un equipo no es capaz de tomar decisiones por unanimidad prácticamente siempre, quedarán personas sin ver satisfechas sus expectativas. Aquel equipo que resuelve por unanimidad sus problemas, es un equipo unido, y alineado con una visión compartida.

Cuando existe un líder dentro del equipo, apostaría que algunos miembros de los equipos siempre aceptan decisiones suyas, sin hacerlas propias. ¿es entonces un equipo autogestionado, o uno con "jefes", pero internos en el equipo?

En una charla sobre liderazgo en equipos interfuncionales, pregunté al ponente si no podía existir equipos sin esa figura de líderes. Su respuesta es que sí, cuando se juntan un grupo de personas, por propia voluntad, y todos expertos y con mucha experiencia en su campo de actuación, con un objetivo claro. Estoy bastante de acuerdo. Si para ser experto se necesitan al menos 10 años, ¿cuantos equipos tienes preparados para una verdadera autogestión?

Por último, dos notas rápidas. Un coach en un equipo, no es lo mismo que un líder, por que ayuda al equipo, pero nadie le sigue. Y ojo, que puede haber equipos sin líderes, pero que ni sepan autogestionarse ni mucho menos sean de alto rendimiento :)

Agilismo a nivel táctico

Hace unos días discutíamos entre los "javeros" de Biko2 sobre las mejores prácticas, herramientas, librerías, automatizaciones que cada proyecto debería llevar en busca de la verdad, o sea, la calidad perfecta :)

Se empezó a hablar mucho de cuestiones concretas, y divagamos un poco sobre algunas herramientas o prácticas a incorporar o reforzar, que para eso nos encanta discutir como al que más. Estas cuestiones las asocio al nivel táctico de aplicación del agilismo en una organización, maniobras en corto plazo que son directamente aplicables para conseguir un fin sobre el campo de batalla. Pero me dio la impresión de que nos perdimos en siglas y nombres, y desglośe un poco por niveles lo que hallaba importante. Os extraigo pues un pedacito del email que envie en ese momento a mis compañeros, sobre los niveles de actuación para la calidad, como desarrolladores en labores técnicas:

• Programación: PMD o checkstyle (herramientas de análisis de código) nos ayudan a no cometer errores varios, aún teniendo que repasar las posibles reglas que pongamos. Pero cada linea que escribimos es una decisión que tomamos sobre la aplicación, y eso solo se resuelve con la inteligencia del desarrollador. Hay que saber cosas de SOLID, de gestión de excepciones, de gestión de logs,... etc. que NO SE PUEDEN AUTOMATIZAR.


• Ecosistema: El ecosistema nos puede comprobar que no rompemos el build, que tenemos buena cobertura de tests, que tenemos infraestrucutra pra hacer TDD, buenas métricas del sonar, despliegues automáticos, la gestion de merges/branches.... pero todo esto,no hay manera que nos lo haga solo... solo depende de la inteligencia, y ahora, también, el trabajo duro del desarrollador. Hay que saber de integración continua, de gestión de ramas,...


• Aplicación: A nivel aplicativo tenemos la definición de terminado-TER-MI-NA-DO, las pruebas de aceptación, o sea, la parte funcional. Aquí entra en juego lo anterior: la inteligencia y el trabajo duro, pero sobre todo, la responsabilidad y el compromiso del desarrollador, las ganas de hacer las cosas bien y emocionar al cliente.

Un saludo a mis colegas de Biko, que sé que me leen ;)