En una empresa, decidieron adoptar Scrum hace aproximadamente un año, y todavía tienen BA (Business Analysts), que están separados de los equipos Scrum. Cómo funciona es:
Por lo general, los BA estarán bastante adelantados en el proceso, entre 3 y 6 meses antes. Estos documentos, una vez que el cliente (y el producto) los haya firmado, hibernarán hasta que el PO tenga espacio para recibirlos.
Aunque este proceso es pesado, la empresa no sabe nada mejor. ¿Cuáles son mejores formas de mejorar el proceso, acercarlo a lo ágil y mejorar el statu quo pesado?
notas
TLDR
Son un montón de ladrones de oxígeno que te están frenando. Conviértelos en personas útiles, deshazte de ellos o haz que cuiden de las abejas .
Mismo punto con más matices (posiblemente):
Los BA esencialmente están haciendo lo que debería estar haciendo el trabajo del propietario del producto y el cliente. Potencialmente, la preparación de historias es demasiado trabajo para que su PO lo maneje y necesitan ayuda adicional. Claramente, no necesitan tanta ayuda, ya que tiene una gran cantidad de inventario .
Me refiero al inventario en el sentido esbelto . Trabajo en progreso que cuesta tiempo hacer, cuesta tiempo hacer un seguimiento y probablemente se habrá vuelto inútil para el momento en que lo necesite. Esto último suena particularmente cierto, ya que me imagino que su PO pasa mucho tiempo reelaborando especificaciones obsoletas (o al menos espero que así sea). Además, esta enorme pila de especificaciones con exceso de trabajo hace una especie de broma con la idea de ser receptivo al cambio y erige una barrera (en el tiempo) entre el cliente y el desarrollador.
Estos BA se interponen en la comunicación entre los desarrolladores y el cliente . El desarrollo de software tradicional tiene muchos guardianes que separan a los desarrolladores (y otros secuaces de "bajo nivel" de los clientes). Uno de los valores clave de ágil es el rechazo de esto, la comunicación es clave. He tenido BA que se ven a sí mismos como dueños de la comunicación entre el cliente y los desarrolladores, y eso solo agrega confusión y demora la retroalimentación. El hecho de que, además, sus BAs no hablarán con los desarrolladores es terrible.
Entonces, ¿qué puedes hacer con estas personas? ¿Quizás hay algo que su equipo realmente necesita y que los BA son capaces de hacer, como probar o ayudar directamente a su PO?
Es más fácil decirlo que hacerlo. ¿Cómo empezamos a ser más efectivos dentro del status quo actual ahora? Aquí están algunas de mis ideas. He tenido algunas conjeturas sobre los problemas que están causando los BA, pero pase un tiempo con su equipo haciendo esto y proponga sus propias soluciones.
El trabajo está desactualizado y no tiene valor: No hay nada de malo en ignorar o descartar la contribución de alguien si no es positiva. Haga que su equipo de desarrollo PO + haga el retrabajo necesario en la comunicación con el cliente.
Falta de comunicación con el cliente: Evite los BA durante el retrabajo y hable directamente con el cliente.
Falta de "agilidad": use esta comunicación para asegurarse de que el cliente pueda acudir directamente a ustedes con las cosas que realmente quiere que se hagan con urgencia.
Yo diría que el papel del BA en el scrum/ágil moderno es exponer los requisitos de raíz y el valor policial . Esto no es algo que pueda suceder en el vacío; para ejecutar, el BA debe ser una tercera voz en la conversación entre el propietario del producto y el desarrollador. Elaborar:
Exponga los requisitos raíz: los propietarios de productos querrán brindarle soluciones cuando sus desarrolladores necesiten los problemas que deben resolver. Mover la conversación PO-Dev de "Necesito este botón" a "Necesito una forma de resolver este problema" es donde el BA agrega valor.
Valor policial: cuando los OP/Devs están totalmente sincronizados sobre el problema y la solución, está en el BA rastrear una necesidad comercial y garantizar que 'vale la pena exprimir el jugo' (a menudo dentro del contexto de un proyecto). Esta es una de las partes más difíciles de ser un BA ágil: señalar características que están fuera del alcance o que sufren un ROI cuestionable.
Este es un rol único que agrega valor de maneras muy diferentes a las de un desarrollador, PO o PM. Por supuesto, en muchos entornos de desarrollo, las responsabilidades del BA ágil serán absorbidas por estos roles, pero eso de ninguna manera significa que los BA son vestigiales. El hecho de que un contratista general haga todo el trabajo de albañilería, electricidad y plomería en un proyecto no significa que los albañiles, electricistas y plomeros estén obsoletos y deban buscar roles de transición.
Mi sugerencia es involucrar a la OP en el proceso antes. En lugar de esperar de 3 a 6 meses, involucre a la OP con los BA tan pronto como el análisis o la documentación estén listos. Antes de ser llevado al cliente.
El PO puede luego llevarlos a los desarrolladores, con el entendimiento de que los requisitos aún están en el aire. Esto también podría permitir el descubrimiento temprano de problemas; como un requisito que es simplemente tecnológicamente imposible.
Este tipo de desarrollo "ágil" es una de las razones por las que el desarrollo ágil se postula como muerto (incluso por parte de aquellos que idearon el Manifiesto para el desarrollo ágil de software) (1) .
Desde mi punto de vista, el mayor problema en su constelación es la distancia con el cliente. El desarrollo ágil consiste en involucrar al cliente lo antes posible .
En primer lugar, la OP debe establecer un canal de comunicación directo/sin filtrar con el cliente, desde el inicio del proyecto. En el mejor de los casos, esta debería ser una comunicación directa o al menos una comunicación sin filtrar a través de los BA. No funcionará cuando los BA organicen algunas reuniones/talleres a puerta cerrada y el OP obtenga un protocolo (de memoria) en el mejor de los casos.
Además de eso, el PO tiene que involucrar al cliente después/antes de cada Sprint. Tiene que pedir e incluso exigir amablemente comentarios del cliente, discutir requisitos nuevos o modificados en función de los resultados actuales y decidir las historias de usuarios próximas/recientes. Por lo general, el cliente no tiene tiempo para involucrarse tanto. El OP tiene que hacerle entender que su contribución es esencial para lograr los objetivos definidos del proyecto.
Además, asegúrese de que el cliente se interese en el desarrollo del proyecto (y no solo en el producto final). Así que asegúrese de que cada Sprint brinde un nuevo valor comercial para el cliente que está en discusión.
Una vez que el cliente se enganche, no olvide que, como PO, debe coordinar los cambios/requisitos, por ejemplo, estableciendo un proceso de gestión de cambios que funcione.
Finalmente, no se concentre tanto en el pesado proceso que tiene su empresa. Recuerde, las personas/individuos son más importantes que todo proceso en un desarrollo ágil.
Business Analyst es el nuevo desarrollador
A algunos BA les puede ir muy bien asumiendo el rol de miembro del Equipo de Desarrollo . Si estuvieran involucrados en la construcción/recopilación de un requisito, podrían verificar/probar que una solución es adecuada para el propósito. Antes de eso, podían emparejarse o agruparse durante la codificación real para guiar la implementación de una función para que se ajuste a su propósito con gran eficiencia. También podrían ayudar a producir cualquier artefacto, por ejemplo, documentación que sea parte de la Definición de "Terminado" para un elemento de la Lista de Producto. Recuerda, solo porque no puedas programar (todavía) no significa que no puedas ser un desarrollador en Scrum :D.
Propietario del producto Equipo FODA
Un Product Owner necesita apoyo para hacer bien su trabajo. Considere reclutar a algunos de esos analistas en un equipo dedicado a encontrar un nuevo valor para el producto, construir experimentos de productos (léase: nuevas características que se verifiquen científicamente), explorar las amenazas de la competencia y, en general, proporcionar análisis de mercado. Un propietario de producto bien respaldado de esta manera toma decisiones científicamente. Sin él, el PO puede quedarse mirando una bola de cristal en busca de predicciones. En resumen, quieres a Isaac Newton , no a Nostradamus . El crédito de la plataforma de diapositivas es para Mark Noneman y Madison Henry Group .
¡El poder de [Producto] te obliga!
Incluso los mejores productos pueden necesitar un poco de atención. No se trata de publicidad per se , sino de promoción. Podrían producir artefactos de documentación, por ejemplo , actualizaciones de blogs , artículos prácticos, demostraciones en video , o interactuar directamente con clientes que tienen problemas para usar o comprender el producto. Realmente cualquier cosa que sea necesaria para que un producto o característica se utilice bien.
Entonces, ¿qué dirías... Ya haces aquí?
Si no está claro que están aportando valor en su función actual, asegúreles con calma que su posición es segura pero su función no lo es. Pídales amablemente que consideren uno de los roles anteriores o que colaboren con ellos para crear una nueva forma en que puedan ayudar o ser parte de un equipo Scrum. Si no se mueven, puede ser el momento de ayudarlos con una transición de carrera si me entiende.
bobo2000
Tomas Owens
dqm
sahan de silva