He trabajado con / in / for agile en el campo del desarrollo web durante más de 10 años. La mayoría de ellos tuvo que lidiar con el marco ágil más popular: scrum ( según VersionOne ). Quiero compartir con ustedes las observaciones y conclusiones acumuladas.
Comenzaré con una metáfora, ya que a veces tuve que ver la introducción de scrum en este escenario:
- Antes del scrum : "desarrollo" como un bebé: tiene un propósito, pero no sabe cómo caminar normalmente, pero realmente quiere aprender para llegar a la meta.
- Introducción : viene un maestro ( entrenamientos scrum, cursos, entrenador ágil, etc. ) y muestra cómo caminar. ¡El niño está feliz, se mueve en pasos! Top-top-top. Tenemos sprints, ¡vamos!
- Después de la introducción : las partes interesadas de los pacientes dicen: "Está bien, nos dirigimos a la meta", a lo que reciben "¡no empujen al equipo, vamos!". El desarrollo escribe trayectorias interesantes y disfruta el proceso, pero el objetivo se olvida.
- Scrum-no : fomenta la píldora de la verdad del negocio, scrum "muta" y permite que el negocio obtenga algún tipo de producto del desarrollo. Y, desafortunadamente, la marca de verificación "trabajamos en scrum" está marcada formalmente, pero el potencial real del equipo de desarrollo aún no se ha revelado, y dicen que "scrum no es real".
En mi opinión, esto sucede debido al hecho de que scrum a menudo se implementa "mecánicamente", sin darse cuenta de la esencia del marco y sus elementos. Me gustaría tratar de revelar los síntomas del "scrum mecánico"; entender cuáles son las desventajas de este enfoque; entender qué podría ser mejor con "scrum real con agile"; y encontrar maneras de ayudar a combatir los síntomas del scrum. Dedicaré aquí un par de artículos a esto y me complacerá sus comentarios y preguntas.
Para empezar, definamos qué es un "scrum mecánico". Desde mi punto de vista, esto es cuando todos los roles, eventos y artefactos de scrum están formalmente presentes, pero los valores y las metas se olvidan; cuando no existe una cultura ágil ( es decir, un alto grado de conciencia y aceptación del manifiesto y los principios ágiles ). Cuando no hay comprensión o incluso un intento de averiguar por qué se necesita este o aquel artefacto, o cuál es el propósito de los eventos en scrum. Es como un robot en un video que sabe cómo dar saltos mortales, pero ¿quién lo llamará gimnasta? Al implementar scrum, es importante transmitir al equipo sus objetivos y valores, y no solo la mecánica. La cultura ágil fortalece el scrum y lo hace "real". Scrum es útil para entregar valor regularmente y recibir comentarios rápidos. Scrum se trata de velocidad y desarrollo de productos. ¿Suena trillado en teoría? Tratemos de descubrir cómo trabajar en scrum y no perder la cultura y los valores de scile en el camino.
Al analizar elementos scrum en ScrumGuide, los roles son uno de los primeros en analizarse , haremos lo mismo. Porque resultó una gran cantidad de material, entonces, para dar la oportunidad de realizarlo, se divide en tres partes ( Parte 2 , Parte 3 ). Comencemos el análisis con Product Owner.
Propietario del producto - Propietario del producto (PO):
El propietario del producto es la persona responsable del producto, él "posee" la cartera de pedidos del producto. La herramienta principal de PO es la visión del desarrollo del producto, y la tarea principal es maximizar el valor del producto producido por el equipo. Todo parece ser simple: "Si eres valiente, hábil y hábil ...", pero hay matices. No nos enseñan en PO, pero enseñan en PM (gerente de proyecto) y, a menudo, PM se convierten en PO, creyendo que esto es solo un cambio de nombre, y puede mantener los viejos enfoques de trabajo. Pero ágil no funciona así. Como es necesario
Interacción entre PO y producto, Backlog
Síntoma : PO no es responsable de la composición del trabajo atrasado, solo funciona en historias recibidas de otros participantes en el proceso. O PO no es responsable de priorizar los elementos acumulados. Su trabajo es llevar la cartera de pedidos al estándar aceptado por el equipo, y no determina el contenido y las prioridades de lo que hará el equipo.
Lo malo: Si el PO no tiene el valor o la capacidad de crear el producto (para formar un retraso de, priorizar, realizar experimentos, etc.), este no es el PO, y cualquier otro tipo de actividad. Y sin PO scrum, no scrum. Sin formar un Backlog, PO no puede ser responsable del producto. Si no es el PO responsable del trabajo atrasado, entonces la adopción de decisiones sobre el producto requiere comunicaciones adicionales: este es un tiempo adicional que afecta negativamente la velocidad del equipo.
Cómo tratar : debe otorgar a PO el derecho exclusivo de tomar decisiones sobre el producto y la responsabilidad de la composición de la cartera de pedidos. Si una persona que no toma decisiones es un orden establecido, entonces es difícil cambiar la situación de la noche a la mañana. Cuando PO es un proxy, entonces
- O lo eliminamos de la ecuación y hacemos que la OP sea realmente la responsable de la composición y priorización del trabajo atrasado. Tanto el equipo de desarrollo como el Equipo especial de descubrimiento de productos pueden ayudar a las OP a trabajar en la cartera de pedidos, pero la responsabilidad de la composición y la calidad de la cartera de trabajos debe permanecer con una sola persona: la OP.
- O gradualmente aprendemos / permitimos / obligamos a asumir la responsabilidad y tomar decisiones (la composición de los elementos atrasados, la prioridad de los elementos, etc. ) del PO actual. Las iteraciones son importantes: consolidar el éxito, obtener retroalimentación.
Síntoma : PO no tiene una visión para el desarrollo de productos, no tiene una estrategia global, no hay un objetivo donde llevar el producto y por qué.
Lo que es malo : la principal fortaleza de PO es la visión del producto, entendiendo por qué y para quién está creado. Con esta visión, puede motivar e "infectar" a las personas que lo rodean. Si no hay visión, es poco probable que el producto resulte necesario y bueno. El equipo no será "acusado" con el resultado.
Cómo tratar : PO es importante formular primero una visión del producto. Debe poder decir en formato de tono de ascensor qué tipo de cosa genial hace, para qué y para quién. Uno de los valores ágiles es la transparencia. Al visualizar diversos artefactos de desarrollo de productos, estamos trabajando en la transparencia. PO puede articular su visión y publicarla frente al equipo. Es mejor si el trabajo en la formulación del tono y la visión del elevador se realiza con cierta frecuencia, como otros eventos de scrum ( planeó una nueva iteración - hecho - retroalimentación recopilada ).
Síntoma : PO no resuelve los elementos de la cartera de pedidos, no los lleva a los acuerdos adoptados por el equipo, no actualiza los elementos de la cartera de pedidos, no lo limpia, no realiza la acumulación de la cartera de pedidos .
Lo malo: Si el PO no se paga actualmente acumulación suficiente atención sobre una base regular, todavía tendrá que hacerlo (sprints también ser recogidos), pero será más una costosa estresante, (por ejemplo: el restablecimiento del orden colectiva de cartera a la planificación del sprint). La sobrecarga de comunicación se compensará con el tiempo asignado para el desarrollo. PO comenzará a perder la confianza del equipo: no invierte en la cartera de pedidos; el equipo no invertirá en el incremento. La acumulación de pedidos mala / irrelevante reduce la transparencia para todas las partes interesadas. Y scrum sin transparencia no es scrum.
Cómo tratar : antes de la orden de compra, debe transmitir la importancia de trabajar en la cartera de pedidos: artículos, libros, capacitaciones, etc. Necesitamos desarrollar reglas / regulaciones para llevar a cabo el Refinamiento del Backlog del Producto (PBR) para que estas reuniones sean útiles y efectivas, llevando a cabo una mini-retrospectiva después del PBR, en unas pocas iteraciones puede mejorar cualitativamente este evento. El equipo necesita mejorar el mecanismo para llevar a cabo PBR, logrando la máxima sinergia entre la OP y el equipo de desarrollo. El trabajo atrasado necesita una limpieza regular. Al obtener la información más reciente, además de agregar nuevas historias a la cartera de pedidos, debe recordar limpiar las historias que han perdido relevancia. El trabajo atrasado debe contener elementos que sean comprensibles para el equipo y elaborados ( dentro del marco de los acuerdos de un equipo específico ) para 2-3 sprints; un trabajo atrasado más profundo puede perder relevancia. En general, la cartera de pedidos debe contener la Hoja de ruta durante al menos un año, para que todas las partes interesadas sientan que el producto tiene futuro. Mantener un trabajo atrasado roto por incrementos aproximados ayudará al equipo a pensar de antemano sobre los objetivos del sprint .
Síntoma : PO funciona en varios productos no relacionados o con varios equipos. Como opción, además del PO principal, también juega un papel diferente en el proceso de scrum (ya sea desarrollador o SM).
Lo que es malo : ser un PO no es un trabajo fácil, requiere grandes ganancias. Si el papel de la OP se combina con otras actividades, con un alto grado de probabilidad, esto afectará gravemente la calidad del resultado. Los OP experimentados y maduros pueden ejecutar simultáneamente varios productos y trabajar con varios equipos si estos productos están "relacionados" o son partes de un producto grande que tienen una funcionalidad cercana. Lo más probable es que solo personas muy, muy únicas puedan hacer simultáneamente, por ejemplo, un editor gráfico para dispositivos móviles y un simulador de vuelo del ejército. Para ser efectivo, debes concentrarte en un objetivo antes de hacer malabarismos con varios.
Cómo tratar : PO debe analizar críticamente sus productos: ¿qué tan bien desarrollada y formulada visión? ¿Cómo entienden y aceptan los equipos esta visión? ¿Qué tan bien desarrollado está el trabajo atrasado? ¿Es transparente para todos los interesados? ¿Existe una hoja de ruta del producto, está claro para todos? ¿Entiende el equipo lo que harán los próximos 2-3 sprints? ¿Qué tan conocido es el usuario y el mercado? ¿Cuál es la calidad de la interacción con el equipo de desarrollo? Si en algunos de estos problemas hay margen para mejorar la calidad, debe dejarse un producto y concentrarse en él.
PO e interacción del equipo
Síntoma : la directiva PO controla al equipo, trabajando realmente en el esquema clásico de MP. PO toma todas las decisiones, incluso las más pequeñas, el equipo recurre a él en cualquier asunto.
Lo que es malo : si PO está involucrado en una microgestión dentro del equipo, participa activamente en el desarrollo, entonces, por un lado, desmotiva al equipo y evita que se desarrolle ( no existe una autoorganización, porque la responsabilidad de las decisiones locales sigue siendo del PO ), por otro lado, es malo para el producto, porque los esfuerzos de PO se dirigen dentro del proceso, y el producto puede quedar sin su atención.
Cómo tratar : PO necesita matar a PM en usted, probar enfoques de gestión no directiva y dejar de percibir a las personas como un recurso. Si se construye un esquema de gestión directiva entre la OP y el equipo de desarrollo, vale la pena involucrar a un facilitador externo o interno que pueda ajustar la interacción. Los límites de responsabilidad entre la OP y el equipo de desarrollo deben definirse claramente: esto es transparencia. Debe haber una relación de confianza entre el OP y el equipo: el equipo en su mayor parte confía en el PO y sus soluciones de producto, y el PO confía en el equipo y las decisiones que el equipo toma para implementar los elementos de la cartera de pedidos. Todos comprenden que el trabajo se realiza con un solo propósito. Una de las herramientas posibles para PO puede ser su equipo de "producto", que incluye analistas. Cuando las hipótesis se basan en números y datos, son más creíbles. Lo principal para PO es no olvidar compartir estos datos con el equipo de desarrollo. Si el equipo no es independiente, la OP debe aprender a delegar. Luego, el equipo se verá obligado a tomar decisiones, como resultado de la responsabilidad, y gradualmente se convertirá en un equipo scrum.
Síntoma: PO y el equipo de desarrollo regularmente en conflicto, hay una confrontación constante, no hay comprensión.
Lo que es malo : PO y la tripulación navegan en el mismo bote, si no se establecen comunicaciones efectivas entre ellos, es poco probable que dicho bote pueda navegar lejos. Se gastará mucha energía en establecer interacción, y no en el desarrollo de productos. El objetivo de la OP y el equipo es el mismo, lo que significa que no debe haber conflictos regulares.
Cómo tratar : necesitamos un facilitador experimentado que pueda identificar la esencia del conflicto, eliminarlo y construir una relación de trabajo. Si todos los esfuerzos no conducen a un entendimiento mutuo, entonces quizás valga la pena cambiar los tándems.
Síntoma : PO casi no se comunica con el equipo. Por ejemplo, está disponible solo como parte de reuniones obligatorias (planificación, revisión de sprint).
Lo que es malo : el equipo crea un nuevo producto complejo ( Scrum es un marco para desarrollar, entregar y mantener productos complejos ) . Por lo tanto, funciona en condiciones de gran incertidumbre. Para entregar el máximo valor, necesitan información que en la mayoría de los casos solo PO tiene ( es su trabajo ). En ausencia de información, se pueden hacer suposiciones y decisiones incorrectas, como resultado, se perderá un tiempo valioso en su corrección.
Cómo decidir : PO debe estar disponible para el equipo, pero el equipo no debe abusar de él, de lo contrario, el tiempo de PO se dedicará solo a preguntas ad hoc. Debe elaborarse un formato de interacción que sea cómodo para todos, en el que el equipo reciba oportunamente de PO la información necesaria y las decisiones que el equipo realmente no puede tomar por sí solo. Puede llamar a las retrospectivas de PO con cierta regularidad y discutir el tema de la frecuencia, las herramientas y el formato de comunicación allí.
Síntoma : PO no inculca ni promueve una cultura de retroalimentación del equipo. O PO proporciona comentarios unidireccionales filtrando elogios o críticas.
Por qué es malo : cuando el OP no brinda comentarios honestos regulares al equipo, esto desmotiva al equipo. Sin sincronización de expectativas y resultados. El equipo no siente complicidad, en realidad no son los creadores del producto, simplemente realizan su función. “El equipo suministra regularmente incrementos. El equipo recibe regularmente comentarios honestos sobre su trabajo ”, parece ser un trato justo.
Cómo tratar : PO, por supuesto, no debe cargar al equipo con toda la cantidad de información con la que trabaja, todo lo que recibe de los usuarios y analistas. Debe agregar y emitir información que ya es importante y comprensible para el equipo. Así llegar a una variedad de formatos para la retroalimentación, no sólo sobre la base de cifras secos (por ejemplo: pruebas en vivo, entrevistas, etc.). El equipo mismo debe recordarle a PO la necesidad de retroalimentación: hacer preguntas, construir un proceso regular para recibir retroalimentación. Si convierte a PO en el “propietario” del evento de revisión de sprint y lo desconcierta con el hecho de que el equipo necesita comentarios, al menos le recordará a PO el trabajo en los comentarios, y puede conducir a un enfoque más creativo para organizar dichos comentarios.
Interacción entre PO y usuarios del mercado
Síntoma : PO no conoce a "su" usuario; El producto ve un conjunto de características. PO ignora las solicitudes de los usuarios y la información de los usuarios existentes. No se comunica con usuarios en vivo.
Por qué es malo : en primer lugar, el producto está creado para el usuario que tiene ( tal vez todavía no lo sabe ) la necesidad satisfecha por el producto. Y si no conoce ni comprende al usuario, entonces es imposible "asumir la responsabilidad de lograr el máximo valor del producto", como lo exige la guía scrum.
Cómo tratar : existen muchas herramientas diferentes para realizar investigaciones cualitativas, por ejemplo, entrevistas en profundidad, un retrato de un usuario, un mapa de viaje del cliente , herramientas para recopilar análisis cualitativos (vs cuantitativos) , etc. etc. Debe probar varias herramientas y dejar útiles / trabajando para su producto. La mayoría de estas herramientas en la salida tienen una visualización del resultado, vale la pena colocarlas frente al equipo para aumentar la transparencia. Vale la pena actualizar estos artefactos de vez en cuando. Puede organizar un equipo de descubrimiento de productos para ayudarlo a realizar investigaciones de calidad. Si PO logra establecer una interacción con el usuario, entonces puede usar este contacto, por ejemplo, para la revisión del sprint: darle al usuario un nuevo incremento, y el equipo examinará cómo el usuario hará frente a la tarea, la ayuda para resolver lo que estableció en el incremento.
Síntoma : PO no estudia el mercado / competidores.
Lo que es malo : el producto vive como si estuviera en el vacío, y está divorciado de la realidad, debe ser un visionario para crear un producto valioso en tales condiciones.
Cómo tratar : hay una serie de prácticas para los propietarios de productos, cómo estudiar y crear mercados, vale la pena probar varios de ellos y dejar otros beneficiosos. En esta actividad, los analistas o un equipo pueden ayudar a las OP. Es útil buscar " océanos azules " de vez en cuando. Y, por supuesto, debe inspirarse en capacitaciones, reuniones de comida y conferencias.
Conclusión
Un análisis de los roles restantes aparecerá en las siguientes partes. Ahora veamos cómo esta información puede serle útil. Examinamos algunos de los posibles síntomas, diciendo que algo anda mal en el scrum y las opciones para cambiar la situación. Si lo desea, una lista de verificación al final:
- Al leer casi todos los elementos, te reconociste a ti mismo ( tu equipo / organización ), es decir Tienes un scrum con comprensión no canónica. Entonces vale la pena hacer preguntas: ¿necesitas scrum? ¿Por qué necesitas scrum? ¿Qué tareas le pones? ¿Está la cultura corporativa lista para valores y principios ágiles? Si tiene respuestas y comprende por qué se necesita scrum, y realmente apuesta por ello, entonces continúe con la segunda opción. De lo contrario, deja de practicar el autoengaño.
- Al leer algunos puntos pensaste que no se trataba de ti. Algunos puntos te llevaron a razonar y te acordaste de tu situación. Si es así, seleccione los elementos que pueden ser aplicables a su situación. Imprimirlos en forma de tarjetas. Discuta los síntomas con el equipo: ¿son justos con usted? Discuta los riesgos, ¿está de acuerdo con ellos o tal vez vea consecuencias más peligrosas de los síntomas? Luego tome la tarjeta que más preocupa al equipo, el síntoma más peligroso en este momento. Considere la solución propuesta, ¿es adecuada para usted? Colabore colectivamente con cómo puede mejorar la situación, cómo aliviar el síntoma. Y actuar! Después de haber tratado un síntoma, continúe con el siguiente, volviendo periódicamente a la revisión general, para asegurarse de que los resultados que ya ha logrado no hayan disminuido.
- Si leyó todo y no reconoció sus realidades en estas situaciones, tenemos todo bien. ¿Existen realmente tales organizaciones? Ustedes son excelentes compañeros, ¡asegúrese de compartir en los comentarios cómo lograron esto!
PD: Espero que el artículo proporcione una herramienta de trabajo para los equipos scrum para la superación personal.
Para ilustración PPS gracias Sai Kin
UPD Parte 2 y Parte 3 .