DevOps es un área de mi interés desde hace varios años. En Diciembre de 2014, en la CAS de Barcelona, di una charla en Inglés sobre la experiencia haciendo que DevOps fuera uno de los pilares de la agilidad en la DVLA -Una suerte de DGT británica-. Hace un año y medio también publiqué un artículo introductor al tema de DevOps y Scrum.
Tres años después, veo que DevOps y su convergencia con Scrum sigue sin arrancar. Me encuentro con profesionales de ambas áreas que en lugar de colaborar, tienden a ensanchar aún más sus diferencias. Los motivos que encuentro son: Resentimiento de la comunidad técnica hacia el éxito de Agile y Scrum, Incapacidad para entender que operaciones forma parte del proceso de desarrollo y un conflicto personas vs procesos.
Resentimiento en la comunidad de operaciones hacia el éxito de Agile y Scrum
A pesar de que ahora pensemos que hemos reinventado todo, la comunidad de operaciones lleva muchos años manteniendo a raya los sistemas críticos de organizaciones grandes y pequeñas.
Se trata de profesionales muy especializados que han visto como el número de Agile Coaches, unos mejores y muchos peores, de pronto cobraba un protagonismo muy importante en las organizaciones que se habían encargado de mantener. Una pena. Y una fuente de frustración
Eso ha hecho que se crearan castas dentro de las propias organizaciones. Desarrollo tiene un papel muy importante mientras que operaciones siguen siendo los tipos del sótano que se encargan de seguir las instrucciones que mandan los de arriba. En ocasiones bajo las mismas restricciones presupuestarias.
Todo esto, unido a la baja calidad de muchos profesionales de Agile, muchos de los cuales no sólo carecen de conocimientos técnicos sino que los minusvaloran, ha creado una brecha todavía más grande entre las dos comunidades profesionales, haciendo que DevOps fuera casi un enemigo para Scrum. Y viceversa.
Incapacidad para entender que operaciones forma parte del proceso de desarrollo
Sorprendentemente, sigue existiendo una incapacidad para querer entender que en el ciclo de vida del desarrollo de Software, la programación pura y dura no suele suponer más de un 12% o un 15% del mismo. Ese software debe de ser diseñado, mantenido y puesto en producción, y a pesar de eso seguimos empeñados en que lo importante es programar, no tener productos terminados y usables por parte del cliente.
Cuando trabajamos usando Scrum, el objetivo no es el proceso, es el producto terminado. Los Sprint Reviews no son compuertas a la siguiente fase -operaciones-, sino que son herramientas para inspeccionar y adaptar nuestra táctica en función de la estrategia. Operaciones debe ser parte del Sprint y de los equipos Scrum. Dependiendo del contexto, puede que trabajen permanentemente dentro de un equipo o que vayan haciendo de consultores que están completamente disponibles para los equipos.
Conflicto personas vs procesos
Mientras que la tendencia en la comunidad ágil es hacia las personas, en la comunidad de operaciones es más hacia los procesos. Esta dicotomía es sólamente resultado de las diferencias que existen en el trabajo de ambas áreas. Mientras el trabajo en desarrollo esta más orientado a descubrir, el trabajo de operaciones está más orientado a ejecutar. Permíteme explicar eso. El desarrollo de Software es complejo, y continuamente tenemos que descubrir soluciones a problemas que no habíamos previsto. El trabajo de operaciones se enfoca en optimizar todo el proceso de puesta en producción y mantenimiento de ese software en producción. Mientras que la variabilidad es inherente al desarrollo y podemos obtener beneficios de la misma (por ejemplo, cuando descubrimos que optando por una librería en lugar de un diseño ad-hoc ganamos en rendimiento y mantenibilidad), la variabilidad es algo a evitar en operaciones. Hay que estandarizar el proceso.
Si además le unimos la baja calidad de algunos profesionales en Agile, eso provoca una desconexión total entre desarrollo y operaciones. DevOps tiene que orientarse a converger con Scrum, y es donde mejor resultado obtienen ámbos.
No todos los sabores funcionan en todas las organizaciones
¿Como resolvemos estos problemas? En primer lugar, adoptando una mentalidad crítica hacia Scrum y DevOps y luego entendiendo el contexto de la organización. No podemos cambiar organizaciones a martillazos, diciéndoles que lo que tienen que hacer es sustituir a todo su equipo de operaciones y dejar ese trabajo a los equipos de desarrollo. No es viable. No es una solución.
En lugar de eso, hay que intentar introducir una cultura que cierre las brechas que se explican más arriba para posteriormente ir mejorando nuestra capacidad de automatización. Un gran banco no puede, de la noche a la mañana, automatizarlo todo. Y es que eso no es DevOps. Es NoOps.
NoOps puede funcionar perfectamente en una pequeña startup, pero en el momento que hay que cumplir requisitos regulatorios, de negocio, seguridad, no es tan fácil automatizarlo todo. El reto está en volver a los orígenes, a la Agile Infraestructure que asentó las raíces de DevOps en sus comienzos. Muchos profesionales de operaciones insisten en que DevOps es automatización, cuando no lo es. Es mucho más.
Si quieres leer más sobre la convergencia de DevOps y Scrum, te recomiendo que eches un vistazo al whitepaper que hemos publicado conjuntamente con el DevOps Institute en Scrum.org