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.
El rol 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 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. Esto es común en implementaciones de Scrum.
Prácticas de Agile Business Analysis vs el Rol de Agile Business Analyst
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.
Los analistas de negocio, si quieren participar en proyectos ágiles llevados con Scrum u otro método, para ayudar a sus Product Owners deben de actualizar sus prácticas, porque no es lo mismo un analista de negocio en un proyecto en cascada que un analista de negocio en un proyecto ágil.
¿Quieres saber más?
Te esperamos el próximo 9 y 10 de febrero en el curso Agile Business Analysis en la Ciudad de México.
