Home » Preguntado y respondido – Espanol

Preguntado y respondido – Espanol

by admin

¿Qué es la criatura legendaria que llamamos Cambio de cultura? Sigo escuchándolo en los círculos de DevOps como la respuesta a todo, pero nunca lo he visto pastando tranquilamente en la naturaleza. Para separar el mito de la realidad, me conecté con Mike Burrows, autor del influyente libro Kanban desde el interior y De derecha a izquierda. Burrows también es fundador de Agendashift, una organización que ayuda a las organizaciones a cambiar para ser más positivas y productivas.

¿Que aprendi? Que las disciplinas de DevOps y Agile no son fundamentalmente defectuosas, pero las nociones preconcebidas de cómo implementarlas están plagadas de desafíos. Repensémonos esto e incluyamos principios como el liderazgo de servicio, para ayudar a abordar el objetivo real, que es que un cambio de cultura es una consecuencia de un cambio de discurso dentro de la organización, y no al revés.

Hacer esto bien puede cambiar el proceso de un ejercicio de arriba hacia abajo que a menudo está condenado al fracaso, a un proceso continuo que es inclusivo y productivo. Para obtener más información, siga leyendo.

Jon Collins: ¡Gracias por hablar conmigo, Mike! Vayamos directamente a eso. En los círculos de desarrollo de software, las personas ya luchan con nociones más simples como la integración continua, simplemente poder construir cosas de manera eficiente, y luego piensan que tienen que “hacer” DevOps de alguna manera. Y eso es parcialmente cierto, porque si no puede construir cosas rápida y automáticamente, entonces no las implementará muy rápido. Pero, en última instancia, muchas de las conversaciones se reducen al hecho de que todo lo que necesitas es un “cambio de cultura”.

Mike Burrows: ¡Esa es una de mis frases desencadenantes! Cuando la gente dice: “Lo que necesitamos es un cambio de cultura”, es lo que yo llamo mendigar el objetivo. De hecho, dice tan poco que es vacío. No dice nada nuevo en absoluto. No identifica los desafíos reales en absoluto. Es una frase tan vacía. La palabra cultura se usa con tanta frecuencia en formas que son lugares comunes.

Jon Collins: Todo lo que necesitamos son algunas fotos en las paredes con aforismos realmente útiles. Aquí está mi hipótesis: no existe el cambio de cultura. Sin embargo, lo que he visto es lo que llamo “El dilema del gurú”. Lo que sucede es que un “Gurú” de DevOps entrará en un lugar y marcará la diferencia. Ayudan a las personas a priorizar y cualquier otra cosa. Pero luego de eso, la gente sigue tratando de hacer las cosas que se les dijo, y luego, un par de semanas después, se rascan la cabeza y dicen: “Bueno, creo que fue un poco así”.

Y seis meses después están de vuelta donde empezaron. Lo he visto con DevOps y sus predecesores: Agile, DSDM, etc. Hay una curva de deterioro: con el tiempo, la gente vuelve a escribir.

Mike Burrows: Bueno, siento mucha simpatía por eso. La idea de que va a actualizar su organización, la forma en que actualiza su servidor de correo electrónico, es una idea ridícula que falla, más a menudo de lo que tiene éxito y, como usted dice, las organizaciones tienden a volver a escribir de todos modos.

Si va a la teoría profunda de la misma, debe mirar los fundamentos del desarrollo organizacional dialógico, que es uno de los fundamentos de Agendashift ahora. Esto se basa en el construccionismo social; su organización está construida socialmente, y si el discurso de la organización no cambia, ¡entonces realmente no ha cambiado en absoluto! Si realmente quiere cambiar fundamentalmente la organización, entonces su discurso tiene que cambiar.

Y eso probablemente comenzará con algunos nuevos tipos de conversaciones y ahí es donde comenzamos en Agendashift. No partimos de soluciones. No comenzamos con marcos, no comenzamos con vagones. Comenzamos con: ¿Qué estamos tratando de hacer? ¿Cuáles son los resultados que queremos lograr? Hacemos eso de una manera que confronta la realidad y es honesto acerca de los obstáculos que enfrentamos.

