Sí, sé que has leído sobre Scrum, y en teoría parece sencillo (Si no aquí tienes la serie de post Scrum para Dummies). También puede que hayas aplicado las prácticas de Scrum, y después de unos cuantos sprints veas que el desarrollo software ha mejorado, pero no de una forma tan drástica como esperabas (Recuerda el post de síntomas de que la agilidad no está bien implementada en una empresa.).
¡Qué decepción! ¡Si iba a ser la solución a tus problemas! Es el momento en el que la ilusión inicial decae y relajamos la adopción de Scrum, hasta que se degrada totalmente. Y las mejoras siguen sin verse.
¿Por qué pasa esto? En mi opinión, después de haber vivido varios casos de implantaciones de este tipo, esto es una consecuencia de que malinterpretamos lo que significa Scrum y la agilidad.
A día de hoy, lo que suele pasar en muchas empresas es que se oye hablar de Scrum y de ser ágiles y se quieren implantar esas prácticas. Porque son nombres molones que venden, y suenan muy bien. ¿Quién no quiere ser como Spotify, Google y demás empresas chachis? Muchas consultoras venden la agilidad y Scrum para todo (por suerte en 233 Grados de TI aportamos más sentido común a las mejoras en desarrollo software :P).
Y así surgen los problemas. La raíz de todo es que muchas empresas no saben lo que significa ni lo que realmente implica ser ágil e implantar Scrum. Ni las diferencias entre ambos conceptos.
En mi opinión, lo que realmente aumenta la productividad y mejora una empresa es la agilidad. Y digo mejorar una empresa, porque aunque la agilidad nace del desarrollo de software, realmente es aplicable a otras disciplinas.
Y Scrum, es una de las tantas herramientas que ayudan a llegar a la agilidad (pero que por sí solas, no la garantizan).
Así que entendamos qué es cada cosa.
Agilidad.
Podríamos decir que la agilidad como tal nace en el 2001, cuando 17 representantes de varias disciplinas de desarrollo software (Scrum, Extreme Programming, DSDM, etc.) se juntaron para buscar una alternativa a los procesos de desarrollo software imperantes hasta esa fecha. Estos procesos de desarrollo software eran muy pesados, con mucha documentación y muy ineficientes para ciertos proyectos software.
Históricamente, la profesión de informática se ha desarrollando queriendo imitar el desarrollo industrial, equiparando la producción de una fábrica o construcción de cosas físicas y el desarrollo de software (Recuerda el post de Fabricar software no es lo mismo que fabricar coches o casas)
Hasta esa época, lo más típico era ver el desarrollo software como una cadena de montaje de un producto en una fábrica: con fases separadas que se realizan una única vez (toma de requisitos del cliente, desarrollo, control de calidad), roles especializados y sin creatividad alguna. Hacer lo que me dicen que haga.
Pero el desarrollo software por naturaleza no es así. Es una actividad creativa, que normalmente se realiza en equipo, donde la motivación, las habilidades personales y las relaciones entre las personas importan muchísimo.
El desarrollo software es lo contrario a una actividad física monótona, y por si fuera poco, está muy sujeto a cambios: porque la propia informática avanza muy rápido y enseguida te quedas desactualizado, porque el cliente muchas veces no tiene claro lo que quiere e incluso porque el equipo tampoco tiene claro al principio cuál es la mejor forma de implementar lo que necesita dicho cliente. Puede que tenga que hacer varias pruebas hasta encontrar la mejor solución, como un artista.
El desarrollo software es una disciplina muy técnica e ingenieril, y a la vez muy creativa. Los que estamos metidos en este mundillo vemos esas peculiaridades de nuestra profesión, pero es algo difícil de explicar y entender para alguien que no conoce esta disciplina, porque no parece que la gestión del desarrollo software sea algo tan complejo.
Así que lo que estas personas hicieron ese día de 2001 es asumir estas peculiaridades del mundo del software, y proponer un cambio de forma de trabajo en la profesión, acordando qué es lo que debería importar a la hora de desarrollar software.
Así llegaron a establecer las bases que caracterizarían al desarrollo ágil de software: el Manifiesto ágil, con sus 4 valores y 12 principios.
Estos son los 4 valores ágiles:
– Individuos e interacciones sobre procesos y herramientas.
– Software funcionando sobre documentación extensiva.
– Colaboración con el cliente sobre negociación contractual.
– Respuesta ante el cambio sobre seguir un plan.
Como ves, son muy simples. Una de las cosas que más destaca de este Manifiesto es que por fin se reconoce que el desarrollo software no es algo físico, y que las personas y colaboraciones entre ellas son muy importantes.
Además de destacar otros principios como la profesionalidad, la excelencia técnica y la mejora continua, que quedaron reflejados en los 12 principios ágiles.
¡Entonces adoptemos la agilidad!
Realmente ser ágil consiste en adoptar esos valores y principios. Digamos que:
– Un programador no es ágil, sino que demuestra programar con agilidad al desarrollar con calidad, mejorar el software y mejorar profesionalmente, etc.
– Alguien no trabaja en un equipo ágil, sino que un equipo demuestra agilidad al tener a miembros motivados, autoorganizados, orientados hacia un mismo objetivo, capaces de resolver sus conflictos y trabajar en equipo.
– Un equipo no es ágil por el uso de herramientas como Jira, tableros físicos, gráficos burndown, etc. Usa dichas herramientas para ayudarse hacia la agilidad.
Como puedes intuir, normalmente este cambio de mentalidad no es fácil, sobre todo si llevas trabajando y viendo el desarrollo software como la construcción de algo físico.
Pero además, adoptar un desarrollo ágil de software no puede quedarse solo en un cambio en el equipo de desarrollo.
¿De qué sirve querer adoptar los valores del Manifiesto ágil en desarrollo, si tu empresa tiene una política del miedo? Con cosas como:
– Aquí se hace lo que yo digo.
– No estás aquí para pensar.
– La creatividad no se valora. La única productividad consiste en estar 10 horas delante de un ordenador, no se mira nada más.
– El trabajo colaborativo es una pérdida de tiempo.
Y un largo etcétera.
Por eso últimamente ha surgido el rol del Agile Coach. Alguien que promueve y gestiona todos estos cambios culturales hacia la adopción de una cultura de valores y principios ágiles.
Si no promueves el cambio y si no fomentas una mejor colaboración y comunicación, al final las prácticas no van a calar en la organización, y no se van a notar tanto las mejoras.
Aún así, ten en cuenta que los cambios no se gestionan solos, ni los conflictos se resuelven mágicamente. Aparecerán conflictos y fricciones en el camino y cierta gente no tendrá la suficiente madurez como para trabajar de esa forma.
Pero ten en cuenta que es normal, ya que los seres humanos somos reticentes a los cambios por naturaleza. Por eso hay que ir definiendo estrategias para suavizar esa adopción, que deben estar promovidas y aceptadas sobre todo por la parte de gestión, de management (CEO, CTO, etc.).
Puede que todo esto te parezca muy hippie. Pero actualmente, una cultura de empresa sana es una de las muchas cualidades que caracterizan a las empresas de éxito.
¿Por qué ponemos siempre el caso de Spotify como éxito de escalar Scrum? Porque ellos han conseguido hacer de los valores ágiles, de la mejora continua y preocupación por sus empleados su cultura de empresa.
Y créeme, esto cuesta, pero funciona.
—
Y te preguntarás, y Scrum ¿dónde entra en todo esto? Pues es una herramienta que puede ayudarnos en el camino hacia la agilidad, pero tener Scrum no implica ser ágil.
La semana que viene veremos cuál es la idea detrás de Scrum, qué tiene que ver con la agilidad y qué es realmente Scrum (y qué no) adaptando los valores ágiles.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Adoptar Scrum no implica ser ágil, de la misma forma que tener arroz no supone comer paella.
¡Exacto! Esa es la principal idea que quiero transmitir con este post y el de la semana que viene. Lo que me encuentro es que en muchas empresas eso no está claro, y por eso surgen problemas y decepciones.
Gracias 😉
No puedo esperar al post de la semana que viene! Cuánta razón hay en este post!
Yo pienso que hay varios factores a considerar:
• Adoptar Scrum como metodología, e inclusive “ser ágil”, no son fines en sí mismos; son medios para conseguir fines últimos: para el caso de una empresa que hace software, el fin último es hacer software que le funcione a sus usuarios y que sea fácil de mantener y expandir en funcionalidad.
• Una empresa se puede liar la manta a la cabeza y emprender el proceso de “implantar agilidad”, pero si no lo hace con convicción sino porque está de moda o por cubrir el expediente no va a llegar a ninguna parte.
• Así como abunda la cultura de “Aquí se hace lo que yo digo, no estás aquí para pensar”, yo estoy cansado de ver técnicos que dicen “yo soy programador y yo programo esto que fue lo que me dijeron que programara y no hago nada más”, alguien que piense así y se quede tan ancho nunca programará con agilidad.