¡Alerta de spoiler! La respuesta honesta es que no se puede imponer agilidad, pero se puede lograr mediante el consenso centrándose en los beneficios
por Isaac Sacolick
Incluso cuando los líderes proclaman en sus ayuntamientos que su organización necesita ser más ágil y ágil, no pueden obligarlo. Su CIO y los líderes de TI pueden estandarizar prácticas, métricas y responsabilidades que describen como estándares de metodología ágil, pero no pueden imponer que todos adopten culturas y mentalidades ágiles .
Puede seleccionar herramientas ágiles, automatizar más con prácticas de DevOps y habilitar programas de ciencia de datos ciudadanos , pero no puede forzar la adopción y exigir la felicidad de los empleados. Las operaciones de TI pueden operar una arquitectura híbrida de múltiples nubes , pero eso no significa necesariamente que los costos estén optimizados o que la infraestructura pueda escalar hacia arriba y hacia abajo automáticamente por arte de magia.
Entonces, si estaba buscando estandarizar rápidamente sus procesos ágiles, o abordar milagrosamente la deuda técnica cambiando a arquitecturas ágiles, o transformarse instantáneamente en una forma ágil de trabajo, entonces lamento decepcionarlo. La agilidad no es gratuita, barata ni fácil. No puede administrarlo en un diagrama de Gantt con líneas de tiempo fijas.
Y aunque creo que la agilidad es en gran medida una transformación de abajo hacia arriba , eso no significa que los desarrolladores, ingenieros, evaluadores, scrum masters y otros miembros del equipo de TI puedan impulsar la agilidad de forma independiente. El equipo debe trabajar en colaboración, reconocer las compensaciones y definir principios operativos ágiles donde haya consenso sobre los beneficios.
Entonces, si la agilidad no se puede exigir y requiere la contribución de todos, ¿cómo pueden las organizaciones volverse más ágiles? En el espíritu de las metodologías ágiles , las prácticas basadas en datos y la adopción de una cultura devops , aquí hay algunas formas en que todos en la organización de TI pueden impulsar la agilidad de forma colaborativa.
Defiende las metodologías ágiles
El capítulo 2 de mi libro, Driving Digital , trata de pasar de las prácticas básicas de scrum a un proceso de planificación ágil más completo que incluye la asignación de roles y responsabilidades, la planificación de retrasos de múltiples sprints y la estandarización de las prácticas de estimación. Cuando trabajo con equipos que intentan adoptar mentalidades y culturas ágiles, establecemos disciplinas de gestión de versiones, estándares arquitectónicos, principios ágiles y otras pautas para impulsar la agilidad.
Pero esto no se implementa de forma prescriptiva. Las diferentes organizaciones tienen diferentes estrategias comerciales, estructuras organizativas, culturas organizativas, talentos, requisitos de cumplimiento y combinaciones de arquitecturas heredadas y modernizadas. Estos contextos son increíblemente importantes al considerar cuándo y dónde aplicar diferentes prácticas ágiles.
Por ejemplo, una organización grande puede tener equipos trabajando en API para aplicaciones móviles que los líderes quieren que se desarrollen rápidamente y se entreguen a los empleados. Un segundo grupo puede estar trabajando para hacer la transición de un sistema heredado complejo que es fundamental para las operaciones de un negocio regulado, auditado y global.
¿Deberían estos dos grupos de equipos seguir prácticas ágiles idénticas, prescriptivas y reglamentadas? Eso ciertamente inhibiría al equipo de API, que sin duda preferiría (y probablemente sobresaliría) si la forma de ágil adoptada fuera más democrática y autoorganizada, y dejaría muchas decisiones al equipo. Por otro lado, dar demasiada libertad a los equipos que trabajan en sistemas heredados complejos y críticos para el negocio conlleva mayores riesgos.
La disparidad en los objetivos y las limitaciones es una de las razones por las que las organizaciones que luchan por la agilidad deben fomentar una cultura de hacer y responder preguntas de “por qué” al definir principios ágiles. Cuando los líderes dictan el cómo sin explicar el por qué, es menos probable que las personas adopten las prácticas subyacentes. Explicar los principios ágiles, especialmente el por qué, ayuda a los equipos a tomar mejores decisiones sobre cuándo, dónde y cómo aplicar prácticas ágiles.
Acelere el aprendizaje automático con dataops y gobernanza de datos
Me encanta la famosa cita de Spiderman: “Con un gran poder, también debe haber una gran responsabilidad”. Toda organización quiere que sus científicos de datos, asistentes de visualización de datos y analistas de datos ciudadanos produzcan conocimientos continuos que ayuden en la toma de decisiones. Pero este poder también requiere que los equipos de datos, análisis y aprendizaje automático adopten prácticas proactivas de gobernanza de datos y dataops que aborden los requisitos de calidad, seguridad, privacidad, gestión de datos maestros e integración de datos de la organización.
Por lo tanto, mientras los equipos de análisis se esfuerzan por ser más ágiles, ofrecer resultados con frecuencia y aumentar la cantidad de conjuntos de datos utilizados en análisis, los equipos de datos deben fortalecer las bases de procesamiento de datos subyacentes en función de los requisitos de cumplimiento y las expectativas comerciales en evolución.
Esa agilidad no se obtiene de forma gratuita o mediante mandatos. Los procesos de datos y análisis evolucionan cuando los equipos multidisciplinarios reconocen la importancia de la agilidad y trabajan en colaboración para mejorar la entrega de análisis y las bases del procesamiento de datos. Aquí hay unos ejemplos:
- Un programa ciudadano de ciencia de datos requiere que los departamentos participantes definan y mantengan el catálogo de datos y las definiciones antes de lanzar nuevas visualizaciones de datos.
- El equipo de ciencia de datos documenta sus modelos de aprendizaje automático, define parámetros de deriva y mantiene los modelos de producción en función de un ciclo de vida definido.
- Los equipos de calidad e integración de datos ven a los equipos de análisis como clientes o partes interesadas. Revisan regularmente la disputa de datos realizada por los equipos de análisis, evaluando y ajustando los modelos de datos y las integraciones para reducir el procesamiento de datos posterior.
- Todos los equipos que tienen la licencia para trabajar con datos revisan periódicamente los cambios en los requisitos de seguridad , cumplimiento y privacidad de los datos. Capturan brechas como seguridad, datos o deuda técnica y asignan prioridades al trabajo de remediación.
- Los equipos de operaciones en la nube y de dataops aumentan de forma proactiva el nivel de supervisión, planificación de la capacidad y automatización de la infraestructura para cumplir con los crecientes requisitos de rendimiento de los equipos de análisis y procesamiento de datos.
La agilidad proviene de la colaboración y el equilibrio del trabajo deseado con el trabajo requerido. De lo contrario, esta nueva generación de big data, machine learning y programas de BI de autoservicio generará fácilmente una nueva montaña de deuda de datos, silos de datos y riesgos de seguridad de datos.
Aplicar una mentalidad de cliente al madurar las prácticas de devops
Las organizaciones que adoptan culturas y prácticas de DevOps se esfuerzan por resolver una paradoja de TI de décadas: ¿Cómo se empodera a los equipos ágiles para que realicen cambios pequeños, frecuentes y de bajo riesgo en la producción que satisfagan a los usuarios y mejoren el negocio sin comprometer la confiabilidad, la seguridad y el rendimiento y otros niveles de servicio operativo?
Las prácticas y herramientas de Devops abordan las brechas en los procesos de administración de cambios de TI que conducen a incidentes importantes, problemas complejos que requieren un análisis de la causa raíz, dependencias complicadas de infraestructura que retrasan las implementaciones y problemas crónicos de seguridad. Algunos ejemplos de éxito de devops:
- Las organizaciones que utilizan nubes públicas y privadas automatizan la implementación y el desmontaje de entornos con una infraestructura segura como código .
- Los equipos de desarrollo ágiles automatizan las pruebas y optimizan las compilaciones e implementaciones con canalizaciones de CI / CD con desplazamiento a la izquierda . Los equipos más avanzados incluyen validaciones de seguridad en sus pipelines y adoptan devsecops .
- Las operaciones de TI mejoran su capacidad para administrar implementaciones complejas sin servidor, arquitecturas de microservicios y redes multicloud híbridas al aumentar el monitoreo y la implementación de plataformas AIOps para mejorar la visibilidad y la respuesta a incidentes .
Todos estos son ingredientes estratégicos para abordar la paradoja ágil y operativa de TI, pero sumergirse de lleno en estos programas sin una estrategia puede llevar a resultados de TI sin valor comercial. Peor aún, a veces puede hacer que TI invierta en exceso en automatizaciones a expensas de cumplir con las prioridades comerciales.
Por ejemplo, supongamos que está modernizando una aplicación heredada de tres niveles mientras la mueve a una nube pública y debe decidir qué nivel de automatización implementar. ¿Cómo definiría lo que es suficientemente bueno? ¿Y cómo debería definir los criterios para el éxito de las mejoras relacionadas con devops?
Hay preguntas y parámetros para ayudar a responder esta pregunta. Algunos podrían llamarlos requisitos de nivel de servicio. Otros pueden describirlos como requisitos no funcionales. En algunos casos, las partes interesadas altamente comprometidas exigirán lanzamientos diarios y cinco nueves de confiabilidad. En otros casos, será más difícil conseguir la participación de las partes interesadas necesaria para definir los requisitos.
Cualquiera de los escenarios plantea desafíos, pero el denominador común requerido para la agilidad comienza por definir a los clientes, las personas del cliente y los criterios de éxito. Cuando tiene partes interesadas demasiado prescriptivas, es importante separar los requisitos que solicitan de los requisitos que tienen sentido comercial racional. Y cuando sus necesidades están mal definidas, es especialmente importante documentar los criterios para el éxito.
Muchas organizaciones definen la gestión de productos o las responsabilidades de gestión de las relaciones comerciales para capturar y compartir las personas objetivo, los criterios de éxito y los requisitos comerciales. Llevar esta mentalidad de cliente a los equipos y prácticas de devops es una de las mejores prácticas que ayudará a la organización a determinar en qué automatizaciones invertir y en qué grado.
En resumen, la agilidad no puede exigirse. La agilidad se logra solo a través de la colaboración entre líderes y colaboradores. Los equipos ágiles deben operar con principios y estándares autoorganizados. Deben equilibrar la entrega de las mejoras requeridas por la empresa con el trabajo requerido para abordar la deuda de datos, operativa y técnica. Establecer prioridades, definir criterios de éxito y determinar qué es mínimamente viable requiere definir las personas del cliente y comprender sus necesidades y valores.
Cuando las organizaciones adoptan este tipo de prácticas, no tendrán que exigir agilidad. La agilidad se convierte en un valor compartido y el enfoque estándar para hacer el trabajo.