Jon Collins: Me alegra que haya introducido obstáculos, ya que, para decir lo obvio, estas son las cosas que hacen que el cambio sea tan difícil de hacer. Como he dicho más de una vez, “si fuera fácil, ¡todo el mundo ya lo habría hecho!”

Mike Burrows: Buen punto, pero es importante no ver los obstáculos como cargas. De hecho, los obstáculos pueden verse como una especie de molienda para el molino, convirtiéndolos en resultados. Está estableciendo algún tipo de dirección desde donde se encuentra ahora, y luego no se trata de implementar la solución: las soluciones son cosas que surgen cuando se necesitan.

El resultado también es mucho más centrado en las personas, más positivo para las personas. Al considerar los obstáculos como resultados, puede generar más complejidad, pero de una manera positiva.

Jon Collins: Si no se trata de un cambio de cultura, ¿se trata de honestidad, en el sentido de que nunca llegarás a este estado de Nirvana donde las cosas del día a día son simplemente “ágiles”? Vas a tener que afrontar el hecho de que seguirán apareciendo nuevos desafíos y así es como los afrontas. No hay futuro, un estado más fácil, pero se acepta que las cosas seguirán haciéndote tropezar.

Mike Burrows: Sí, aunque no debes negar que existe un cambio cultural. Sin embargo, creo que enfrentar la cultura como lo principal que hay que arreglar es contraproducente. La cultura cambia a través de un proceso natural, que involucra el discurso de la organización. Cambia a través de la experiencia y cambia al abordar algunos de los problemas que tiene la organización.

Pero lo más importante, creo que es el error tomar la cultura como algo separado de la misión de la organización. El enfoque que he aprendido y probado es convertirlo en una conversación de estrategia, que puede estar más o menos centrada en formas de trabajar.

Jon Collins: Entiendo. Bien, para llevar esto al extremo, ¿cree que no tiene sentido hacer que las cosas cambien sobre el terreno si no son cosas que son relevantes para la estrategia empresarial? ¿Es solo un ejercicio inútil?

Mike Burrows: Yo no iría tan lejos. Eso es un poco en blanco y negro. Para tomar un rumbo diferente, creo que los equipos tienen autonomía y, de hecho, tienen una estrategia propia.

Además, creo que es importante cambiar su visión de la “estrategia”. Tan pronto como aceptas que la estrategia es un proceso continuo, las cosas cambian drásticamente. Es algo muy bueno. Están sucediendo cosas y es necesario que haya mecanismos que mantengan esas cosas tirando en la misma dirección. Entonces, la estrategia se convierte en “mecanismos de alineación”.

Este principio es una de las aportaciones del Modelo de Sistemas Viables a la gestión empresarial. Se trata de identificar en qué niveles de la estrategia de la organización está sucediendo y qué mecanismos los mantienen alineados y los ven como procesos que deben estar conectados. Este enfoque es mucho más útil que ver los requisitos como un atraso que debe superar.

Creo que es vital dejar de ver el desarrollo o la implementación de estrategias como un paso a través de una acumulación de requisitos. En cambio, sugeriría comenzar desde el resultado, trabajar hacia atrás para comprender el proceso y alinearse con eso.

Jon Collins: Comenzar con el fin en mente. ¡Suena familiar! En términos de DevOps, esto me recuerda la creciente disciplina de Value Stream Management. En realidad, se trata de tener un proceso vivo, que responda a los cambios que puede medir. Como un organismo, el proceso reconoce qué tan bien lo está haciendo en ese momento, en función de lo que necesita lograr.

Mike Burrows: Sí, para tener éxito, el proceso debe ser adaptativo, con participación incorporada. No es uno en el que una parte de la organización imponga su voluntad. Las diferentes partes de la organización deben seguir hablando entre sí y deben trabajar para lograr los mismos fines; esto significa ser un mentor, en lugar de imponer o entrar en conflicto.

Jon Collins: Derecha. Lo que llamamos estrategia debe estar alineado en toda la organización. No es una especie de complemento. No tiene sentido tener esas conversaciones, no tiene sentido progresar, a menos que tengas ese nivel de alineación en primer lugar.

