Sospecho que los problemas en los equipos de Scrum en mi organización actual superan este aspecto, pero quería centrar la pregunta más específicamente en cómo se puede hacer Scrum mejor de lo que se está haciendo actualmente.
Somos una organización nueva en Agile/Scrum y tenemos muchos desafíos. Estamos estratificados horizontalmente hasta el punto de la pura locura en la que casi todos los aspectos del software y la tecnología se han proporcionado a través de algún equipo de plataforma empresarial externo que monopoliza un aspecto increíblemente específico de un sistema de software general (por ejemplo, equipo ESB, equipo de informes, equipo DBA, Equipo de Tareas Programadas, Notificación de Eventos Empresariales, etc...)
Nuestro proyecto es una especie de centro con una cantidad absurda de interfaces externas que entran y salen del software que estamos tratando de entregar. Tenemos muchas, muchas, muchas capas de abstracción de negocios y operaciones, analistas de operaciones comerciales, propietarios de productos y analistas de sistemas comerciales que definen requisitos funcionales detallados en forma de historias de usuarios y criterios de aceptación.
Este proyecto tiene un gran presupuesto, por lo que formaron dos equipos de scrum, pero para mis objeciones extremadamente vocales, la decisión del maestro de scrum fue segregar horizontalmente los dos equipos de scrum de modo que un equipo de scrum entregue las historias de los usuarios para las partes interesadas mientras que el otro equipo de scrum entrega en historias más técnicas y de interfaz en una forma digerible para el otro equipo de scrum. Mis objeciones desatendidas fueron que una historia de usuario debería ser un corte vertical completo, de lo contrario, perjudicaríamos nuestra capacidad de ser interfuncional. El argumento en contra del mío es que incluso la parte más simple y atomizada del valor comercial no podría entregarse en un sprint de dos semanas debido a la cantidad obscena de dependencias externas que requiere cualquier historia. En cambio, el segundo equipo trabaja por delante del equipo de historia de usuario.
Todo esto está fallando miserablemente en la práctica, pero a pesar de todo esto, el mayor problema aún es que nuestras sesiones de preparación de tareas pendientes y planificación de sprints tardan más de 8 horas en completarse.
Nuestro scrum master insiste en que no podemos finalizar la reunión hasta que haya suficientes historias listas para el próximo sprint, pase lo que pase. La mayoría de las historias simplemente no están listas en términos de requisitos, creo que la historia del usuario es clara y los criterios de aceptación tienen sentido. Constantemente trato de sofocar las discusiones técnicas profundas prolongadas de las que los técnicos en la sala insisten en hablar hasta la saciedad, pero por lo general me doy por vencido después de un tiempo y dejo que hablen sobre cualquier ansiedad que tengan.
Originalmente traté de tomar una postura dura en las reuniones y llamar a la historia No Listo y regresar a Backlog, sin embargo, el Product Owner frustrado me estaba sermoneando que no estamos logrando aportar nada útil en el próximo sprint.
A continuación, traté de pedir un regreso a Sprint Zero porque todavía no estamos listos para trabajar en nada. Está claro que el Equipo Scrum necesita más orientación sobre los requisitos y el diseño de alto nivel, y como soy responsable de la arquitectura del sistema, estoy de acuerdo en que nos estamos moviendo demasiado rápido para dar el nivel de detalle de diseño que los técnicos creen que necesitan. para trabajar en una historia. Trato de compensar esto estando completamente disponible para preguntas o inquietudes durante el sprint, pero eso no alivia la ansiedad que siente el equipo sobre la inminente humillación pública que se produce cuando están de pie y tienen que admitir que no. No sé qué hacer y que su historia está en peligro una vez más. El Scrum Master hace caso omiso de mi llamado para Sprint Zero e insiste en que no vamos a cumplir con nuestros estrictos plazos reglamentarios de alcance mínimo si "perdemos tiempo" en Sprint Zero. Es una posición completamente inmutable de la que se niega a renunciar.
Por lo tanto, nuestra preparación de Backlog y la planificación de Sprint se han convertido en sesiones de más de 8 horas en las que esencialmente hacemos todo lo posible para reunir los requisitos y los detalles de diseño para cada historia, y donde las discusiones pueden durar más de 45 minutos en cada historia.
Toda esta experiencia me hace preguntarme si Scrum simplemente no se adapta a grandes proyectos en la práctica.
¿Qué más puedo hacer como arquitecto técnico para ayudar a sacar el proyecto de esta espiral de muerte viciosa en la que se encuentra? ¿Cómo puedo ayudar al equipo a llegar a un punto en el que podamos preparar, dividir y dimensionar una historia en menos de 10 minutos?
Nuestro scrum master insiste en que no podemos finalizar la reunión hasta que haya suficientes historias listas para el próximo sprint, pase lo que pase. La mayoría de las historias simplemente no están listas en términos de requisitos.
Su maestro de scrum no está haciendo su trabajo y esta puede ser una discusión que debe tener con ellos (con tacto y en privado) para ver si están dispuestos a cambiar su enfoque.
Las sesiones de planificación de Sprint deben tener un límite de tiempo para evitar exactamente que esto suceda. Nadie debería ser más pedante sobre el tiempo de estas reuniones que el scrum master.
Básicamente, toda la documentación sobre Scrum lo respaldará aquí (por ejemplo: http://www.scrumguides.org/scrum-guide.html#events-planning )
La planificación de Sprint está limitada en el tiempo a un máximo de ocho horas para un Sprint de un mes. Para Sprints más cortos, el evento suele ser más corto. El Scrum Master se asegura de que el evento se lleve a cabo y que los asistentes entiendan su propósito. El Scrum Master le enseña al Equipo Scrum a mantenerse dentro de la caja de tiempo.
Las sesiones duran tanto porque se les permite durar tanto. Calcule el tiempo de la sesión y el equipo pronto aprenderá a ser más productivo/menos detallado debido a la necesidad. Esta es la razón por la que el time-boxing funciona: hace que el tiempo no sea negociable, por lo que otras cosas deben negociarse (p. ej., profundidad de la discusión, definición del proceso de preparación general y listo).
Es posible que necesite un nuevo Scrum Master, porque supervisa al equipo, no es mentor ni desafía. También puede intentar moverlo de la supervisión a la tutoría. Eso sería de gran ayuda para su equipo.
Como arquitecto técnico, asume el papel de tutor técnico y mejora a su equipo para que sea mejor en el desarrollo de software. Puede hacerlo oficialmente pidiendo tiempo a SM, o extraoficialmente dando vueltas, viendo quién necesita ayuda y ayuda: programación en pareja, pequeñas discusiones sobre tecnología y arquitectura, y dar charlas informales.
Las reuniones de planificación suelen ser largas porque
Como arquitecto técnico, puede reducir el primero por educación. Si no hay más discusiones técnicas sobre la reunión de planificación, pueden concentrarse en el dominio y, con el tiempo, terminarán antes.
Desafortunadamente, no hay aceite de serpiente para "preparar, cortar y dimensionar una historia en menos de 10 minutos". Se necesita tiempo, mucho esfuerzo de tutoría, apoyo administrativo, pacientes y un equipo que permanece igual. Suponiendo que estos estén presentes y según mi experiencia, es posible que vea una reducción en el tiempo de la reunión de planificación después de 5 o 6 sprints.
Parece que ha pensado mucho en los problemas y las fuentes potenciales, pero ¿ha considerado reunir a todos y hacer un análisis de causa raíz? Dada su información, supongo que incluso el paso inicial de enmarcar los problemas actuales generará una gran cantidad de conversaciones interesantes y expondrá problemas de alineación en torno a lo que significa ser ágil, si realmente sigue los principios de Scrum, etc.
pensar