Tengo un poco de una pregunta complicada, aquí. (Disculpas si proporcioné demasiadas explicaciones innecesarias; si es así, salta a 'El problema'). Primero, déjame explicarte...
Somos una empresa mediana con un departamento de desarrollo relativamente pequeño: 7 personas. Hasta hace poco, casi todo el trabajo que entraba era algo bastante pequeño, asignado a una sola persona, y la única gestión de proyectos era un sistema de tickets simple (que, de todos modos, nadie usaba con tanta frecuencia). Ahora, sin embargo, tenemos un proyecto de tamaño significativo, estimado en 18 meses. Por el bien de este proyecto, hemos comenzado a utilizar técnicas reales de gestión de proyectos, en este caso, Scrum.
Comenzamos el proyecto con un equipo de un desarrollador de empleados a tiempo completo, dos desarrolladores de empleados contratados, un propietario del producto (su título de trabajo teórico es 'director de proyecto', aunque debido a que no tenemos suficiente personal, terminó siendo también propietario del producto, BA y QA) y el propietario del proyecto, que es el CIO. Recientemente (hace unos meses) también agregamos a un desarrollador senior, que trabaja con tecnologías completamente diferentes y tiene algunos problemas para comunicarse de manera efectiva, a nuestro equipo para trabajar en ciertas tareas que solo ella puede realizar, o incluso comprender completamente. Todos los desarrolladores trabajan juntos, en un solo cubículo, mientras que el PO y el CIO trabajan en un edificio separado, a unos dos minutos a pie.
El PO es excelente, ya que recientemente completó un curso de Gestión de proyectos-Scrum antes de ser contratado, y los desarrolladores estaban ansiosos por obtener finalmente algún tipo de estructura de proyecto, por lo que en general obtuvimos una buena aceptación de ellos.
En cuanto al CIO, su opinión fue similar a 'No me importa cómo se organicen, simplemente háganlo'. Más tarde, esto se transformó en un ligero rechazo cuando se dio cuenta de lo diferente que era Agile de Waterfall al que estaba acostumbrado, pero como a todos los demás en el departamento no les gusta Waterfall, en su mayoría se retractó, pero tampoco se involucró.
Soy uno de los empleados contratados antes mencionados. También soy desarrollador junior... y también Scrummaster. Me doy cuenta de que es una elección extraña, pero dado que soy el único que ha tenido alguna experiencia real con Scrum, fui prácticamente nominado. No soy un Scrummaster certificado de ninguna manera, pero dado que llevamos un año en el proyecto y nada está en llamas todavía, creo que las cosas no van tan mal.
Comenzamos a hacer Scrum principalmente 'por el libro' ( Scrum from the Trenches , específicamente): reunión diaria (que consistía en desarrolladores), reunión previa a la planificación (donde solo los desarrolladores analizan los detalles técnicos de las historias), reunión de planificación ( donde los desarrolladores estiman las historias con la ayuda del PO), demostración, retrospectiva.
Sin embargo, para el standup diario, la demostración y la retrospectiva, el interés se desvaneció rápidamente.
Hubo varias quejas leves sobre el standup diario: "¿Por qué molestarse, cuando todos nos sentamos a dos metros de distancia todo el tiempo?" Cabe destacar el hecho de que ni el PO ni el CIO estuvieron presentes en las reuniones diarias (¿deberían haber estado?). Entonces, con el tiempo, cuando las personas llegaban tarde o estaban ocupadas y me olvidaba de realizar las reuniones, simplemente se eliminaron gradualmente y ya no las hacemos.
En cuanto a la demostración, originalmente teníamos al CIO involucrado, pero estaba preocupado de sofocar el proyecto después de que hubo repetidas ocasiones en las que mencionó un cambio y ese cambio no se implementó de inmediato, lo que lo llevó a creer erróneamente que queríamos que lo hiciera. dejó de proporcionar comentarios, por lo que dejó de asistir bastante temprano. Varios meses después de eso, se decidió que necesitábamos comenzar a tener control de calidad... a pesar de no tener un control de calidad. Entonces, el PO se vio obligado a convertirse en el QA. Y así, dado que ya había repasado cada historia durante el proceso de control de calidad, consideró que asistir a la demostración era redundante. Después de eso, la demostración se eliminó bastante rápido, ya que el enfoque cambió a completar las funciones en lugar de "perder" el tiempo preparando e implementando una demostración que solo verían los desarrolladores. YO'
Y ahora, a medida que nos acercamos al primer hito, aumenta la presión y las historias se vuelven cada vez menos definidas (¿mencioné que nuestro PO también es un BA y un QA?), las reuniones retrospectivas y de planificación previa han comenzado a caer a medida que bien. He recibido muchos comentarios positivos sobre la planificación previa, por lo que estoy seguro de que se recuperará una vez que pase el hito, pero me preocupa que la retrospectiva también pueda terminar muerta en el agua. Ni siquiera me he molestado en intentar incorporar a la desarrolladora senior a la retrospectiva, ya que está muy atrasada y trabajando en un montón de proyectos diferentes a la vez. ¿Debería intentarlo, independientemente? ¿Qué pasa con el CIO?
Si bien me doy cuenta de que parte de Agile es la capacidad de modificar los procesos para adaptarse al entorno, me preocupa que estas reuniones se hayan podado por error, o al menos prematuramente. Es posible que mi propia falta de comprensión o incapacidad para transmitir los propósitos de estas reuniones haya contribuido a esto.
¿Debería simplemente aceptar que estas reuniones no encajan bien en esta organización y permitir que desaparezcan? Si no es así, ¿qué puedo hacer para mejorar la aceptación de ellos? ¿Debo solicitar que el PO asista a los stand-ups? ¿Puedo/debo ejercer mi 'autoridad' como Scrummaster para obligar a las personas a asistir a estas reuniones (teniendo en cuenta que tengo poca autoridad formal, ya que mi puesto oficial es desarrollador junior, no Scrummaster)?
¿Qué debo hacer?
Hay dos partes en el rol de Scrum Master:
La segunda parte a menudo se descuida, pero es muy importante.
Si el equipo no ve el valor del enfoque de Scrum, dejarán de seguirlo rápidamente. El Scrum Master debe entrenar al equipo para asegurarse de que entiendan por qué tiene ceremonias como la de pie y la retrospectiva.
Si simplemente le dices al equipo que haga las ceremonias, tarde o temprano dejarán de hacerlo. Tienen que entender por qué las ceremonias son valiosas.
El Scrum diario es un ejemplo clásico. Muchos equipos tratan el Scrum diario como una reunión de progreso. Los equipos de desarrollo rara vez ven valor en las reuniones de progreso y, por lo tanto, a menudo se quedan en el camino.
Si escucha cosas como esta en su Scrum diario, entonces tiene un problema:
"Es casi el final del sprint y todavía tenemos mucho por hacer".
"¿Esa historia ya está arreglada? Nos estamos atrasando".
"¿Eso es todo lo que lograste hacer ayer?"
De hecho, el Scrum diario no tiene nada que ver con medir el progreso. Se trata de sincronización. Por eso las conversaciones en el Scrum diario deben estar relacionadas con cuestiones de sincronización.
Deberías escuchar cosas como esta en tu Scrum diario:
"Voy a reconstruir el servidor de control de calidad hoy, así que no podré hacer ninguna prueba"
"Ese error que encontramos ayer es un problema real. ¿Alguien puede ayudarme?"
"Ayer terminé la mayor parte de la primera página, ¿a alguien le gustaría ver una demostración?"
Vale la pena señalar que la mayoría de los equipos de Scrum tienen al Product Owner presente en el Scrum diario. Esto ayuda a reforzar que se trata de una reunión del Equipo Scrum en lugar de una reunión del equipo de desarrollo .
No invitaría a su CIO ya que no tiene un rol de Scrum y no es parte del Equipo Scrum.
Para las retrospectivas es importante darse cuenta de que se trata de mejorar. La idea en Scrum es trabajar de forma más inteligente en lugar de trabajar más duro .
Asegúrese de centrarse en demostrar valor en las retrospectivas. Por ejemplo, los equipos normalmente toman uno o dos elementos de cada retro y dicen que los arreglarán en el próximo sprint. Luego, en la próxima retrocomprobación, verifican que lograron realizar esos cambios. Si las retrospectivas solo se enfocan en los problemas y no en las soluciones, pierden valor rápidamente.
Finalmente, la revisión del sprint. Este es un aspecto clave de Scrum porque:
La idea de Scrum es que el equipo se enfoque en entregar valor al cliente . Si no está interactuando con sus clientes, entonces no tiene idea de si lo que está haciendo es lo que realmente quieren.
Es posible que esté trabajando duro, pero no tiene mucho sentido trabajar duro en las funciones incorrectas o en las funciones que no son una verdadera prioridad para las partes interesadas.
Scrum tiene exactamente un 'libro' autorizado: The Scrum Guide . Todavía no he tenido la oportunidad de leer Scrum from the Trenches (está en mi lista) y estoy seguro de que contiene información valiosa.
El propósito del Daily Scrum es que el Equipo de Desarrollo inspeccione el progreso del Sprint, sincronice y planifique. Si se lleva a cabo como un informe de estado o no se cumple el propósito , puede volverse obsoleto . El hecho de que los desarrolladores estén ubicados en el mismo lugar no significa necesariamente que estén trabajando juntos.
La falta de definición en las historias es un problema. Su objetivo es entregar valor al cliente de manera temprana y frecuente; si no sabes lo que quieren, esa es una meta imposible de lograr. Esto debe discutirse con el propietario del producto. El problema ciertamente sale a la luz en el evento Sprint Planning. Sería más visible si el refinamiento de la cartera de productos se produjera dentro de la iteración. Por lo menos, esto podría discutirse en las Retrospectivas de Sprint.
¿Se invitó a los clientes y participaron en las Revisiones de Sprint? Llamarlo una demostración niega su propósito y disminuye su valor. Hay un propósito extenso para el evento, perderlos crea un sinsentido. También es una oportunidad importante para recibir comentarios y aportes del cliente.
Si el equipo Scrum o el equipo de desarrollo no está trabajando en colaboración, ese es un problema de raíz que debe abordarse. Posiblemente era bueno que el CIO tuviera algo de formación, si fuera de calidad; hay mucho entrenamiento "ágil" que fomenta la ignorancia del Manifiesto y detalles como Scrum, DSDM y XP.
Vale la pena considerar los comentarios de RubberDuck cuando el equipo de desarrollo de software ágil y la organización están maduros para cumplir con los valores y principios ágiles.
Espero que esto sea útil y no demasiado inconexo en mi estado de sueño. Solicite aclaraciones si lo desea.
En primer lugar, no te preocupes por la "autoridad". Un Scrum Master es un líder servidor que logra cosas a través de la persuasión, no del decreto. Es su trabajo asegurarse de que las personas y el proyecto obtengan valor de las ceremonias.
La reunión más importante en Scrum es el Daily Scrum. Si dejamos pasar eso, perdemos el circuito de retroalimentación más estrecho que tenemos. Este stand-up es lo que nos mantiene trabajando como equipo , incluso cuando todos estamos enfocados en diferentes partes del proyecto: ese es nuestro impulso para pedir ayuda u ofrecerla cuando vemos que alguien no está progresando. Sin eso, es muy fácil seguir adelante solo sin ayuda. También es la mejor oportunidad para que el equipo (incluido el PO) comprenda si el sprint actual va por buen camino para alcanzar los Objetivos del Sprint y avisar con anticipación a las partes interesadas si queda claro que no los lograremos.
Dije "incluido PO" arriba, pero no su CIO. Mi recomendación es no requerir su presencia, ya que debería recibir actualizaciones adecuadas del PO durante el sprint y estará presente en la demostración al final del sprint para ver los resultados tangibles. (Por supuesto, asegúrese de que sepa que siempre es bienvenido como observador, pero que no se le permitirá descarrilar la reunión).
Si el equipo no se beneficia del stand-up, quizás se pueda mejorar. El problema más común que he encontrado es que no está enfocado y se prolonga demasiado con demasiados detalles. Intente hacer cumplir estrictamente un límite de tiempo de 30 segundos para que los miembros del equipo brinden su progreso hacia los Objetivos del Sprint y lo que pretenden hacer para la próxima parada. Cualquier discusión que no sea sobre los objetivos debe cerrarse para que la reunión pueda continuar; cualquier cosa que deba discutirse con más profundidad debe anotarse como un elemento "Reunirse después" para los afectados.
Es una muy buena idea tener los Sprint Goals bien visibles durante el stand-up, para ayudar a mantener el enfoque. Al mantener la reunión breve y enfocada, el equipo obtiene un mejor valor por el tiempo invertido en el stand-up, y usted debería sufrir menos por la atención desviada.
La próxima reunión más importante en Scrum es la Retrospectiva, porque sin una retrospectiva, no tenemos ningún mecanismo para mejorar nuestros procesos. Me gusta hacer mi retrospectiva en tres partes, con plazos ajustados:
Mantenerlo enfocado en identificar formas de mejorar ayuda a evitar que la reunión se convierta simplemente en una "sesión de quejas" donde los problemas se discuten sin cesar pero nunca se abordan.
Finalmente, ¿realmente está trabajando como un equipo , o simplemente como un grupo de individuos, cada uno trabajando en lo suyo? Si es lo último, entonces una forma de fomentar un trabajo más colaborativo es establecer un límite para el trabajo en curso que sea inferior al número de miembros del equipo. Eso significa que al menos una historia debe ser trabajada por dos personas juntas, ayudándolas a ampliar sus conocimientos y habilidades.
Tu historia me suena muy familiar. Deberías abandonar el scrum y hacer 'no-process'
Standups y Demos no son para el beneficio de los desarrolladores. Si su PO y CIO no los entienden o no se preocupan por ellos, entonces no está en condiciones de hacerlos funcionar.
Aquí hay algunas verdades duras sobre scrum.
El scrum diario: el propósito de esta reunión es informar el progreso al PO y garantizar que los desarrolladores no se desvíen hacia otros proyectos/funciones de baja prioridad o Facebook.
Si el PO no lo hace, al menos revise la pizarra para asegurarse de que se están haciendo las historias. No te molestes con eso.
La demostración de Sprint: este es el control de calidad, el PO y las partes interesadas pueden ver lo que se ha hecho. Los errores son evidentes de inmediato. Si las cosas se ven mal, pueden armar un escándalo.
Si las partes interesadas no se presentan a la demostración. no lo hagas
Todas las reuniones de scrum tienen buenos propósitos detrás de ellas, intentan facilitar la gestión de un proyecto, predecir si va a cumplir con los plazos, etc. Pero es realmente para un PM el que se preocupa por estas cosas. Si no lo hacen, debe concentrar sus esfuerzos en lograr lo que SÍ le importa a la empresa. Es de suponer que agregue funciones lo más rápido posible, que, suponiendo que las especificaciones sean comprensibles, puede poner sin reuniones.
pato de goma
Todd A. Jacobs
Sarov
alan larimer