Enterprise Agility Q&A (Parte 1)

Dentro de nuestro partnership con IIBA, nuestra compañera Ali organizó un webinar en el que ofreció 10 consejos para facilitar la agilidad empresarial. Durante la sesión, recibimos varias preguntas muy interesantes que nos gustaría compartir con vosotros. Como no dispusimos del tiempo para resolverlas al completo, os proporcionamos un Q&A muy completo en el que intentaremos dar respuesta a todas las preguntas generadas.
De cualquier modo, si no pudiste asistir al webinar te dejamos la grabación disponible en el sitio web de IIBA.

La realidad es que el propietario de un producto no tiene las habilidades esenciales del análisis comercial, ni tampoco ha recibido capacitación al respecto, para poder comprender completamente cómo analizar las necesidades comerciales y traducirlas a necesidades funcionales/no funcionalies. Además, no podrá obtener el nivel apropiado de detalle para los desarrolladores, ni asegurar que los requisitos se entreguen con el valor esperado y previsto. Si bien un Business Analyst podría no ser necesario, su rol es crucial. Siempre aparece citado en muchas encuestas e informes como una de las habilidades necesarias y que no suelen aparecer en los proyectos IT. En el mundo VUCA, que hablamos en el seminario, estos perfiles con más que necesarios. Necesitamos pensadores críticos para ayudar a comprender los cambios, identificar las soluciones necesarias para abordarlos y comprender el valor que estas soluciones deberían y podrían ofrecer.

No es la metodología ágil lo que más ayudará con esto, es la mentalidad. Si bien las ceremonias del marco Scrum (por ejemplo) pueden ayudar a dirigir a los equipos sobre la cadencia y la estructura de la colaboración, lo que realmente cuenta es la mentalidad. La mentalidad implica:

  • Colaboración:  es decir, equipo de entrega y negocios trabajando juntos todos los días.
  • Comunicación: con conversaciones cara a cara.
  • Autoorganización: los equipos deciden la mejor manera de trabajar juntos, incluido un acuerdo de trabajo sobre cómo tratarse entre sí.

Creo que esa mentalidad requiere capacitación para aprender y mucha práctica para descubrir qué funciona mejor para cualquier equipo.

Hay una diferencia entre el acuerdo sobre lo que un equipo entregará en las próximas semanas (2 -4) y lo que van a entregar durante muchos meses o incluso muchos años de trabajo. Por lo tanto, si tiene que planificar y comprometerse con lo que va a entregar de 1 a 3 meses, sí, es probable que la compañía todavía esté bajo una mentalidad de cascada. Pero hay muchos matices ágiles y algunos métodos híbridos son realmente mejores para las circunstancias. Por ejemplo, si un cliente requiere que usted cumpla con un contrato estricto o una declaración de trabajo, el cliente debe ‘comprar’ ágilmente para que realmente funcione bien.
Scaled Agile, por ejemplo: SAFe o LeSS generalmente se usa para coordinar múltiples equipos Scrum que trabajan para la misma iniciativa, o a veces, múltiples iniciativas, de modo que cuando entran en producción con su solución, no se solapan entre sí. Las soluciones se prueban bien. Es aún más útil cuando múltiples iniciativas ponen productos al mismo tiempo.
Enterprise Agility en realidad no se trata solo de iniciativas o proyectos, sino de toda la organización que abarca los principios ágiles y la mentalidad hacia el aprendizaje continuo, la mejora continua, la colaboración y el autoempoderamiento, es decir, equipos autoorganizados.
La escala ágil podría ser parte de la estrategia de agilidad de una empresa.

