Get best of the week

¿Cuál es el significado oculto de los autores en la Guía SCRUM? Parte 1. Sobre el proceso

Hablar de magia y unicornios SCRUM-a?

imagen

No es ningún secreto que muchos trataron de implementar SCRUM en sus hogares, pero no todos tienen éxito, y muchos no entienden de dónde puede venir la magia.

Inmediatamente de acuerdo, el único manual para SCRUM es Scrum Guides , cambia y se actualiza, por lo tanto, le aconsejo que lo vuelva a leer regularmente.

Esta serie de artículos no reemplazará la lectura del manual, pero será una adición a la guía con algunas adiciones personales del autor.

Y probablemente comenzaremos con lo que está escrito en la última página del manual:

los roles, eventos, artefactos y reglas de Scrum son inmutables y, aunque es posible implementar solo partes de Scrum, el resultado no es Scrum.

(Los roles, eventos, artefactos y reglas de Scrum no cambian . Y aunque la introducción de solo partes de Scrum es posible, el resultado no será Scrum).

¿Qué me dice esto, que ya tiene un callo en la frente por el rastrillo que estábamos atacando, después de 4 transformaciones en la empresa?

Acerca de eso: si queremos obtener gasolina A95, entonces probablemente debamos cumplir estrictamente con los estándares de producción, calentar el aceite en la columna de ratificación a una temperatura estrictamente definida, tomar los vapores a cierta altura, agregar componentes no "a simple vista", pero observar el último punto ¡su madre! proceso tecnológico. Para que el resultado final sea A95, y no algún tipo de peso corporal que arruine su automóvil.

¿Pero por qué? Por qué, un gerente típico (clásico), que de repente decidió implementar SCRUM en casa, cree que el "proceso tecnológico" no está en su empresa. Su gente es diferente, sus manos son diferentes o sus piernas, ¿el código está escrito en el lugar equivocado? Y en general, parece que no me importan los 30 años de evolución de los enfoques gerenciales. Hay un millón de razones para inventar su bicicleta por primera vez en un millón, y luego escribir con orgullo sobre ella en un centro, o incluso escribir un libro sobre su "scrum negro" . Al popularizar que la "bodygirl", a través del dolor y las lágrimas de los desarrolladores, destruyó el proceso clásico establecido con el que la compañía había vivido durante varias décadas antes, y como resultado, no funcionó.

// SCRUM es - simple de entender


Entonces a eso me refiero. Lo que podría ser más simple que SCRUM: planifique, pase cinco minutos por la mañana y, después de 2 semanas, reúna a todos y deje que muestren el resultado (por lo general, ya no es necesario), y espere el producto, ¡que trae dinero, alegría y orgullo para todos! ¿Simplemente? ¡Implementemos, digamos gerentes!

Este "gancho" generalmente se presenta joven y no experimentado, porque los experimentados (lectores) ya saben que no es tan simple.

// SCRUM es difícil de dominar


¿Sabes lo que Jeff y Ken escondieron en estas 19 páginas de la guía? Una verdad simple es que cuanto más se "preocupa" un gerente / gerente / supervisor por su equipo, peor será el equipo con autoorganización, peor será el resultado de su trabajo.

Todos saben que el administrador malo (con el cual el equipo se está degradando) es:

  • no puede delegar
  • distribuye el trabajo él mismo, acepta el resultado
  • monitores diarios
  • Requiere informes constantes, documentación, cumplimentación de plazos (horarios de asistencia)
  • no confía en el equipo
  • impone sus decisiones

(Espero que nadie se reconozca aquí).

Esta es la misma "hiper preocupación", o es el sentimiento de "anciano", "padre", "más responsable", "Solo lo necesito".

Con un comando, esto necesariamente hace mala magia:

  • El equipo pierde la capacidad de pensar. (Tu manager deja de filosofar aquí, pero solo dime qué hacer)
  • el equipo trabaja en tareas, no en el resultado, a veces "simulando" estar activo. (Hacemos la tarea 1, la tarea 2, la tarea 3, y el producto se ha caído, que los administradores / desarrolladores entiendan).
  • el equipo está ocupado informando, documentando, pero no trabajando. (Escribo informes medio día los lunes y viernes, no hago tareas).
  • El equipo se resiste a cualquier innovación. (¿Qué son las pruebas automáticas? Hagamos la tarea).

