Enterprise Agility Q&A (Parte 1)
Ali Cox
- Agilidad Empresarial
- Recursos descargables
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.
Recientemente escuché esto: tenemos una agilidad madura, por lo que no necesitamos BA. Nuestros grandes desarrolladores pueden hablar con las pymes. ¿Cuál es tu respuesta?
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.
¿Cómo puede la metodología ágil eliminar conflictos y aumentar la eficiencia durante la colaboración?
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.
Trabajo como Business System Analyst. Tuve que trasladar un proyecto del SDLC tradicional al Modelo iterativo para dividirlo en MVP iterativos a desarrollar, solo porque la política de mi empresa no tiene una mentalidad ágil debido a la emisión de una solicitud de cambio a nuestro cliente. Mi pregunta es si la mayoría de las compañías quieren congelar el requisito, ¿está sucediendo aquí lo mismo?
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.
¿En qué se diferencia Enterprise Agility de Scaled Agile?
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.
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.
Con respecto a la cultura, ¿cuáles son las restricciones clave que deben observarse para un cambio exitoso de mentalidad ágil?
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:
- Comprenda a su cliente
- Apoye y aliente la colaboración
- Fomentar el intercambio de conocimientos + transparencia
- Adoptar una mentalidad Kaizen
- Centrarse en el valor
- Perfeccionar las reglas comerciales para tomar buenas decisiones
- Conocer los datos y que se cuente historias a través de ellos.
- Comprender el negocio y las partes interesadas
- Seleccionar cuidadosamente las herramientas adecuadas
- Implementar buenas prácticas
Si no eres un líder, ¿cómo puedes promover una cultura ágil? El equipo de desarrollo de software de mi empresa utiliza prácticas y mentalidad ágiles, pero estamos limitados por las prácticas del resto de nuestra empresa.
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.
¿Qué es lo único que puede ayudar a impulsar el cambio de cultura y mentalidad?
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!
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!
¿Has estado involucrado en algún proyecto relacionado con las ventas y su adopción agile? ¿Puedes decirnos cómo fue?
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.
¿Puede dar más detalles sobre cómo podría aportar valor un “acuerdo de trabajo” a través de puntos específicos?
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?
¿Cuál es la mejor manera de convencer a las personas de mi organización de que Agile no significa que no hay documentación ni requisitos para analizar?
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?
¿Cómo podemos medir el valor además de los puntos completados por sprint?
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.
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.
¿Podría describir “persona” como método para empatizar con el equipo y el cliente?
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.
¿Puedes definir retrospectiva?
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:
- ¿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.
- ¿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.
- ¿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.
¿Quién define el “valor” a nivel empresarial que debe realizarse adoptando la agilidad empresarial?
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.
¿Qué piensas sobre la creación de un acta constitutiva de un proyecto Agile?
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.