Para mí, las claves en las que debemos centrarnos son:

  • Empoderar a las personas para hacer su trabajo y hacerlo bien. En lugar de un enfoque de comando y control que les dice a los empleados qué trabajo hacer durante x horas al día, los empleados quieren que les demos objetivos y visión.
  • Permitir que los empleados dentro de la organización colaboren bien. Es decir, asegurarse de que tengan las herramientas que necesitan para colaborar. Si no están ubicados conjuntamente, ofréceles las herramientas para permitir esa colaboración como si lo estuvieran.
  • Fomentar un ambiente de aprendizaje. Debes asegurarte de que las personas tengan la oportunidad de aprender y experimentar. Junto con eso, no castigue los errores o fracasos. Acepta algunos de esos fracasos porque ahí es donde aprendes. Esto permite a las personas experimentar y aprender y no tener miedo a las consecuencias cuando cometen un error una vez.

De todos los consejos que nos ofreció, ¿podemos establecer alguna prioridad?

Todos los consejos los establecí a través del orden que considero importante. Es importante no olvidar que hay comprender a al cliente, a la empresa y a las partes interesadas. Todo comienza por entender por qué estás haciendo lo que haces y para quién. Por lo tanto, si queremos establecer una prioridad rápida debería ser algo parecido a lo siguiente:

  1. Comprenda a su cliente
  2. Apoye y aliente la colaboración
  3. Fomentar el intercambio de conocimientos + transparencia
  4. Adoptar una mentalidad Kaizen
  5. Centrarse en el valor
  6. Perfeccionar las reglas comerciales para tomar buenas decisiones
  7. Conocer los datos y que se cuente historias a través de ellos.
  8. Comprender el negocio y las partes interesadas
  9. Seleccionar cuidadosamente las herramientas adecuadas
  10. Implementar buenas prácticas

Esa es una gran pregunta para la que no estoy seguro de tener una gran respuesta. Es difícil implementar prácticas y mentalidades ágiles si su liderazgo y el lado comercial no están de acuerdo. Pero mostrar éxitos es una de las mejores maneras de hacerse notar y hacer que la gente pregunte: “¡¿Qué están haciendo para tener tanto éxito ?!”. Cuando tenga éxito, intente llamar la atención sobre por qué tiene éxito si puede atribuirse a sus prácticas ágiles.

Es difícil decir una sola cosa, pero lo intentaré. La agilidad debe ser generalizada en toda la organización. Tienes que tener liderazgo involucrado. Deben comprender que no se puede simplemente decir “hazlo ágil”, tienen que defenderlo y ser ágiles ellos mismos. Tienen que entender lo que significa agilidad.
Hay un gran libro y video de David Marquet: Turn the Ship Around que habla sobre el liderazgo de servicio en el ejército que uso mucho con nuestros clientes. ¡Recomiendo echar un vistazo!

De hecho, utilizamos agile en Netmind y con nuestros equipos de ventas. Nuestros vendedores están facultados para tomar decisiones sobre los clientes, dados ciertos parámetros, por ejemplo, el margen que se espera de una propuesta o venta. También tenemos colaboración entre ventas y entregas (¡por ejemplo, yo!) Para asegurarnos de que entendemos el problema del cliente, lo que están tratando de lograr y que hacemos coincidir la solución propuesta con la resolución del problema o el logro de ese objetivo. También he participado en la capacitación de clientes para ayudar a los equipos de ventas y marketing a usar el marco Scrum y/o Lean Kanban para proyectos como construir SOW o una campaña de marketing.

Un acuerdo de trabajo es algo que recomiendo para cualquier equipo. Nos comprometemos como equipo a cumplir con ciertas normas y comportamientos. Aquí hay algunos ejemplos para agregar a un acuerdo:

  • Cuándo y cómo nos reunimos diariamente.
  • Cómo nos tratamos (respeto, honestidad, apertura, transparencia).
  • Para un equipo de desarrollo, ¿cuál es nuestra definición de preparado y definición de hecho?
  • ¿Qué hacemos con impedimentos, problemas, bloqueos?
  • ¿Qué hacemos si alguien está rompiendo este acuerdo?

