* Scrum (sustantivo) es un marco que ayuda a resolver tareas que cambian durante el proceso de trabajo para entregar productos de manera productiva y creativa a los clientes con el mayor valor posible.
¿Por qué decidí escribir este artículo?
Muy a menudo en un entorno de trabajo, en Internet y en entrevistas, puede escuchar, por ejemplo, esto:
“¡Hay tantas reuniones con este Scrum! ¿Cuándo trabajar entonces?
"Bueno, que sea al menos Scrum, al menos Vergüenza, ¡simplemente déjalo y déjame escribir el código!";
"También impusimos este Scrum, en general no está claro por qué";
“Todos los días, de pie durante unos cuarenta minutos, ¿para qué tengo que asistir? Quiere saber qué he hecho y en qué estoy trabajando ahora: vea Jira, Confluence, Git, etc. "
"El maestro Scrum es generalmente un bufón, ¡tendría que ir a bailar en lugar de administrar el proyecto!";
"Sí, utilizamos Scrum: lo principal es que realizamos retrospectivas".
El propósito de este artículo es mostrar que la negatividad, que todavía se está vertiendo en una gran corriente hacia Scrum, en realidad no se aplica a ella, y el problema debe buscarse en otro lugar.
A continuación, me gustaría hablar sobre casos típicos en los que se originan estos problemas.
Yo mismo soy un empleado de Scrum certificado (scrum.org) de una gran organización del sector financiero (no "verde" si eso es así). En la actualidad, no tenemos Scrum, pero nos estamos moviendo en esta dirección, y personalmente tengo una visión de por qué y cómo continuaremos haciéndolo.
De hecho, la fascinación por las metodologías flexibles y por Scrum en particular me llegó no hace mucho tiempo, pero en mi opinión, es importante no "hace cuánto tiempo", sino "cuán cualitativa y conscientemente".
Y cuanto más te sumerges en este tema, más te das cuenta de que este marco es una "herramienta" poderosa, y más triste cada vez que te encuentras con frases y reseñas al comienzo del artículo, que, como regla, son evidencia de torpes intentos de cambiar a Scrum.
Por qué intentos, e incluso torpes: porque no se dieron cuenta de por qué todo este Scrum y Agile, en principio, se detuvieron un poco antes que al comienzo de la transición.
Las empresas que entienden por qué se necesita Scrum y cómo usarlo, en mi opinión, no es tan frecuente en nuestro país.
El poder de Scrum, invisible para muchos, se puede comparar hasta cierto punto con el poder de Excel: todo parece bastante simple, pero si cavas ...
Sin embargo, no considero a Scrum una bala de plata, al igual que sus creadores (no proporcionaré un enlace a un artículo publicado recientemente en una publicación autorizada), y este ya es un tema para un artículo separado.
1. "Impuesto"
En mi opinión, una de las razones principales por las que Scrum provoca tal aversión es cuando simplemente fue "bajado desde arriba" durante la transformación de la organización. Y el problema aquí es exactamente cómo fue la transformación:
- ¿Se dio cuenta la gerencia de por qué iba a utilizar metodologías flexibles y Scrum en particular?
- ¿Cómo informaron a los empleados sobre la necesidad de transformación, y por qué las metodologías flexibles y Scrum en particular ayudarán en esto?
- ¿Cómo apoyó a los empleados en las condiciones de transformación, proporcionó capacitación, certificación y asistencia de calidad en el lanzamiento de equipos?
Una historia muy común es cuando las empresas se transforman, simplemente porque está "de moda".
Al final, es poco probable que ocurra algo bueno, y el murmullo resultante, posteriormente fluye en una ola de negatividad.
En este sentido, me gustó una frase en el tema: "En las empresas tradicionales, los gerentes tradicionales organizan las transformaciones tradicionales".
Sin embargo, seré sincero con usted: cuando obtuvimos Agile / Scrum / Kanban por primera vez, fue sobre Scrum lo que inicialmente pensé que era una especie de basura con reuniones interminables. Los cambios en mi actitud hacia él se produjeron después de que me hice la pregunta: "¿Qué pasaría si ...?" A mí mismo en un proyecto muy bueno.
2. Adivinación por Scrum
Otra razón para la indignación e incluso cierta amargura en Scrum es su interpretación incorrecta, que se asocia principalmente con el lugar donde obtenemos conocimiento de ella. Como resultado, por ejemplo, tenemos "ceremonias del té" o "rituales de sacrificio" en lugar de "eventos".
Tampoco excluyo la presencia de cismáticos que discuten sobre pararse en el Daily Scrum con un círculo, un cuadrado o alguna otra figura. Si es redondo, pase la palabra en el sentido de las agujas del reloj, en contra o de alguna otra manera.
Al mismo tiempo, existe una completa falta de comprensión de por qué estas reuniones (eventos) obligatorios notorios existen en Scrum, que, por cierto, se pueden contar con los dedos de una mano.
Al observar el enorme flujo de información en la red, parece que muchos simplemente no saben cuál es la fuente principal y dónde obtener el conocimiento básico del marco.
Por lo tanto, el documento principal de Scrum es The Scrum Guide, coescrito por Ken Schwaber y Jeff Sutherland, disponible en muchos idiomas, incluido el ruso.
En mi opinión, para obtener un conocimiento básico de Scrum y, posteriormente, no obstruir su mente con todo tipo de adiciones mal entendidas a Scrum, solo necesita dos componentes principales: deseo y lectura reflexiva de la Guía Scrum, y más de una vez. Este documento es bastante compacto: puede dominar menos de veinte páginas.
En cuanto a los entrenamientos, diré brevemente: ¡ten cuidado! No anunciaré a nadie en el marco de este artículo, pero creo que en nuestro país solo se puede confiar en una o dos compañías con los "entrenamientos correctos" sobre este tema.
3. "Interpretación" de algunas secciones de la Guía Scrum y no solo
En el contexto de la cantidad de discusiones similares en la red sobre Scrum, intentaré llamar la atención sobre ellas y expresar mi comprensión de acuerdo con la guía y experiencia de Scrum.
Scrum es ...
Destacaré dos de las tres características:
simple para la comprensión y
difícil para el dominio perfecto .
Algunas personas piensan que hay una contradicción.
Sprint
En esta subsección, deliberadamente plantearé algunas preguntas que pueden hacerle pensar y repensar su enfoque del marco.
- ¿Qué crees que tiene sentido llamar a Sprints fijos en intervalos de tiempo? Por ejemplo, ¿puede ser más fácil enviar un informe de progreso cada dos semanas?
- Si está en el proceso de cambiar a Scrum, ¿por cuánto tiempo ha elegido Sprint? Cuando hice esta pregunta, a menudo me encontré con una mirada de asombro y luego la respuesta: "Estándar - 2 semanas".
- ¿Por qué elegiste un sprint de tal longitud?
- ¿Por qué no se recomienda establecer la longitud del sprint durante más de un mes?
Algunos pueden no creerlo, pero las respuestas a estas preguntas se encuentran en la Guía Scrum.
4. Scrum diario
Uno de los temas más controvertidos es el Daily Scrum, también conocido como Daily Standup Meeting, también conocido como Daily Scrum, o simplemente "Stand-up".
Puede que no me creas, pero este evento tiene un tiempo fijo (cuadro de tiempo): no más de 15 minutos, independientemente de la duración del Sprint.
El equipo mismo determina el formato de la reunión. Y lo más importante en este período de quince minutos es comprender el estado del progreso hacia la Meta Sprint.
Ahora preguntas para rellenar: ¿cuántos de ustedes saben cuál es el Objetivo Sprint? ¿Cuántos de ustedes saben cómo formularlo? ¿Y quién los formula en absoluto?
En la gran mayoría de los casos, Scrum está indignado precisamente por su ignorancia y malentendido, para este evento llamado Daily Scrum es necesario.
¡Esta no es una reunión informativa! En esas reuniones que veo a menudo, no hay suficiente información, excepto sobre cuántas veces una persona bebió café, té, agua y también fue al baño. Y "no más de 15 minutos" puede estirarse durante una hora y media.
Una vez más: ¡Daily Scrum se trata de avanzar hacia los Objetivos Sprint!
Al darse cuenta de que solo esta parte de Scrum, usted, en mi opinión, podrá lograr un avance significativo.
Y otra observación, que para muchos se convierte en una revelación, Daily Scrum es un evento en el que puede participar (nota, "participar" y "esperar, escuchar" son dos cosas diferentes) ¡solo el Equipo de Desarrollo! ¡Incluso Scrum Master (Scrum master) y Product Owner (Product Owner), si no son miembros a tiempo parcial del Equipo de Desarrollo, no participan directamente en esta reunión!
5. Scrum Master no es un Project Manager ni un servidor
Otro tema muy común: Scrum Master (SM) = Project Manager (PM).
Puedes encontrar un montón de artículos sobre SM vs. PM
Destacaré lo principal:
- El Scrum Master es responsable de promover y apoyar a Scrum de acuerdo con la Guía Scrum.
- Los principales conceptos erróneos sobre el Scrum-master:
- Scrum master NO gestiona el proyecto;
- Scrum master NO gestiona el equipo (a quién llevar, a quién eliminar);
- Los scrum-masters no se seleccionan en función del empleado más experimentado o a largo plazo de la empresa;
- Scrum-master NO es un secretario del equipo, "obstruyendo lo que se avecina".
- Las tareas del Scrum Master NO incluyen la entrega de pizza los viernes (un tema favorito en los entrenamientos), lavar los calcetines y planchar los cordones del propietario del producto o los miembros del equipo de desarrollo.
Las áreas de responsabilidad del Scrum Master también se describen en la Guía Scrum.
Al final de esta sección, puedo lanzar algunos temas más, para estudio independiente, si alguien está interesado:
- Scrum como un culto de carga vs. Scrum y shuhari.
- El propietario del producto es un gerente de producto, no un proyecto o equipo. Aquí está el PO vs. PM
- Propietario del producto y Scrum Master en un solo paquete.
- Lo principal en Scrum es una retrospectiva, o te has encontrado casi así: Scrum = retrospectiva (¡pero una retrospectiva de lo que es otra pregunta)!
- ...
Está maduro a la luz de lo que se encuentra en el trabajo, en los comentarios, incluso en Habré.
Scrum es Ken Schwaber, Jeff Sutherland y su Scrum Guide. Ver nota final.
Scrum: esto es lo que está en la Guía de Scrum, y no lo que está acostumbrado a llamar en su empresa.
Tampoco tenemos todavía Scrum, pero entendemos esto, lo reconocemos y sabemos cómo avanzar hacia él. Además, también entendemos que es absolutamente necesario mudarse allí, ya que esto realmente puede aportar grandes beneficios a la organización.
Para resumir
Si las notas anteriores, al menos hice que alguien pensara y reconsiderara lo que es este Scrum, y las metodologías flexibles en general, ¡entonces asumiré que he logrado el objetivo!
El agua desgasta la piedra y, tal vez, en el futuro cercano no escucharemos con tanta frecuencia como ahora escucharemos: "Usted se deja llevar por este Scrum, y según los resultados de tal o cual equipo (de hecho usando ScramNO) no vale la pena".
¡Gracias a todos por su atención y estaré encantado de sus comentarios y comentarios!
Referencias
www.scrumguides.org/index.html