No es extraño, pero SCRUM simplemente "limita" al equipo de tal "hipercontrol" por parte del "padre principal".

¿Necesitas pruebas? Guárdelo todo de acuerdo con la Guía Scrum:

Standup, solo para el equipo de desarrollo!


Todos los maestros de Scrum saben que tan pronto como llega el "gerente", incluso el propietario del producto "nuestro amigo", el stand-up se convierte instantáneamente en un "informe de estado". El equipo ya no discutirá qué hacer con él para lograr los objetivos del sprint, pero de repente comienzan a "bailar delante del anciano" para contar lo que hice y lo bien que estoy en todos los detalles. Y créanme, esto lleva inmediatamente más de 15 minutos, y lo más triste es que es una pérdida de tiempo absolutamente inútil para todos los miembros del equipo.

En la guía, no está escrito para nada:
el Daily Scrum es una reunión interna para el Equipo de Desarrollo. Si hay otros presentes, el Scrum Master se asegura de que no interrumpan la reunión

(Daily Scrum es una reunión interna del Equipo de Desarrollo. Si hay
hay alguien más, el maestro Scrum se asegura de que no interfieran con la reunión)

Pero los ex gerentes, que generalmente se convierten en Propietarios del producto en el nuevo proceso, lo odian cuando no se les invita a participar. Y lo primero que se descompone en el proceso tecnológico SCRUM es que todos los expertos lo visitan, porque "el control está por encima de todo".

En las reuniones con el propietario del producto, el equipo no tiene más del 10% del tiempo y no más de un minuto.


(Me refiero a aquellos en los que PO está presente, el equipo siempre puede recurrir a PO si lo necesitan)

Porque durante un sprint de 2 semanas, estas son 3 reuniones estrictamente reguladas:

  • 4 horas máximo en cepillado Sprint
  • máximo 2 en la revisión de Sprint
  • y 1.5 horas de Sprint retro

Y todo, en 2 semanas, el Propietario del producto, de acuerdo con las regulaciones, tiene solo 7.5 horas, en las cuales no hay absolutamente ningún tiempo para el "control". El 90% restante del tiempo el equipo trabaja con el objetivo de correr. (¿Pero consideró cuánto puede codificar realmente su equipo?)

En realidad, por supuesto, nuestro antiguo "gerente" no tolerará esto, y romperá este "desastre" con un par de informes intermedios y manifestaciones .

El equipo debe implementar las necesidades del cliente, no los objetivos personales del propietario del producto.


Porque en ninguna parte está escrito que el Dueño del Producto debe escribir los requisitos para el producto en sí, pero está escrito qué priorizar y hacerlos comprensibles para todos.

Un buen maestro de Scrum sabe que para garantizar la "transparencia", es imprescindible invitar a clientes de User Story cuya prioridad es reunirse con el equipo. Establecer comunicación directa con el cliente. Porque dada la promesa al cliente, oh, cuánto motivan al equipo.

3 principios de SCRUM: Transparencia, Investigación, Adaptación

¿Pero qué "gerente" sensato permitirá? Resulta que la "verdad administrativa" del ego está siendo cuestionada, esta es la oportunidad del equipo de "negociar" y romper todos los planes para el crecimiento profesional y la captura del universo.

No, SCRUM es un sueño terrible para un gerente clásico, y la gente solía vivir en "procesos".

Por lo tanto, generalmente intentan romper todo este proceso SCRUM, agregar más control, menos transparencia y sin adaptación, desarrollo.

Como resumen: la mejor manera de enterrar a SCRUM es nombrar al propietario del producto, proyectos anteriores o sus propios gerentes.

  • PO, no un líder.
  • PO debe ser una persona con habilidades únicas: para ver el apilador donde otros no lo ven.
  • PO debe entender dónde más y menos dinero / valores y priorizar.
  • PO debe poder llevar el apilador al equipo, donde el equipo mismo ya venderá su producto.

y además
— ? , Scrum , , .

Deja que las buenas personas lean buenos artículos :)

More articles:


All Articles