La idea de este post surgió de un debate en LinkedIn sobre el papel del Scrum Master y si es similar al de un entrenador de fútbol o no (no, este post no trata sobre Scrum ni sobre el papel del Scrum Master) y sobre si el Scrum Master tiene que saber construir software o no. Para ser sincero, para mí la idea de un Scrum Master como un entrenador de fútbol, dando órdenes desde el banquillo, decidiendo quién va a jugar y quién no, marcando la estrategia, etc., no es mi idea de Agile. Por supuesto, alguien tiene que tomar decisiones, pero en mi opinión esa persona no podría ser siempre la misma y debería ser alguien que trabaje “desde (dentro) y para el equipo” en lugar de “solo para el equipo”.

Me di cuenta de que no hay una visión compartida sobre Agile y cómo se aplica para construir mejor software. Y también me di cuenta de que, a veces, hay objetivos diferentes según los roles:

• Uno, centrado en aplicar el proceso completo (Scrum, SAFe, Less, …, lo que sea) y liderado por el “equipo agile”.
• Otro, centrado en tratar de construir (no de entregar) el software requerido y liderado por el “equipo de desarrollo”.

Para mí, debería haber un objetivo común: entregar buen software cuando se espera.

Debo decir que no soy un “Agile Coach” profesional, aunque obtuve algunas certificaciones agile y me gusta mucho “la parte de metodología” de la construcción de software. Basándome en mi experiencia construyendo software durante muchos años, creo que deberíamos volver a lo básico, “El Manifiesto Ágil”, y poner el foco, de nuevo, en la construcción de software en lugar de simplemente seguir un método.

Volver al “Manifiesto Ágil”

No voy a explicar qué es el “Manifiesto Ágil”, pero os recomiendo volver a leerlo. De este manifiesto, me gustaría destacar algunos puntos:

• El título es “Manifiesto por el Desarrollo Ágil de Software”, por lo que es un manifiesto de desarrolladores para personas que trabajan en software.
• Los autores (17) son desarrolladores de software.
• El primer valor es “Individuos e interacciones sobre procesos y herramientas” y todos acordaron ponerlo en la primera posición.

… (resto del post traducido) …