En la primera parte, observamos síntomas alarmantes y posibles formas de "tratar" al propietario del producto en un scrum "mecánico". Continuamos el análisis de roles y el siguiente en la línea es el equipo.
Sin embargo, conocen el mantra de que el equipo debe ser autoorganizado y multifuncional, parece la parte más simple de scrum: tomamos a las personas con las competencias adecuadas, les decimos: "ustedes son un equipo", ¡y volamos! Pero en realidad, todo es algo más complicado.
Autoorganización
Síntoma : hay una jerarquía explícita (presentación de directivas) fuera, o peor dentro de un equipo. Es decir de hecho, un desarrollador de productos puede tener una tarea que no está directamente relacionada con las actividades del equipo. O, dentro del equipo, las personas no son libres de elegir un trabajo para lograr el objetivo del sprint, sino que reciben tareas del "líder".
Lo que es malo :
Cualquier límite - limit @ CEP
Cuando una persona es presionada por la descripción del trabajo, la jerarquía de sumisión, etc., esto evita que se revele. La fuerza del equipo scrum está en abrir oportunidades para las personas. Hay una tarea, tomar valor y ser responsable de su implementación. Una persona debe decidir por sí misma qué hará para lograr el objetivo del sprint. Si le dicen qué hacer, entonces esto no es autoorganización ni scrum.
Cómo tratar : Para las personas en el equipo, todas las descripciones de trabajo y jerarquías se cancelan, la estructura tiende a ser plana.
Todos los que están en el equipo son los
desarrolladores del producto (la
guía scrum no permite otros roles ). Solo existe un liderazgo situacional, y las personas deciden qué tan cómodos se sienten para trabajar para ser efectivos. Por supuesto, hay reglas generales del juego en la compañía, el equipo no las viola de ninguna manera (
aunque puede afectar el cambio a nivel de la compañía ), pero es responsable de todas las cosas internas. Si existen obstáculos serios para levantar las restricciones para los desarrolladores, entonces vale la pena escalar el problema a aquellos que han decidido implementar scrum y una transformación ágil. Puede intentar ejecutar una estructura plana, como un experimento para varios sprints, y luego realizar una amplia retrospectiva, donde todas las partes interesadas discutan los resultados del experimento.
Síntoma : las personas, además de trabajar en equipo, deben realizar otras tareas funcionales en la empresa. Por ejemplo: el 50% del tiempo realiza las tareas del equipo, el 50% - las tareas del departamento (desarrollo, pruebas, etc.).
Que mal : uno de los valores en scrum es el foco. El equipo se enfoca en la meta del sprint y avanza hacia ella. Si, además de trabajar en equipo, una persona tiene que hacer otra cosa, se pierde el enfoque. Como resultado, el resultado será peor. Es difícil mantener el espíritu de equipo en tales condiciones.
Cómo tratar : debemos asegurarnos de que las personas del equipo trabajen SOLO en este equipo. Para hacer esto, vale la pena comprender la naturaleza del trabajo que recayó sobre los desarrolladores del equipo desde el exterior, y encontrar formas de hacerlo sin romper el scrum. Seguramente este trabajo es necesario para la empresa, por lo tanto, dependiendo de los detalles del trabajo, puede:
- coloque el trabajo en la cartera del equipo y luego se realizará de acuerdo con un solo flujo de trabajo.
- o transferirlo a otros empleados fuera del equipo. Por ejemplo: no toda la empresa trabaja en scrum, y usted necesita hacer un trabajo regular en un momento específico, entonces ese trabajo ya no es adecuado para los empleados de scrum.
- o se puede crear un equipo especial y seleccionar un producto que recopile todo el trabajo de este tipo.
- o, si es una función única que realiza una persona para varios equipos debido a la falta de especialistas. Entonces vale la pena sacar a la persona de todos los equipos y construir otro proceso para él que no rompa el resto del scrum ( por ejemplo: una cola de tareas priorizadas ), hasta que se encuentren especialistas en estos equipos scrum.
Funcionalidad cruzada
Síntoma : las personas del equipo solo realizan un determinado trabajo, existe una clara especialización. Peor aún cuando todavía está cubierto por deberes oficiales, regulaciones y otra burocracia. La ausencia (vacaciones, baja por enfermedad, etc.) de un miembro del equipo reduce la funcionalidad del equipo. Hola, factor bus .
Lo que es malo : si un equipo depende de las competencias de uno de sus miembros, es un equipo que es inestable a los cambios. Es difícil establecer comunicación con ella, porque debe comprender su funcionalidad actual y recordar los riesgos asociados con este nivel de tolerancia a fallas. La estrecha especialización de los desarrolladores complica en gran medida el trabajo organizativo del equipo: al planificar, debe pensar mucho sobre quién hará qué; no todas las tareas necesitan proporciones predeterminadas de las competencias del equipo, por lo tanto, es difícil armar un sprint equilibrado; En tal esquema, necesariamente surge un "cuello estrecho", lo que reduce la velocidad general del equipo.
Qué hacer : es necesario promover y apoyar las habilidades en forma de t . Para mantener al equipo flexible, es importante que una función o conocimiento particular no se concentre en una sola persona. Es necesario estimular y fomentar el desarrollo continuo. Es importante asegurarse de que el equipo mejore, buscando formas de mejorar los procesos. Como opciones de desarrollo en forma de t: realización de seminarios internos, donde los miembros del equipo comparten conocimientos entre sí; adoptar la regla de ejecución de tareas no centrales cada sprint por cada miembro del equipo; trabajo en pareja en tareas, etc. Puede estimular artificialmente a un equipo "apagando" a sus miembros por un tiempo: vacaciones, seminarios, capacitaciones, viajes de negocios, etc.
Síntoma : en la cadena de valor, el equipo es responsable (influye) solo de una pequeña parte y, como resultado, el equipo no puede emitir incrementos por sí solo.
Que mal : si el equipo tiene poco efecto en la entrega del incremento ( lanzamiento del producto ), entonces scrum también pierde su esencia: los lanzamientos ocurren con un retraso, la retroalimentación ocurre con un retraso aún mayor. En general, no hay ritmo y, por lo tanto, velocidad. Sin velocidad, sin flexibilidad. Tal equipo no siente su propiedad, es solo un tornillo funcional en un automóvil grande. La funcionalidad del equipo debería ser suficiente para cerrar la mayor parte de la cadena de valor, de lo contrario, el equipo simplemente no entregará valor, sino que simplemente procesará un tipo de "pieza de trabajo" en otro y lo transferirá aún más.
Ilustramos esto con un ejemplo de la web. Donde se simplificó la creación de una nueva característica incluye los siguientes pasos:
- Desarrollo de prototipos UI / UX
- desarrollo de diseño
- crear una API RESTful
- Creación de SPA
- escribir pruebas de integración
- montaje y lanzamiento en el entorno de combate
Para estos trabajos, se requieren diversas competencias. Un ejemplo de una división fallida en equipos: para separar el
equipo A de UI / UX, diseñadores y desarrollo frontend, preparan su incremento en forma de SPA; pero dependen de cuándo el back-end preparará la API para que la nueva funcionalidad funcione; espere a que QA verifique todo de manera integral y escriba pruebas; y todavía esperan que DevOps lo ponga todo en combate. Es difícil para tal
equipo A ser responsable de la liberación y entrega de valor, simplemente corta el "espacio en blanco" - SPA.
Cómo tratar : determinamos qué competencias le faltan al equipo para entregar el incremento. Dotamos al equipo con estas competencias al capacitar a los miembros existentes del equipo o al agregar nuevos jugadores al equipo. Porque encontrar / enseñar personas no es la tarea más fácil y rápida, entonces puede establecer comunicaciones con equipos / departamentos vecinos, explicarles los valores scrum y acordar con ellos sobre reglas especiales / reglas de interacción bajo las cuales no romperán scrum a su equipo. Vale la pena resaltar el proceso de expansión de la funcionalidad del equipo: después de la primera retrospectiva e identificar las competencias faltantes, puede imprimirlas y colocarlas frente al equipo. Cuando un equipo hace frente a una falta de competencia (
aprendido; un nuevo miembro del equipo; establece una comunicación efectiva con otro equipo, etc. ), colgamos una solución además de la competencia que faltaba anteriormente. Con el tiempo, el equipo debe esforzarse por expandir su funcionalidad para cubrir completamente la cadena de valor.
Equipo y producto
Síntoma : hay un equipo, pero no hay producto. Sin PO, sin retraso. Es solo que las personas realizan tareas que provienen de diferentes direcciones.
Que mal : esto no es scrum. Cuando un producto no está asignado a un equipo, es poco probable que el equipo se "queme" con el trabajo. Cuando hay un objetivo global ( visión / estrategia / hoja de ruta del desarrollo de productos ), desea ir a él. Usted hace el trabajo, recibe comentarios, reflexiona y da el siguiente paso. Sin un sentido de propiedad, corre el riesgo de estar en una rutina: realmente no necesita comentarios, el equipo se convierte en una herramienta para procesar los conocimientos tradicionales en funcionalidad.
Cómo tratar : el equipo debe tener su propio producto con cartera de pedidos y PO, lo que puede encender al equipo con el producto y llevarlo consigo, esa es la esencia. ¿Necesita entender por qué necesita scrum? ¿Entiendes de dónde viene el equipo? ¿Entiende si hay un "producto" entre este flujo? Elija entre los equipos de "clientes" uno y conviértalo en el propietario del producto , dándole el derecho exclusivo de responder por el retraso. Puede ser necesario dividir el equipo en un equipo scrum que trabaje con un PO ( este puede ser un equipo scrum "piloto" ) y un segundo equipo, mientras trabaja de la misma manera con el resto de los "clientes". Al proporcionar la máxima transparencia de los procesos y resultados que ocurren en el nuevo equipo scrum, puede sentar las bases para una mayor distribución de scrum y ágil en la organización.
Síntoma : el equipo no tiene influencia en el componente del producto: no decide "¿cómo hacerlo?", El equipo simplemente dice "¿qué hacer?" TK llega a la entrada, y el equipo es considerado como una unidad funcional.
Que mal : esta es una opción muy peligrosa si la empresa realmente proclama los valores de ágil y scrum. Por lo general, esto implica que todos los empleados son profesionales geniales que pueden resolver cualquier problema que no tenga miedo de tomar decisiones y asumir la responsabilidad. Pero si no se les permite tomar decisiones sobre el producto, toda la libertad creativa del equipo generalmente se extiende desde el producto a la tecnología. Dado que el equipo no puede decidir cómo facilitar la vida del usuario, el mundo es mejor y el producto es más útil; luego el equipo comienza a desarrollar una base de código, probar nuevas tecnologías / herramientas / marcos, etc. Existe un conflicto de intereses entre el OP y el equipo, el equipo comienza a vender "refactorización", "optimizaciones", "balas de plata" en forma de una nueva pila, etc. Y esto se ve afectado principalmente por el usuario y el producto. En el proceso de pasar de los modelos de gestión directiva a ágil, existe el peligro de quedar atrapado en la comprensión del equipo como una unidad funcional (el equipo no había tomado una decisión antes ). Esto está plagado del hecho de que, o matamos la iniciativa del equipo, o llegamos a una situación en la que el equipo está más interesado en la tecnología que en el producto.
Cómo tratar : debe identificar la causa de la desconfianza del equipo o su indecisión: ¿por qué el equipo no está buscando una solución, sino que solo trabaja con una tarea técnica detallada? Una vez encontrada la causa, puede eliminarla gradualmente. Por ejemplo:
- El equipo carece de competencias o experiencia. : Alguien está trabajando en soluciones y escribiendo TK, puede agregar a esta persona al equipo o dejar que trabaje en algunas tareas junto con el equipo, transfiriendo así parte de sus habilidades y experiencia al equipo. Poco a poco, el equipo aprenderá y se acostumbrará a resolver los problemas del producto.
- La gerencia teme que el equipo cometa un error. : Este es el miedo fundamental en la transición a ágil, pero sin superarlo, no podrás obtener toda la fuerza del equipo scrum. El equipo está obligado a cometer un error, porque todos están equivocados. Pero un error es una fuente de experiencia y habilidad. Es más útil cuando un equipo comete un error, porque así lo decidió, y no por un TK externo incorrecto. Scrum es ritmo: rápidamente tomó la decisión de probar una hipótesis; Comentarios recibidos se dio cuenta de que iban por el camino equivocado; tiró la decisión. El costo de un error se reduce drásticamente ( gastó un sprint, no un trimestre / año / su período de lanzamiento ), lo que le permite superar el miedo al error.
Síntoma : los miembros del equipo no tienen acceso gratuito a los artefactos del equipo. Por ejemplo, no todos ven un sprint o un retraso general, o existen dificultades con la posibilidad de actualizar su estado.
Lo que es malo : Scrum se basa en la transparencia, los artefactos ayudan a aumentar la transparencia. Si los miembros del equipo tienen dificultades para trabajar con estos artefactos, entonces los miembros del equipo no tienen transparencia en el trabajo en equipo, y para otras partes interesadas la situación será aún peor: no está claro quién está haciendo qué y por qué. No está claro dónde está el equipo camino a la meta.
Cómo tratar : es necesario determinar los formatos de los artefactos scrum en un equipo y hacerlos ( puede dedicar esta retrospectiva ), y luego colocarlos para que el equipo se sienta cómodo trabajando con ellos. Es genial si puedes crear un espacio separado para el equipo, las condiciones bajo las cuales el equipo trabajará lado a lado (hombro con hombro) al mismo tiempo. Esto reducirá la sobrecarga de comunicación. Y en el espacio común es fácil visualizar todo ( rotafolios, pegatinas, marcadores son las herramientas favoritas de Agile ), lo principal es que es conveniente, no estresante para el equipo. Los artefactos deberían ayudar, y no interferir con el trabajo del equipo, no burocratizarlo. La interacción verbal es buena para el trabajo en equipo. Si hay dificultades con la organización del trabajo local del equipo ( por ejemplo, distribuido o remoto ), entonces debe maximizar el efecto del trabajo en equipo y la unidad. Por ejemplo, canales de presencia de video, tableros de scrum interactivos en vista directa de cada miembro del equipo, etc.
Conclusión
En la siguiente parte, continuamos considerando los roles de scrum y finalmente llegamos al scrum master. Le recordamos brevemente qué hacer con los síntomas:
- Seleccione los síntomas que se aplican a su situación.
- De estos, elija el más nítido.
- Toma conciencia de este dolor.
- Se te ocurre una solución de equipo ( puedes tomar casos del artículo como punto de partida ).
- Implementa tu decisión.
- Ve al paso 1.
Gracias por leer, me gustaría ver los "síntomas" conocidos en los comentarios.
Gracias a Sai Kin por la ilustración.
La siguiente parte sobre el Asistente de Scrum