Mike Burrows: Lo llamamos una ‘Organización Adaptativa Deliberadamente’ (adapté eso de la Organización del Desarrollo Deliberadamente, el modelo en el corazón de Robert Kegan y Lisa Laskow Lahey Una cultura para todos). Cada nivel de la organización necesita tener estos procesos de estrategia adaptables y receptivos para ser saludable y viable. Cómo realizas, cómo mantienes estos procesos continuos indefinidamente, cómo se produce la organización. Todo esto es muy importante y emocionante.

Si la organización necesita producirse por sí misma (lo que hacen todas las organizaciones), esto se tratará de los sistemas, cómo se forman y se auto-perpetúan. Esto nos lleva al liderazgo, o específicamente a la noción de Liderazgo de servicio: tenga en cuenta que una de sus metas es producir la próxima generación de líderes de servicio; un proceso de auto-creación y perpetuación.

Jon Collins: Asegurémonos de mantenerme aquí: las organizaciones que se adaptan deliberadamente requieren un cierto tipo de liderazgo, que funciona desde atrás. Está diciendo que el liderazgo de servicio implica, esencialmente, una organización más orgánica que está respondiendo al cambio. No se trata de un líder fuerte que trabaje desde el frente. ¿Tengo eso bien?

Mike Burrows: Quiero ser claro, creo en el liderazgo, pero en el liderazgo de servicio y el liderazgo del anfitrión en particular. Estos son los tipos de modelos de liderazgo que más me atraen. Liderar desde el frente no va a tener éxito por sí solo cuando se trata de convertirse en una organización adaptable.

Podemos ver esto tanto en Agile como en DevOps, que intentaban resolver problemas inherentes a la forma en que se creaba el software, alrededor del cambio de siglo. Pero ninguno solucionó todos los problemas que estaban abordando.

Jon Collins: Creo que existe una especie de noción de “lugar mejor” de que lo que sea que estés haciendo en este momento está mal y deberías estar en un lugar mejor.

Mike Burrows: DevOps se estaba enfrentando a un problema real, que el desarrollo y las operaciones no estaban lo suficientemente bien integrados, pero de alguna manera, DevOps lo empeoró.

Hice un trabajo para organizaciones en las que enviaron a todos a capacitarse en Scrum y luego la gente de desarrollo se queja de que la gente de operaciones no viene a todas sus reuniones y la gente de operaciones se queja de que los equipos ágiles les están tirando cosas por la borda. Es la centralidad de Scrum Team. Y la idea de que ponemos un límite muy no poroso alrededor del equipo y estás en el equipo o no, vienes a todas nuestras reuniones o no eres bienvenido, ese tipo de cosas comienzan a crecer.

Y ahora tenemos otro problema, lo que Martin Fowler alguna vez llamó: “el complejo industrial Agile que impone Agile a las personas”. El dominio de Agile es ver procesos impuestos a los equipos sin ningún tipo de diálogo.

Debe haber una respuesta mejor que simplemente implementar un marco sobre los sentimientos de las personas que van a tener que trabajar de diferentes maneras. Pensando específicamente en DevOps, creo que la solución es el compromiso. Lo que eso significa en realidad es ayudar a los profesionales a participar y ayudar a las organizaciones a interactuar con su personal en condiciones de cambio.

Estamos contratando a personas inteligentes en el trabajo del conocimiento, y parece un poco loco que contratemos a personas inteligentes y caras y luego les digamos qué hacer y cómo hacer su trabajo, donde la mayoría de las personas que realizan el trabajo realmente entienden su trabajo. mejor que sus gerentes.

Jon Collins: Según el Irish Adage, si quieres llegar allí, ¿no empieces desde aquí?

Mike Burrows: ¡Algo como eso!

Jon Collins: Mike, me encantaría hablarte más sobre esto, ¡pero supongo que tendré que leer tu libro!

Mike Burrows: Ha sido un placer.


También puedes escuchar la conversación completa aquí.

You may also like

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Accept Read More

Privacy & Cookies Policy