¿Cómo hacer que la gente se sume a Scrum/agile?

Lo siguiente se basa en la suposición de que trabaja en un entorno complejo y adaptativo donde se desconoce más de lo que se sabe en lo que respecta al valor que crea su trabajo:

Hay libros y libros sobre este tipo de cosas, y empresas que ganan millones consultando sobre la habilitación ágil, pero realmente se reduce a cuán dispuestas están las personas a adoptar los valores de Scrum . Por personas me refiero tanto a los miembros del equipo como a las partes interesadas a cargo de empoderar a un equipo multifuncional y autoorganizado.

Al final del día, todos deben entender que Scrum es simplemente un marco que descubre sus problemas; no te los resuelve. El lado positivo es que Scrum le brinda a su equipo la oportunidad de sentirse capacitado para abordar esos problemas y crear soluciones que brinden valor de manera incremental e iterativa. Si bien Scrum crea oportunidades para hacer esto, el equipo debe incorporar los valores para que funcione. Todo comienza con los valores y el empoderamiento para autogestionar el trabajo que realizan.

En mi experiencia, una vez que un equipo está capacitado para administrar su propio trabajo, los frutos de Scrum realmente comienzan a ser evidentes. Es difícil de vender, principalmente porque cambia la forma en que se realiza el trabajo, pero hay estudios de casos que muestran los beneficios. Recomiendo encontrar algunos de ellos y trabajar con su equipo para comprender que su situación no es única y puede transformarse utilizando el marco Scrum.

EDITAR: también puede beneficiar a su equipo realizar una capacitación formal con un entrenador certificado. Los mejores resultados si todos están capacitados al mismo tiempo para que puedan discutir los nuevos conocimientos, su comprensión del marco y cómo su función encaja en el panorama más amplio.

¡Bienvenidos!

Otro problema que tengo es que, ¿podríamos incluso ejecutar ágilmente como equipo debido al hecho de que tenemos poco tiempo para concentrarnos en el desarrollo? Tenemos tantas tareas operativas que tenemos tantas tareas transferidas al próximo Sprint que a menudo me pregunto si solo estamos perdiendo el tiempo.

Quizás es por eso que el equipo de administración sugirió que su gerente quisiera que "incluyera todo lo que hacemos, ya sea que se trate de desarrollo o no". Me parece que fue una recomendación adecuada. ¿Cuál fue la base para la decisión de su equipo de limitarlo solo a tareas de desarrollo?

Entonces, mi problema principal es que somos un equipo que realiza una gran cantidad de funciones operativas en nuestro día.

Puede encontrar que Kanban es una mejor opción para su situación que Scrum. Se enfoca en un flujo constante de trabajo, con límites WIP en las distintas etapas, en lugar de centrarse en los sprints como lo hace Scrum.

los que no son desarrolladores realmente no quieren participar en el proceso ágil... ¿Cómo hago para que personas que están tan en contra del proceso participen?

La respuesta a eso depende de por qué están en contra del proceso.

Creo que si esto ha estado sucediendo durante 4 meses (¿y ha sido tan malo desde el principio? ¿O hubo inicialmente más participación de los que no son desarrolladores?), entonces es hora de detenerse y repensar, en lugar de seguir haciendo lo mismo. lo mismo que no funciona.

Parece que todos podrían beneficiarse de la capacitación y/o el asesoramiento, no solo sobre cómo (¡y por qué!) "hacer" ágil/scrum, sino también sobre cómo "ser" ágil y trabajar juntos como un equipo... o posiblemente como dos equipos, ya que el tamaño recomendado para un equipo es de 5-7 personas.

¡Buena suerte!

Dado que el equipo de desarrollo está a bordo , le sugiero que haga que el equipo de desarrollo se centre exclusivamente en Scrum/Agile.

Todo lo que entra y sale de Dev pasa por Scrum.

• ¿Quieres saber cuándo estará listo algo? Ven al Daily Standup. O mira el tablero Kanban.
• ¿Quiere saber si su mascota-peeve/error será tratado? Ven a la reunión semanal de trabajo pendiente.

Asegúrese de invitar a todos a la reunión diaria, pero comience a tiempo, siempre, sin esperar a nadie. ¿Por qué castigar a los que llegan a tiempo? Sin llamar, empujar o esperar.

Y asegúrese de que su tablero, tareas e información estén actualizados de antemano, y que todos sus accesorios estén disponibles; esperar a que el Scrum Master encuentre un marcador mágico o una nota adhesiva es una excelente manera de autodestruirse.

No molestes a la gente para que venga; simplemente pregúnteles por qué no están al tanto de sus tareas:

Ellos: ¿Qué tarea?
Tú: ¿No viste tu columna/carril en el tablero Kanban?
Ellos: Oh, no entiendo esas cosas; Dáme un respiro.
Tú: Bueno, Dev ahora se está ejecutando en Agile; si quieres interactuar con ellos, será mejor que te pongas al día. ¿Quieres que te haga un recorrido de 10 minutos sobre cómo funciona?

Solíamos filmar el standup diario (poner la cámara en un trípode, para que nadie se distraiga mientras graba). Las personas que estaban fuera del sitio, tarde o tarde podían revisarlo.

Enviar un enlace a un video también sirve como recordatorio y resumen.