Número uno: el análisis no es solo la documentación, es el pensamiento crítico involucrado para construir la solución correcta y entregar el valor deseado. Los requisitos nos ayudan a comprender el verdadero propósito comercial y la necesidad. Para la documentación, creo que el mejor argumento es la prueba. Por lo tanto, descubra qué documentación se necesita realmente en el proyecto y hágalo lo más visual y comunicativo posible. Demuestra su valía. La documentación no tiene que ser demasiado formal, solo necesita que esté presente ¿Por qué documentamos? Documentamos para:

  • Comprender cómo se tomaron las decisiones.
  • Aclarar y acordar una comprensión compartida de los requisitos. Los requisitos contienen el porqué y lo que debe contener la solución. Sin esto documentado, ¿cómo sabemos si los hemos cumplido? ¿Cómo no olvidamos los detalles? ¿Cómo recordamos porqué y qué hicimos para el próximo proyecto?

Recomiendo comprender cómo reacciona su cliente a lo que está entregando. Puede hacer cosas como encuestar al cliente y al Product Manager para ver si el producto realmente está resolviendo el problema planteado.
Además, mida nuevamente los objetivos del proyecto. Solo entregar un producto no significa que esté resolviendo el problema. Realmente se trata de determinar si el problema realmente se está resolviendo.
También recomiendo leer este artículo que mi compañera Jacqueline escribió para algunas métricas ágiles específicas.

Sí, una persona es solo una de las formas en que puede empatizar con el cliente. Creo que hablé sobre cómo he usado LEGO® Serious Play® para empatizar y comprender al cliente y el viaje que han llevado a cabo con nuestro producto. Para empatizar con el equipo, le recomiendo que eche un vistazo a la pregunta sobre el acuerdo de trabajo . Tenemos ejercicios de empatía muy poderosos en algunas de nuestras formaciones y en algunas termino con los ojos llorosos por la empatía con los mparticipantes.

La retrospectiva es una ceremonia para que un equipo u organización se miren a sí mismos para descubrir cómo mejorar. Básicamente, es el equipo u organización que se reúne para discutir estas preguntas típicas:

  1. ¿Qué estamos haciendo bien? Siempre queremos hablar sobre lo que estamos haciendo bien porque existe la posibilidad de que si no hablamos sobre eso, no podamos continuar haciéndolo.
  2. ¿Qué podemos hacer mejor? No se trata de señalar con el dedo ni de culpar, sino de ver qué podemos hacer como equipo u organización para la mejora continua.
  3. ¿Cómo podemos planificar para mejorar? Comprueba los resultados, priorízalos en función del valor y luego aborda las tareas de una en una. Por lo general, se busca salir de una retrospectiva con un plan.

El valor es diferente según sea la tipología de la organización. Por ejmplo, os dejo aquí algunos ejemplos de empresas en las que estoy trabajando:

  • Children’s Cancer Research Hospital: reducción en la tasa de mortalidad por cáncer.
  • Bancos: número de cuentas nuevas abiertas en los últimos 6 meses.
  • Seguros: número de pólizas nuevas.

Una carta o acta para un proyecto ágil debe incluir la mayoría de las actividades de alcance típicas que tiene un proyecto tradicional. Es decir:

  • Propósito del proyecto (¿por qué estamos haciendo esto?).
  • Objetivo(s) medible(s).
  • Comprensión compartida de los riesgos, tanto del negocio como del proyecto.
  • Impactos de las partes interesadas (sistemas, personas, partes involucradas).
  • Datos de alto nivel e impactos del proceso.

La diferencia en el estatuto sería elementos tales como el plan del proyecto y los hitos. Esos deberían centrarse en el desarrollo incremental (y típicamente también iterativo, dependiendo de qué tan conocida sea la solución potencial). Por ejemplo, se incluiría una hoja de ruta en lugar de un diagrama de Gant típico.

Únete a nuestra comunidad #AlwaysLearning

Formación

  • Sensibilización en la importancia de las e-Competences
  • Capacitación Técnica y en Gestión de la Tecnología
  • Formación a medida
  • Adaptación de contenidos propios a formación presencial y online
Buscar

Solicitar Información

Request Information