La imagen está tomada de este recurso .Su competidor o socio ya ha implementado Scrum y está mostrando buenos resultados y, por supuesto, desea lograr lo mismo. Tengo malas noticias para ti: si se usa incorrectamente, Scrum puede ser dañino.
Aquí, por ejemplo, hay una lista de situaciones identificadas empíricamente en las que Scrum puede interferir con su trabajo.
1. ¿Planea combinar roles de la gestión clásica de proyectos y Scrum?
El equipo Scrum debe incluir 3 roles: propietario del producto, equipo de desarrollo y Scrum-Master. En el marco de la composición propuesta, el equipo permanece "plano", es decir, no tenemos una subordinación directa entre los participantes. Dicho equipo está facultado para tomar independientemente todas las decisiones con respecto al producto que se está desarrollando. Los roles en Scrum describen claramente quién es responsable de qué problemas.
Ahora imagine que está planeando implementar Scrum en un equipo con gestión de proyectos clásica. Luego, el equipo Scrum comienza a trabajar con la participación del Project Manager. ¿Qué pasa en este caso? De hecho, PM simplemente no tiene nada que ocuparse en tal proyecto. Cualquier área de responsabilidad que le transfiramos crea un desequilibrio en el equipo Scrum. ¿Le das un presupuesto a PM? Excelente, es decir, PM no regula el valor y el contenido del producto, pero en caso de problemas, será él quien lo reciba en la cabeza. ¿También le daremos trabajo con el valor del producto? Entonces será posible abolir el propietario del producto. Pero no será Scrum.
Cómo cambian los roles y tareas en un equipo con la llegada de Scrum2. Trabajas con requisitos extremadamente claros
Scrum fue creado para desarrollar productos con un alto nivel de incertidumbre. Funciona bien en los casos en que necesitamos lanzamientos frecuentes para obtener comentarios del mercado. En una situación en la que tenemos requisitos detallados que no dejan espacio para la creatividad, o cuando no necesitamos comentarios de los clientes / usuarios, Scrum solo dedica tiempo al equipo para reuniones que no son de gran valor para el desarrollo de productos.
Cuando todo está claro ya, ¿por qué complicarlo?
3. Trabajas con proyectos de corta duración.
La base de Scrum es un enfoque empírico. Su significado es que recurrimos a la experiencia existente del equipo para poder predecir sus éxitos futuros. Si estamos trabajando en un proyecto que dura 2 meses, simplemente no tendremos tiempo para acumular suficiente experiencia para aplicarlo para mejorar los procesos de trabajo.
4. El equipo no desea cambiar el enfoque del trabajo.
Esta es una de las limitaciones clave en la implementación de Scrum. La implementación de Scrum como guía es casi siempre una mala idea, primero es importante transmitir valores al equipo, "vender la idea". Pero incluso después de eso, no tendrá garantías de que las ideas de Scrum estarán cerca de todos sus participantes. Aquellos que no han aceptado internamente la idea de Scrum y los valores ágiles pueden comenzar a destruir el sistema desde adentro, "sacudir el bote".
Hay varios escenarios posibles. Primero: Scrum no se arraiga en absoluto. Esto puede suceder si la mayoría del equipo está en contra del cambio. O el equipo organizará un motín desde el principio, o hará todo lo posible para que el nuevo enfoque resulte ineficaz.
La segunda opción: uno o más participantes no querrán trabajar en el nuevo sistema. Típicamente, tales situaciones resultan en un participante "problemático" que abandona el equipo por su cuenta.
Cambio Estamos esperando el cambio.
La imagen está tomada de este recurso .5. No está listo para usar todas las prácticas requeridas de Scrum
Para este enfoque, incluso acuñaron el término especial ScrumBut. Esto es cuando trabajamos en Scrum, pero ... No tenemos retrospectivas. Pero tenemos una reunión diaria 2 veces a la semana. Pero abandonamos el papel del maestro Scrum. Y muchos otros "peros" similares.
Scrum Framework proporciona una respuesta simple y clara a todas estas situaciones. Sí, puede agregar prácticas adicionales al proceso Scrum de su equipo (por ejemplo, prácticas de XP). Pero no, no puedes rechazar ningún elemento de Scrum, ya que este no será Scrum.
Todos los roles, eventos y artefactos de Scrum están estrechamente vinculados y tienen como objetivo lograr un objetivo común: suministrar eficientemente a los clientes un producto de máximo valor. El rechazo de cualquier parte de Scrum nos aleja de este objetivo.
6. No está listo para reclutar empleados para trabajar en un producto a tiempo completo
¿Has visto un gráfico de la dependencia del tiempo de trabajo productivo en la cantidad de proyectos en los que estás trabajando simultáneamente? Si no, entonces mira.
Este diagrama en sí mismo es el mejor argumento a favor de involucrar a los empleados en el trabajo en un proyecto a la vez. Pero si ella no lo convence, reste el tiempo restante en un proyecto cuando trabaja con varios otros, el tiempo que se dedicará a las reuniones obligatorias (reuniones diarias, retro, planificación, revisión de sprint). Un miembro del equipo tendrá muy poco tiempo para trabajar en las tareas. Lo necesitas
Hay excepciones a esta regla. Por ejemplo, Scrum-Master puede trabajar con varios equipos a la vez. Pero para otros participantes es necesario garantizar la máxima participación solo en este proyecto.
7. No tienes soporte administrativo
Así como queremos que los empleados adopten un nuevo enfoque para trabajar, también necesitamos el apoyo de la gerencia. Es importante entender que la introducción de Scrum, especialmente en
Las primeras etapas pueden requerir cierta inversión. Por ejemplo, contratar un entrenador ágil o un Scrum Master profesional, capacitar al propietario del producto, realizar capacitación de Scrum para empleados y mucho más. El líder debe estar listo para apoyar financieramente la nueva empresa.
Pero esto no es lo más importante. Es mucho más importante que la administración de la empresa comparta los valores de Scrum y esté lista para cambiar la cultura de la empresa. Por ejemplo, un líder debe estar preparado para el hecho de que tendrá que dar nuevos poderes como parte de los nuevos roles en el equipo. No todos están preparados para esto, por lo que también puede ser necesario "vender una idea" a este nivel.
Esta lista de criterios no pretende ser exhaustiva; puede complementarla usted mismo o compartir sus casos en los comentarios.