La importancia del Business Analysis en el mundo ágil
- Escrito por Vanessa Amaya
- Publicado en Blog
- Visto 3099 veces
La esencia más importante
de la agilidad está en el negocio
Iteraciones cortas no es sinónimo de agilidad. Entregas frecuentes no es agilidad si no se entrega valor de negocio: fácil de decir, no tan fácil de realizar.
En Scrum, aunque todos los miembros del equipo deben de conocer la visión del negocio, es el rol de Product Owner es el que se encarga de descubrir qué necesitan los clientes, recopila información de los involucrados relevantes, define la visión y los objetivos de negocio que deben de reflejarse en el producto y apoyar la gestión ligera de requerimientos basados en la expectativa de cambio.
En Kanban no hay roles predefinidos pero sus prácticas se enfocan en el flujo de trabajo contínuo, al flujo de trabajo entran los requerimientos priorizados y como no hay un sprint o iteración, el flujo es contínuo por lo que la priorización es constante, esa priorización está orientada a valor y a la capacidad del equipo, que en Kanban se especifica con un límite llamado WIP Limit (Work in progress Limit) para establecer cuantos requerimientos el equipo puede tener en proceso al mismo tiempo SIN sacrificar la CALIDAD.
Así que como verás, en ambos marcos de trabajo la orientación al valor y la priorización son importantes: aquí es donde entra el Business Analysis.
En Scrum, la responsabilidad de Product Owner está bien definido porque su base es la gran necesidad de que la visión de negocio, el refinamiento de requerimientos y la priorización estén presentes como parte del equipo, sin embargo, la definición choca con frecuencia con la realidad en los siguientes sentidos:
- *Los Product Owners (PO) que cuentan con el conocimiento y empoderamiento para ejecutar el rol, con frecuencia tienen a su cargo otras responsabilidades que les impiden estar dedicados a los proyectos ágiles de manera total e incluso parcial.
- *Se asigna el rol de PO a personas no adecuadas, no por falta de capacidad sino porque no cuentan con el empoderamiento suficiente para tocar la puerta de los involucrados relevantes ni para tomar decisiones sobre la marcha de los proyectos.
- *Al implementar la agilidad las empresas deciden con frecuencia invertir en capacitación solo para los Scrum Masters olvidándose de que quien ejecute el rol de PO también debe de contar con capacitación.
- *Muchas empresas dicen que hacen Scrum pero en el día a día, no se ve al PO por ningún lado, es más, con frecuencia los desarrolladores no conocen su cara.
- En resumen: ya sabemos lo que está mal y seguimos trabajando igual.
Prácticas de Agile Business Analysis vs el Rol de Agile Business Analyst
Exista o no exista un Business Analyst o un Agile Business Analyst en un equipo, las prácticas SI o SI deben de ejecutarse. Un Product Owner es quien más debe de desarrollar estas habilidades pero al final, la custodia y entendimiento de los requerimientos es de todo el equipo por lo que cada rol debe de hacer algo en relación a fortalecer esto porque: sin requerimientos claros no hay éxito, sin priorización no hay valor y sin entregas que reflejen los requerimientos no hay nada.
Agilidad o no Agilidad son fundamentales dos cosas:
- Ejecutar tareas de Business Analysis en los proyectos. Para poder asegurar que se trabajará en lo que el negocio y los clientes verdaderamente necesitan, con la calidad adecuada y considerando las restricciones que se tengan.
- Minimizar la cadena de comunicación entre roles de negocio y los desarrolladores. Siendo verdad que los roles de negocio y los desarrolladores son perfiles sumamente distintos, los roles intermedios deberían fungir como facilitadores de la comunicación, no como cadenas de comunicación. Es decir, ayudarles a comunicarse, no interpretar por ellos y burocratizar su comunicación.
Derivado de los dos puntos anteriores, un Product Owner debe de contar con conocimientos y habilidades no solo de sus procesos de negocio y de sus clientes, puede enriquecer lo anterior para realmente ser esa pieza fundamental que se requiere en los proyectos.
Si en un equipo hay división de roles, es decir, hay Product Owners y Business Analyst, es necesario comprender que el diferenciador principal es que quien porta con el rol de Analista no tiene el empoderamiento para priorizar, en cambio quien porta el rol de Product Owner si.
Los analistas de negocio apoyan al Producto Owner y al equipo para facilitar el entendimiento.
En Kanban, tener conciencia sobre la dimensión de los requerimientos y la aportación de cada requerimiento al valor esperado junto con la conciencia de la capacidad del equipo son pilares fundamentales para que el método funcione. Esta conciencia en Kanban se alimenta de ESTADÍSTICAS y las prácticas que hay alrededor de ellas también son importantes en el Business Analysis.
Los analistas de negocio que se iniciaron en proyectos en cascada, es vital actualicen sus conocimientos ya que no es lo mismo ser analista en un cascada que en agilidad.
¿Quieres saber más?
Contacto para inscripciones e informes
Escúchame en: