La agilidad de negocio son fantásticos para resolver problemas comerciales y las empresas continúan haciendo la transición a la agilidad para lograr los objetivos.
Pero pueden surgir problemas si se olvida que la agilidad de negocio es solo una metodología, un medio para lograr un objetivo, no el objetivo en sí.
Hay millones de artículos sobre las trampas (y el temor) asociados con la decisión de la gerencia de “volverse ágil” repentinamente.
Refleja la ilusión de que se trata de una implementación simple, como cambiar de proveedor de material de oficina, en lugar de un marco que requiere un cambio significativo de mentalidad y en la cultura de la organización.
La típica frase siempre es “Amazon lo está haciendo”, “Netflix lo hace” o “Spotify lo hace también”.
Buenos indicadores de que la empresa no ha definido claramente el “¿por qué?” es una de las primeras preguntas que hago cuando trabajo con una empresa en transición a ágil o cuando imparto una clase certificada de Scrum.
A menudo obtengo respuestas como:
- Adaptarnos rápidamente al cambio
- Realizar mejoras continuas
- Efectuar releases con más regularidad
Estos parecen grandes objetivos y se alinean con los resultados que esperamos de una metodología ágil.
Pero incluso las metas que suenan nobles pueden causar problemas y frustraciones cuando las persigue sin definirlas adecuadamente.
¿Cómo sabe que ha elegido el objetivo correcto?
Digamos que mi amigo me dice que quiere ganar $ 100,000 adicionales en los próximos 12 meses.
Probablemente lo alentaría a probar este objetivo para ver si es lo que realmente quiere.
Los cinco porqués es un enfoque bien conocido para descubrir la causa raíz subyacente de un problema y también funciona bien para descubrir las motivaciones subyacentes para perseguir un objetivo.
Si le pregunto a mi amigo por qué quiere los $ 100,000, puede responder que es para mejorar su estado, o tal vez dice que quiere remodelar completamente su casa.
Si aplicamos otro por qué, podemos descubrir una capa más profunda de lo que es importante para él sobre estas cosas.
Entonces podría decir que el estatus es importante para él, para demostrarles a sus padres que tiene éxito. O quiere remodelar para estar emocionado de volver a casa al final del día.
A medida que continúa explicando por qué algo es importante, puede comenzar a revisar el objetivo original y preguntar: ¿Es el correcto y está definido con suficiente claridad?
Por ejemplo, tal vez mi amigo no necesite $ 100,000 para demostrarles a sus padres que tiene éxito, tal vez solo necesite un coach de vida para darse cuenta de que es lo suficientemente bueno.
Y quizás todo lo que necesita para disfrutar de volver a casa al final del día es que un mejor amigo lo reciba.
Una buena meta también necesita buenas pautas
Después de un poco de discusión, mi amigo decide que definitivamente quiere dinero contante y sonante.
¿Cómo debería lograr esto?
Podría robar un banco. O adquirir el dinero a través de una estafa de criptomonedas al estilo Josef Ajram.
¿Debería considerar esas opciones?
Bueno, dado que mi amigo no es un genio criminal, hay muchas posibilidades de que lo atrapen y pierda la libertad.
También es una persona realmente decente, por lo que la idea de cometer un crimen probablemente le molestaría.
Claramente, reconocemos que además de elegir el objetivo correcto, también necesita pautas sobre cómo lograr ese objetivo (por ejemplo, no infringir la ley) y no comprometer las cosas que son importantes para él, como su libertad y sus valores.
Cuando tiene el objetivo correcto, pero la ejecución incorrecta
Conocí a un vicepresidente senior que quería usar Scrum para mejorar la colaboración.
Ese es un objetivo perfecto para este tipo de marco de trabajo.
Sin embargo, también creía que la colaboración solo se podría lograr si el equipo trabajaba físicamente en el mismo espacio.
Como resultado, trasladó a todos a una sala pequeña y estrecha e insistió en que todo el trabajo y las discusiones se llevaran a cabo allí, con todo el equipo involucrado.
Esto no solo era incómodo; también significó que un miembro que anteriormente había pasado unos días trabajando desde casa ahora tenía un viaje diario de ida y vuelta de tres horas.
La moral y la calidad del trabajo comenzaron a sufrir y así como la agilidad de negocio. Cuando entré para ver por qué Scrum no funcionaba para ellos, comencé preguntándole por qué quería mejorar la colaboración.
Me dijo que quería que los miembros del equipo tuvieran:
- Comprender en qué estaban trabajando otras personas, identificar brechas o ver dónde los miembros tenían exceso de trabajo para que pudieran ayudarse entre sí.
- Discutir con confianza y rapidez las soluciones a los problemas
- Comunicarse entre sí de una manera simple y clara.
Y nos dimos cuenta de que ninguna de esas cosas requería que alguien se sentara físicamente al lado de otra persona.
Al analizar la situación de nuevo, el vicepresidente se dio cuenta de que “colaboración” no significaba proximidad, y pudimos volver a examinar las diferentes formas en que podían trabajar para lograr los objetivos reales.
Cuando olvidas el por qué, es fácil dividirse
Trabajé con un Scrum Master que era nuevo en un equipo y entendía muy bien la agilidad de negocio.
Cuando descubrió que habían modificado algunas de las reglas, en su opinión, no estaban haciendo Scrum correctamente. Como Scrum Master, sintió que era su papel corregir al equipo y asegurarse de que todos estuvieran haciendo Scrum de la manera correcta.
Para hacer esto, duplicó las reglas, destacando los errores del equipo y aconsejando lo que deberían hacer en su lugar. Pero cuanto más presionó, más gente la rechazó y se convirtió en un ambiente tóxico de interminables desacuerdos.
Le pregunté por qué era tan importante hacer cumplir esas formas de trabajo. Ella me respondió:
“Porque así es como solía trabajar con mi equipo anterior y tuvimos mucho éxito”.
Le pedí que describiera cómo era estar en ese equipo y que compartiera por qué pensaba que trabajaban tan bien juntos.
“Hicimos clic. Nos animábamos el uno al otro incluso cuando cometíamos errores. Conocíamos las fortalezas de los demás, nunca nos preocupamos por pisar los dedos de los pies, realmente nos sentimos libres de entrar y hacer nuestro mejor trabajo “
En ningún momento dijo:
“Porque siguieron perfectamente el marco de Scrum y la agilidad de negocio”.
Cuando dimos un paso atrás, vimos que su rigor sobre las reglas estaba provocando tensión, desconfianza y disminución de la productividad. Su objetivo general era ser un equipo ágil de alto rendimiento, pero sus acciones a corto plazo estaban directamente en conflicto.
En lugar de centrarse en las cosas que su equipo hacía de forma diferente, empezó a fijarse en el objetivo que todos compartían, ser ese gran equipo ágil, y decidió centrarse en lo que estaba funcionando bien y crear una buena relación, en lugar de intentar arreglar todo lo que tenía. el pensamiento estaba roto.
Ponga a prueba las metas y asegúrese de que las pautas sean claras
Si tu organización está pasando a ser ágil, anima a los gerentes a poner a prueba esos objetivos cuando sea posible.
Descubre que es realmente importante.
Elimina la ambigüedad de lo que desea lograr como equipo, de modo que puedas ser creativo con tu enfoque en lugar de limitarte a reglas arbitrarias.
Y considera el costo que estás dispuesto a pagar. ¿Es importante la moral del equipo? ¿Es mejor atraer a menos clientes con promesas realistas, entregar de manera más confiable y generar más negocios repetidos?
Con los equipos deportivos, el éxito a menudo se relacionaba con los muchos pases desinteresados realizados por los miembros del equipo, con la forma en que los individuos anteponen el éxito del equipo a la gloria individual.
Veo que sucede lo mismo con equipos ágiles exitosos. Un equipo con el que trabajé estaba entregando a tiempo, pero se hizo evidente que el UX estaba sobrecargado de trabajo.
En lugar de considerar su propia capacidad individual al planificar y seleccionar tareas, los miembros comenzaron a pensar en la capacidad del equipo.
Decidieron que si una persona estaba luchando, todos estaban luchando. Un desarrollador abandonó algunos de sus propios elementos del Backlog pendientes para dedicar un tiempo a aprender a diseñar e intentar ayudar.
El equipo disminuyó la velocity a corto plazo, pero a largo plazo comenzaron a entregar más, ya que tenían habilidades más desarrolladas.
Si simplemente se hubieran centrado en ofrecer tantas funcionalidades como fuera posible en cada iteración, es posible que este progreso a largo plazo nunca hubiera sucedido.
Me encantaría conocer tu experiencia.
¿Están los objetivos claramente definidos y comprendidos?
¿O alguna vez has sentido que se estaba siguiendo un plan de negocios basado en palabras de moda?
¿Qué has encontrado que funciona bien al usar la agilidad de negocio y es ágil para resolver un problema de negocio o lograr un objetivo?
