Trabajo en equipo coordinado en Scrum
La fundación de Scrum, el marco de gestión ágil más popular, comenzó a partir de un artículo de 1986 en la revista Harvard Business Review escrito por Hirotaka Takeuchi e Ikujiro Nonaka. En el artículo, Takeuchi y Nonaka presentaron el término "Scrum", resaltaron las estrategias de trabajo en equipo que utilizan los equipos de rugby para marcar puntos, y sugirieron que los equipos de desarrollo de productos podían usar métodos similares para mejorar sus tasas de éxito.
La investigación presentada en el artículo señaló que los equipos pequeños y autoorganizados lograban un rendimiento significativamente mejor en productos complejos cuando los equipos recibían objetivos, pero tenían la posibilidad de establecer cómo alcanzar esos objetivos por su cuenta.
Ken Schwaber y Jeff Sutherland desarrollaron el marco Scrum y formalizaron los roles de los miembros del equipo de Scrum en la década de 1990. En 1995, publicaron un artículo titulado "SCRUM Software Development Process". Después de realizar gradualmente otras mejoras en Scrum y publicar otros artículos, Schwaber y Sutherland completaron la primera publicación de la Guía de Scrum en 2010.
En la Guía de Scrum, el método Scrum y los roles de equipo se definen como "un marco dentro del cual las personas pueden abordar problemas adaptativos complejos, al mismo tiempo que entregan productos del mayor valor posible de manera productiva y creativa. El marco Scrum consta de equipos de Scrum, junto con sus correspondientes roles, eventos, artefactos y reglas".
En las descripciones dentro de la Guía de Scrum sobre los roles del equipo, se afirma que "el equipo de Scrum está formado por un propietario del producto, el equipo de desarrollo y un Scrum Master. Los equipos de Scrum son multifuncionales y autoorganizados. Los equipos autoorganizados eligen la mejor manera de realizar su trabajo, en lugar de ser dirigidos por otras personas ajenas al equipo. Los equipos multifuncionales presentan todas las competencias necesarias para realizar el trabajo sin depender de otras personas que no forman parte del equipo. El modelo de equipo en Scrum está diseñado para optimizar la flexibilidad, creatividad y productividad. Los equipos de Scrum entregan productos de manera iterativa e incremental, y maximizan las oportunidades para recibir comentarios".
Schwaber y Sutherland publicaron una edición actualizada de la Guía de Scrum en julio de 2016. El contenido más notable agregado a la edición de 2016 es la sección sobre los valores de Scrum, que incluye detalles sobre cómo los miembros de los equipos de Scrum deben interactuar entre sí y con el resto del personal de la empresa.
Guía para la gestión de proyectos
Su ventanilla única para todo tipo de gestión de proyectos
¿Está listo para sacar más provecho de sus esfuerzos de gestión de proyectos? Visite nuestra guía completa de gestión de proyectos para obtener consejos, prácticas recomendadas y recursos gratuitos para gestionar su trabajo de manera más efectiva.
Recomendaciones sobre el tamaño del equipo de Scrum
Para lograr la máxima cohesión en el equipo de Scrum y maximizar el nivel de trabajo en equipo dentro del grupo, los expertos suelen ofrecer consejos sobre el tamaño del equipo. Schwaber, que brinda capacitaciones sobre Scrum a través de su organización Scrum.org, realiza recomendaciones sobre el tamaño del equipo en su libro de 2007, The Enterprise and Scrum. Schwaber explica que los equipos de Scrum deben "tener un límite de tamaño para maximizar la velocidad, el contenido, la precisión y el ancho de banda de las comunicaciones. El tamaño del equipo puede incluir hasta nueve personas".
Más adelante en su libro, Schwaber ofrece el siguiente consejo: "Mantenga el tamaño del equipo lo más cercano posible a siete. Al parecer, siete mentes son capaces de alcanzar y mantener un modelo mental compartido de un sistema, junto con su representación en diseño y código, sin ayudas artificiales, como la documentación. Los malentendidos y el tiempo de registro se minimizan".
Mindi Schnase, gerente de proyectos de Renown Health, cuenta con una certificación de CSM (Scrum Master certificada) de Scrum Alliance y una certificación de PMP (profesional de gestión de proyectos) del PMI (Project Management Institute). En International Game Technology (IGT), empleador anterior de Schnase, trabajó como ingeniera líder de aseguramiento de la calidad antes de pasar al rol de Scrum Master. La experiencia de Schnase conllevó trabajar en equipos de Scrum de distintos tamaños.
Schnase sugiere que de siete a nueve personas por equipo es un tamaño bueno y manejable, aunque también explica que el tamaño del equipo está influido por los detalles específicos del proyecto. "Realmente depende del alcance del proyecto. Fui Scrum Master en varios equipos: uno tenía tres miembros, otros tenían entre siete y diez personas".
Sutherland, que sigue dando cursos de Scrum a través de su organización Scrum Inc., ha incluido mucha información sobre la dinámica de equipo en el sitio web de su organización, como el siguiente análisis sobre el tamaño del equipo y la productividad:
"Lawrence Putnam, una figura legendaria en el desarrollo de software, convirtió en el trabajo de su vida estudiar cuánto tiempo se tarda en hacer cosas y por qué. Su trabajo continúa mostrando que los proyectos con 20 o más personas requieren más esfuerzo que aquellos con cinco o menos. No se trata de solo un poco más de esfuerzo, sino mucho más. A partir de esta hipótesis, analizó 491 proyectos de tamaño medio en cientos de empresas diferentes. Todos estos proyectos requerían la creación de nuevos productos o funciones, no una readaptación de versiones anteriores. Dividió los proyectos por el tamaño del equipo y notó algo de inmediato. Cuando los equipos superaban las ocho personas, tardaban mucho más en hacer las cosas. Los grupos formados por tres a siete personas requerían alrededor del 25% del esfuerzo que utilizaban los grupos de nueve a veinte personas para realizar la misma cantidad de trabajo".
Según los expertos, la cantidad ideal de miembros en el equipo es siete. Sin embargo, no tema a ajustar la cantidad de miembros en función de proyectos específicos.
El flujo de trabajo y los eventos de Scrum hacen que los equipos de Scrum sean más efectivos
Cuando se toma la decisión de aplicar Scrum como parte de la gestión ágil de proyectos, participan equipos de diversas formas y tamaños en un flujo de trabajo particular. Los eventos de Scrum tienen un propósito valioso: fomentan la comunicación regular, especialmente entre los miembros del equipo, y minimizan la necesidad de realizar reuniones adicionales no definidas en Scrum.
Si no incorporaran eventos de Scrum a sus calendarios, los equipos no serían tan efectivos ni estarían tan centrados. La siguiente lista representa el flujo de trabajo típico que utilizan los miembros del equipo de Scrum para el desarrollo de productos.
Visión del producto: el propietario del producto resume la visión del producto en una declaración luego de recibir comentarios de varias fuentes, incluidos los usuarios finales, los clientes, los miembros del equipo y otras partes interesadas. La declaración de visión del producto incluye detalles del caso de negocio sobre los objetivos del producto y cómo el producto encaja en las estrategias de la empresa.
Trabajo pendiente y refinamiento del producto: los elementos del trabajo pendiente del producto representan todo lo que se puede entregar en un proyecto de forma independiente. La mayoría de estos elementos se centran en ofrecer valor a los clientes, al igual que las funciones del producto y las historias de usuario. Las historias de usuario presentan situaciones específicas y detalladas para explicar aquello que los usuarios lograrán con una nueva función. Los trabajos pendientes del producto también pueden incluir requisitos del mercado, especificaciones, casos de uso y otros elementos.
El propietario del producto prioriza los elementos del trabajo pendiente del producto según el valor comercial que representa cada elemento. Por lo general, el 80% del valor de un producto se encuentra en el 20% de sus funciones. La asignación de valor comercial para priorizar los elementos del trabajo pendiente del producto garantiza que las funciones más valiosas se construyan primero. Los elementos situados en la parte superior del trabajo pendiente del producto están bien definidos y se incluyen en un sprint próximo. Los demás elementos deben refinarse durante una reunión de refinamiento del trabajo pendiente del producto.
Algunos propietarios de productos y equipos de desarrollo realizan una reunión de refinamiento del trabajo pendiente del producto hacia la mitad o el final del sprint actual para refinar aún más los elementos del trabajo pendiente del producto para futuros sprints. Otros equipos de Scrum tratan el refinamiento como un proceso continuo.
Ejecución de sprints efectivos: los dos pasos siguientes se completarán para ayudar a los equipos a ejecutar sprints efectivos. Un sprint (a veces llamado iteración de longitud fija) es el período en el que los equipos completarán una sola iteración del trabajo antes de volver a reunirse y prepararse para la siguiente, y representa un componente importante en la gestión ágil de proyectos.
- Planificación de sprints: el propietario del producto, el Scrum Master y el equipo de desarrollo se reúnen durante una sesión de planificación de sprints a fin de elegir los elementos del trabajo pendiente del producto para el próximo sprint y comprometerse con un objetivo. Los miembros del equipo de desarrollo seleccionan elementos en la parte superior del trabajo pendiente del producto hasta que tengan suficiente trabajo para completar el plazo del sprint. Los elementos seleccionados se mueven al trabajo pendiente del sprint.
- Tablero de Scrum y trabajo pendiente del sprint: todos los elementos del trabajo pendiente del sprint deben completarse al final del sprint. Para garantizar un sentido de la responsabilidad compartida, los elementos se colocan en una de las columnas, generalmente etiquetadas como Pendiente, Trabajo en curso (WIP) y Listo, en un tablero de Scrum físico o digital (tablero de tareas). El tablero de Scrum debe estar visible para todo el equipo, y los elementos relacionados (a menudo, escritos en notas adhesivas como tareas o historias de usuario) deben reflejar el estado del sprint en tiempo real. Seguir esta guía permite al equipo realizar ajustes si un elemento en particular está retrasado en el cronograma.
Sprint: los sprints duran de una a cuatro semanas. Cada sprint representa un breve ciclo de desarrollo y da como resultado un incremento del producto (oficialmente conocido como incremento de producto potencialmente entregable) o el producto terminado. Los equipos no siempre pueden completar un incremento de producto entregable, especialmente al principio. Sin embargo, esto es algo a lo cual el equipo debe aspirar a medida que mejora con el tiempo.
Scrum diario: durante cada sprint, los miembros del equipo de desarrollo participan en reuniones diarias de actualización conocidas como Scrums diarios. La duración máxima de la reunión es de 15 minutos porque los participantes solo comparten sus respuestas a tres preguntas básicas: 1) ¿qué se logró desde la última reunión?; 2) ¿qué se hará antes de la siguiente reunión?; y 3) ¿qué obstáculos hay en el camino?
El propósito de esta reunión es brindar al equipo de desarrollo la oportunidad de coordinar los esfuerzos, sincronizar el trabajo e informar sobre los impedimentos (problemas técnicos, obstáculos del departamento, etc.). Este no es el tipo de reunión donde los empleados entregan un informe de progreso a su gerente. El Scrum Master puede asistir para averiguar qué obstáculos debe resolver, mientras que el propietario del producto no suele asistir.
Reunión de Scrum de Scrums: en una afirmación destacada del instructor de Scrum Mike Cohn en el sitio web de Scrum Alliance, la reunión de Scrum de Scrums se describe como "una técnica importante para adaptar los Scrums a la escala de equipos de proyectos grandes. Estas reuniones permiten que conjuntos de equipos analicen su trabajo centrándose sobre todo en las áreas de superposición e integración. Imagine un proyecto perfectamente equilibrado compuesto por siete equipos, cada uno con siete miembros. Cada uno de los siete equipos lleva a cabo su propia reunión diaria de Scrum de forma simultánea o secuencial. Luego, cada equipo designa a una persona para que también asista a una reunión de Scrum de Scrums".
En las reuniones de Scrum de Scrums que Schnase facilitó, entre los asistentes se incluyen Scrum Masters, propietarios de productos, líderes técnicos, así como algunos gerentes de aseguramiento de la calidad, patrocinadores de programas y gerentes de departamentos que estaban directamente conectados con los proyectos en los que trabajaban los equipos de Scrum. "Cada dos semanas, realizamos un Scrum de Scrums para conversar sobre logros, hitos, progreso, dependencias y obstáculos", dice Schnase.
Revisión del sprint: al final de cada sprint, el equipo lleva a cabo una revisión del sprint (también conocida como revisión de iteración o demostración de sprint) para demostrar la funcionalidad del producto creada durante el sprint a las partes interesadas, las personas directamente afectadas por el resultado del producto. Las revisiones o demostraciones de sprints también son una oportunidad valiosa para demostrar el producto a las personas que utilizan el software, y pueden proporcionar comentarios inmediatos.
Reunión retrospectiva del sprint: después de la revisión del sprint, el equipo de Scrum participa en una reunión retrospectiva para analizar los éxitos y fracasos del sprint, y hacer planes de mejoras. Otro propósito de la reunión retrospectiva es desarrollar aún más el proceso y las prácticas que utiliza el equipo de Scrum, y volverlos más efectivos para el próximo sprint.
El equipo también busca formas de aumentar la calidad del producto y, si corresponde, modificar los elementos según la definición de "listo". En "The Basics of Scrum" en Scrum Inc., algo listo se define de la siguiente manera: "Un elemento del trabajo pendiente está listo si es independiente, utilizable, se le ha asignado un valor con puntos, y tiene una definición clara de los criterios sobre lo que significa estar listo. A su vez, esta definición de listo garantiza que todos sepan exactamente lo que se espera de un elemento cuando se entrega".
Modelo de desarrollo de equipos de Scrum
Para crear un equipo de Scrum eficaz, Schnase dice que es importante que todas las personas tengan pasión y una actitud positiva hacia el proceso a fin de que los miembros del equipo trabajen bien en conjunto. En varios recursos de Scrum, se menciona el modelo de desarrollo grupal de Bruce Tuckman como un método efectivo a seguir cuando se construye un equipo de Scrum o se agregan nuevas personas al equipo. En el artículo de Tuckman, "Developmental sequence in small groups", publicado en la revista Psychological Bulletin en 1965, se afirma que los nuevos equipos deben pasar por varias etapas antes de alcanzar un nivel de alto rendimiento y ofrecer resultados óptimos. Tuckman denominó estas etapas como formación, conflicto, normalización y desempeño.
El nombre de cada etapa dentro del modelo de desarrollo de grupo de Tuckman refleja con precisión la dinámica del equipo durante ese período particular.
Formación: Tuckman se refiere a esta etapa como una centrada en la orientación, las pruebas y la dependencia. Los miembros del equipo aún no están familiarizados entre sí, y siguen pensando en su trabajo como tareas individuales en lugar de un trabajo colaborativo de todo el equipo en conjunto. Las sesiones de cooperación del equipo y los almuerzos grupales suelen ayudar al equipo a sentirse más cómodo.
Conflicto: por lo general, en la etapa de conflicto, los miembros del equipo se aferran a sus opiniones y se resisten diversos aspectos de la influencia del equipo, por lo que suelen ocurrir roces en los grupos. La etapa de conflicto ocurre cuando se anima a los miembros del equipo a aceptar que habrá diferencias dentro del equipo, y que la diversidad puede dar lugar a más ideas y un aumento en la productividad. Para avanzar a la siguiente etapa, los miembros del equipo necesitan tener seguridades sobre los requisitos laborales y las exigencias de la tarea. A medida que se establece la confianza y la estabilidad, resultará más fácil resolver los roces.
Normalización: cuando el equipo alcanza la etapa de normalización, los miembros tienen áreas de acuerdo consolidadas y llegan a un consenso. Se establecen pautas claras sobre los roles individuales, lo que da lugar a una apertura y coherencia emergentes entre los miembros. El objetivo dentro de esta etapa es trabajar juntos para desarrollar estándares de grupo y debatir sobre las ideas e interpretaciones relevantes.
Desempeño: dentro de la etapa de desempeño, el grupo demuestra una visión unificada, energía colectiva y un sentido del propósito. El equipo aprende a desempeñarse bien en conjunto y a resolver problemas de manera positiva y diplomática. Según Tuckman, los roles se vuelven flexibles y funcionales, y la estructura del equipo admite un mayor nivel de rendimiento.
Schnase recomendó tener en cuenta el modelo de Tuckman cuando se agregan personas a un equipo de Scrum porque un nuevo miembro cambia la dinámica del equipo. Según ella, cada vez que el equipo atraviesa un cambio, pasará por las etapas de formación, conflicto, normalización y desempeño. "La velocidad disminuirá cuando agregue un nuevo miembro del equipo, por lo que debe tener tal fenómeno en cuenta".
Schnase también señaló otra razón por la que es efectivo realizar reuniones retrospectivas de sprint. "Las reuniones retrospectivas son importantes porque el equipo necesita reflexionar sobre los aspectos positivos y aquellos elementos que podrían mejorar. Ayuda al equipo a avanzar a la etapa de desempeño".
Cooperación inicial de equipos de Scrum
Al igual que la mayoría de los modelos de desarrollo, lograr resultados lleva tiempo. Lo mismo ocurre con los equipos de Scrum. Un nuevo equipo no generará resultados superiores de inmediato. El tiempo que lleva a un equipo llegar a la etapa de rendimiento depende de las personas y otros factores, como la unidad del equipo, por lo cual la cooperación del equipo es imperativa.
"La cooperación del equipo es beneficiosa para establecer la confianza y para que todos los miembros del equipo reconozcan las fortalezas de los demás miembros del equipo", dice Schnase. "Se necesita tiempo para crecer en equipo".
La clave para la cooperación en el equipo está en encontrar algo que resulte interesante y divertido para todos, y dejar de lado los incómodos ejercicios cooperativos que nadie quiere. Prepare una lista de posibles actividades en equipo, pregunte a los miembros del equipo cuáles disfrutarían, y pida sugerencias. Puede barajar una excursión para vincularse fuera de la oficina, como un viaje a un museo o un encuentro deportivo local, una oportunidad de voluntariado en grupo o un simple almuerzo de equipo para fomentar un entorno de equipo sólido. Además, asistir juntos a un taller de capacitación en Scrum, especialmente uno que incluya sesiones de reunión, lo ayudará a analizar las fortalezas individuales que beneficiarán al equipo en general.
Equipos de Scrum remotos vs. coubicados
La cooperación de equipos es difícil cuando los miembros del equipo se encuentran en diferentes ciudades, mucho más cuando se trata de países diferentes. Schnase ha trabajado con miembros de equipo de Scrum de todo el mundo. Aunque algunos expertos recomiendan crear solo equipos coubicados porque a menudo desarrollan la cohesividad y la confianza de manera más fácil mientras trabajan juntos en un solo lugar, Schnase dijo que esta opción no es siempre posible.
Por ejemplo, los puestos de Schnase en IGT implicaron trabajar con miembros del equipo de Scrum de Australia y China, así como con personas de distintas ciudades de Estados Unidos. Si bien las diferencias horarias pueden ser un desafío, especialmente para los acuerdos de reuniones de grupo, afirma que se puede lograr que la situación funcione.
En estos casos, el proceso de cooperación de equipo puede tener que llevarse a cabo en línea mediante una herramienta de videoconferencia. Algunas empresas entienden el beneficio de reunir inicialmente a los miembros del equipo, y pagarán para que el equipo se reúna en un lugar central con fines de capacitación u otros objetivos de cooperación del equipo. Si este es el caso de su empleador, es posible que quiera preguntar a los miembros del equipo de Scrum si apoyarían la idea de reunirse en una conferencia de capacitación de Scrum, por ejemplo. Si todos apoyan la idea, sugiera la opción a su empleador.
Roles, responsabilidades y rasgos preferidos del equipo de Scrum
Los primeros desarrolladores de Scrum visualizaron los roles del equipo de Scrum dentro de una estructura autoorganizada similar a la que utilizan los equipos de rugby cuando pasan la pelota de un lado a otro y avanzan por el campo como una unidad coherente. Ahora, la estructura del equipo de Scrum es un modelo demostrado que los equipos de desarrollo de productos siguen para lograr resultados constantes, coordinados y confiables.
Un equipo de Scrum bien equilibrado incluye lo siguiente:
- Un propietario del producto que promueve la visión del producto y prioriza el trabajo pendiente del producto para maximizar la funcionalidad y el valor del producto para el cliente.
- Un Scrum Master que capacita eficazmente al equipo de desarrollo, facilita los eventos y elimina las distracciones que interfieren con el progreso del equipo.
- Miembros del equipo de desarrollo que se mantienen centrados en completar las entregas en incrementos (funcionalidad del producto completada al final de cada sprint) y elaborar un producto final superior.
Sutherland y Schwaber hacen hincapié en que existen motivos puntuales por los que hay roles de Scrum específicos, y que la combinación de tales roles suele provocar una disminución en la productividad. Los empleadores también deben reconocer que los equipos son mucho más productivos y estables cuando sus miembros solo se enfocan en un producto por sprint, y no están obligados a trabajar en varios productos o con otros equipos.
En las siguientes secciones, revisaremos las responsabilidades y los rasgos preferidos vinculados a cada rol para que los gerentes de contratación puedan evaluar a los candidatos de manera adecuada.
Rol de propietario de producto
La Guía de Scrum describe el rol del propietario del producto como responsable de "maximizar el valor del producto y el trabajo del equipo de desarrollo". En otras palabras, el propietario del producto es responsable de entregar un producto de alta calidad que maximice el retorno de la inversión (ROI) de la organización. El resto de sus responsabilidades principales están relacionadas con la comprensión y explicación de las expectativas del cliente para un producto, así como con la gestión del trabajo pendiente del producto, una lista con prioridades de las funciones del producto.
Schnase dice que el propietario del producto debe tener una clase de personalidad capaz de "proporcionar al equipo requisitos y objetivos de alto nivel para el producto, pero que también permita que el equipo establezca cómo lograr estos objetivos".
Los propietarios de productos suelen tener experiencia en gestión de productos o proyectos, marketing o diseño de experiencia de usuario (UX). A menudo, tienen experiencia en el análisis de las expectativas de los clientes, productos competitivos, demandas del mercado y tendencias futuras sobre el tipo de producto en desarrollo. Sus credenciales académicas varían según el tipo de producto, empresa e industria. Lo que es más importante, el propietario del producto debe tener una visión clara del producto y una fuerte conexión con él.
La siguiente lista representa las responsabilidades que debe cubrir la descripción del puesto del propietario de producto para lograr el éxito en ese rol.
- Desarrolla la visión del producto y hace hincapié en las expectativas del cliente: el propietario del producto debe ser una persona que pueda evaluar información de varias fuentes, desarrollar una visión del producto y promover tal visión. El propietario del producto debe poder presentar mensajes clave sobre el producto que resuenen con el equipo de Scrum, las partes interesadas y otras personas en la organización. Es especialmente importante que el propietario del producto represente el punto de vista del cliente al explicar el producto y cómo sus funciones nuevas o mejoradas superarán las expectativas.
- Tiene en cuenta el aspecto comercial del desarrollo del producto: los propietarios de productos deben tener conocimientos comerciales, comprender las necesidades corporativas que abarcan el desarrollo del producto, y reconocer la importancia del momento justo, las condiciones positivas del mercado y las decisiones en función de las inquietudes presupuestarias y el ROI. A su vez, los propietarios de productos deben ser estratégicos a la hora de desarrollar planes de publicación del producto y promover el producto en varios niveles, ya sea en el mercado, ante los directivos o el equipo de Scrum.
- Motiva al equipo con objetivos claros e inspiradores: el propietario del producto debe conversar sobre los requisitos y objetivos de alto nivel de cada proyecto con el equipo de desarrollo, responder todas las preguntas y permitir que el equipo decida cómo cumplir estas expectativas. El propietario del producto es responsable de priorizar el trabajo pendiente del producto, pero los miembros del equipo de desarrollo son quienes deciden cuánto trabajo pueden completar durante cada sprint, y cuántos sprints se necesitarán. Por tanto, el propietario del producto debe tener el tipo de personalidad que motiva a los miembros del equipo sin intentar controlarlos.
- Maximiza el valor del producto y el progreso del equipo de desarrollo: esta responsabilidad integral enfatiza cuán esencial es para el propietario del producto identificar correctamente qué funciones del producto son actualmente las más importantes y pertenecen a la parte superior de la lista de prioridades para el próximo sprint. Para realizar tal tarea de forma correcta a lo largo del proceso de desarrollo del producto, el propietario del producto debe perfeccionar y repriorizar constantemente los elementos del trabajo pendiente del producto. Los elementos del trabajo pendiente del producto (o más específicamente, las funciones del producto y las historias de usuario) deben priorizarse según el valor que aportan al producto. Algunos expertos van un paso más allá y afirman que el valor se determina a partir de la obtención del máximo valor comercial a cambio de los elementos de menor costo. Sin embargo, a veces es necesario satisfacer a los clientes clave y analizar otros factores de la estrategia comercial.
- Prioriza y gestiona el trabajo pendiente del producto: como único responsable del trabajo pendiente del producto, los propietarios de productos con experiencia reconocen las dependencias que deben tenerse en cuenta y evaluarse correctamente. Los propietarios de productos más efectivos entienden la necesidad de ser selectivos cuando alguien se acerca a ellos para solicitar un cambio u otra función nueva. Saben que no pueden aprobar todo y mantener los demás aspectos del desarrollo del producto en consonancia con el valor comercial y expectativas realistas. Saber cuándo decir "no" es una parte importante del trabajo.
- Perfecciona el trabajo pendiente del producto con regularidad: para asegurarse de que todo el equipo comprenda cada función listada en el trabajo pendiente del producto, el propietario del producto aclara las descripciones, explica su grado de importancia y pregunta al equipo si tiene alguna pregunta sin responder. Estos detalles también ayudan a garantizar el compromiso del equipo con un producto de alta calidad que coincida con las expectativas del cliente. Algunos propietarios de productos piden a los miembros del equipo de desarrollo que agreguen especificaciones técnicas, junto con otros detalles similares al trabajo pendiente del producto, pero el tiempo que los desarrolladores dedican a estas tareas debe ser mínimo.
- Presenta historias de usuario que se centran en la funcionalidad del producto: el equipo de desarrollo es responsable del trabajo pendiente del sprint determinado durante la reunión de planificación de sprints, pero el propietario del producto es responsable de las historias de usuario, descripciones de las funciones contadas desde la perspectiva del usuario. Algunos propietarios de productos crean ellos mismos la mayoría de las historias de usuario, mientras que otros involucran a todo el equipo en el proceso.
- Se mantiene comprometido con el equipo y está constantemente disponible: mostrar compromiso con ofrecer el mejor producto posible implica interactuar activamente con el equipo. Los propietarios de productos enfatizan su disponibilidad ante el equipo y utilizan sus competencias de comunicación para desarrollar relaciones sólidas.
- Aumenta el conocimiento mediante contactos: los propietarios de productos deben saber por qué es necesario establecer contactos con otras personas del sector mediante la asistencia periódica a conferencias y talleres. Una excelente manera de adquirir conocimientos es escuchar lo que otros tienen para decir sobre técnicas de modelado de negocios, lecciones aprendidas, historias de éxito de productos y mucho más.
Rol de Scrum Master
El Scrum Master es principalmente responsable de garantizar que el equipo de Scrum entienda y siga las prácticas y reglas de Scrum. Junto con esa responsabilidad, el Scrum Master se asegura de que las demás personas dentro de la organización respeten la teoría de Scrum lo suficiente para limitar la cantidad de distracciones que depositan sobre el equipo Scrum y aceptar comentarios sobre cualquier interacción que interfiera con el progreso del equipo.
Como guía y facilitador del equipo en proyectos complejos, el Scrum Master aporta valor al eliminar la mayor cantidad de obstáculos posibles para asegurarse de que el equipo de desarrollo permanezca centrado en sus objetivos. Schnase dijo que los Scrum Masters deben ayudar al equipo eliminando los obstáculos e impedimentos cuando sea necesario. "Si alguien no puede entrar a una carpeta de red que necesita, o bien el entorno de pruebas no funciona, el Scrum Master puede ayudar a elevar y resolver estos problemas", dice Schnase. "Los Scrum Masters deben poder comunicarse con cualquier parte interesada, además de ser asertivos y entusiastas".
Los Scrum Masters provienen de una amplia variedad de ámbitos y disciplinas académicas, como el diseño, la ingeniería, la TI, el marketing, la gestión de productos o proyectos, el aseguramiento de la calidad y las pruebas. Tienen cualidades particulares, como humildad, perseverancia y lealtad, junto con una amplia base de conocimientos y sólidas competencias de liderazgo que les permiten ser excelentes facilitadores y negociadores y saber cómo resolver conflictos. Los Scrum Masters también debe sostener su compromiso con el método Scrum, independientemente de la presión que reciban de otras fuentes.
Para desempeñarse continuamente con un alto nivel, los Scrum Masters deben abordar varias responsabilidades y poseer varios rasgos personales, como se exhibe en la lista detallada a continuación.
- Cumple con el rol de líder servidor: un verdadero líder servidor sabe que el enfoque debe centrarse en asegurarse de que el equipo tenga aquello que necesita para entregar resultados al cliente de una manera que cumpla con los objetivos comerciales de la empresa. En este sentido, el Scrum Master sirve a varias entidades en simultáneo: los miembros del equipo, el cliente y la empresa. Según la Guía de Scrum, el rol del Scrum Master implica responsabilidades específicas en el servicio al propietario del producto, el equipo de desarrollo y la organización. El Scrum Master lidera con el ejemplo y es la clase de persona a quien el resto del equipo quiere seguir. Un Scrum Master inspirador anima a los demás a creer en sus capacidades y trabajar en su potencial, incluso cuando las cosas no salen según lo planeado.
- Acepta la responsabilidad sin sentirse con derecho a la autoridad: en su entrada de blog titulada "Leader of the Band", Cohn explica la expectativa de tener responsabilidad sin poder: "Si bien el Scrum Master no asume la responsabilidad sobre el éxito del proyecto (eso corresponde al equipo), asume la responsabilidad de la adopción del método Scrum y su práctica por parte del equipo. El Scrum Master emprende esta responsabilidad sin asumir el poder que podría resultar útil para lograrlo".
En otra publicación, "Advice for Interviewing Scrum Masters", Cohn aclaró la expectativa al sostener lo siguiente: "Un director de orquesta una vez explicó que no tiene poder real sobre cómo tocan los músicos individuales. Sin embargo, siente una enorme responsabilidad de ayudarlos a ser los mejores músicos posibles".
- Resuelve impedimentos y, si es posible, los impide: para proteger el trabajo del equipo de desarrollo, el Scrum Master resuelve o elimina los impedimentos siempre que sea posible. A menudo, los miembros del equipo le avisan al Scrum Master sobre un impedimento durante el scrum diario, y explican por qué el impedimento podría interferir en su capacidad para completar el trabajo durante un sprint.
En las publicaciones de empleo recientes, los gerentes de contratación han mostrado una preferencia por aquellos Scrum Masters que tienen un amplio conocimiento técnico o comprenden por completo los detalles de un sector en particular. Los Scrum Masters que tienen este tipo de conocimientos cuentan con la ventaja de poder ayudar a sus equipos a abordar los impedimentos sobre problemas técnicos con mayor rapidez.
Algunos impedimentos subyacentes constituyen amenazas a la efectividad general del equipo, por lo que es muy deseable contratar a un Scrum Master observador y comprometido que pueda eliminar tales amenazas. Cuanta más experiencia tenga un Scrum Master, más fácil le será reconocer un problema potencial y resolverlo antes de que se convierta en un problema.
- Asesora al equipo sobre cómo mejorar: los Scrum Masters asesoran a sus equipos mediante ejemplos basados en sus conocimientos y experiencias, y los guían para que aprovechen su potencial al máximo. Al hacerlo, ayudan a los miembros del equipo a entenderse mejor, e implementan prácticas que involucren la autoorganización y la funcionalidad cruzada. Cuando los Scrum Masters fomentan el poder de la autoorganización, los equipos aumentan la responsabilidad sobre su trabajo, les resulta más fácil tomar decisiones y realizar cálculos aproximados del trabajo, y tienen un sentimiento más fuerte por lograr un propósito común.
Cohn compara el asesoramiento del Scrum Master con el tipo de asistencia que ofrecen los entrenadores personales. "La ayuda de un Scrum Master es parecida a la de un entrenador personal, quien ayuda a cumplir con un régimen de ejercicios y realizar todos los ejercicios de la forma apropiada. Un buen entrenador le proporcionará motivación y, al mismo tiempo, se asegurará de que no haga trampa y omita un ejercicio difícil. Sin embargo, la autoridad del entrenador es limitada. El entrenador no puede obligarlo a hacer un ejercicio que no quiera hacer. En cambio, le recuerda sus objetivos y cómo decidió alcanzarlos".
- Reconoce y resuelve conflictos lo antes posible: todos los miembros de un equipo de Scrum tienen libertad para abordar actitudes improductivas y comportamientos disfuncionales. Sin embargo, a veces, el conflicto surge a partir de malentendidos o la necesidad de llegar a un acuerdo. En estos casos, los Scrum Masters deben reconocer el conflicto en el equipo con antelación suficiente para resolverlo antes de que sea necesario realizar mucho control de daños. Los Scrum Masters también reconocen que cierto grado de conflicto es inevitable y no siempre es algo malo. En última instancia, la capacidad para superar conflictos hará que el equipo sea más fuerte.
En su entrada de blog "Advice for Interviewing Scrum Masters", Cohn analiza de qué manera la mentalidad colaborativa que los Scrum Masters aportan al trabajo contribuye a resolver conflictos. "Un buen Scrum Master trabaja para garantizar que exista una cultura de colaboración dentro del equipo. El Scrum Master debe asegurarse de que los miembros del equipo se sientan capaces de plantear problemas en un clima de debate abierto. Cuando surgen disputas, los Scrum Masters colaborativos animan a los equipos a pensar en soluciones que beneficien a todos los involucrados, y no en términos de ganadores y perdedores".
- Facilita los eventos de Scrum: los mejores Scrum Masters parecen saber instintivamente cómo facilitar los eventos y guiar a las personas. En realidad, la mayoría de los Scrum Masters reciben este tipo de capacitación a partir de cursos de liderazgo o años de experiencia. Las personas que asisten a sus eventos de Scrum aprecian su preparación y la capacidad de establecer expectativas claras.
- Escucha y observa: una vez más, el equilibrio es crucial. Los Scrum Masters efectivos tienen competencias de comunicación excepcionales, pero también saben cuándo simplemente escuchar y observar. Con escuchar, nos referimos a una escucha atenta y activa. Con observar, nos referimos a la observación de aquello que no se comunica en voz alta, pero resulta evidente al prestar atención al lenguaje corporal, las expresiones faciales y otras señales.
- Actúa como educador y promotor de Scrum: los Scrum Masters no solo garantizan que los miembros del equipo de Scrum entiendan y sigan el método Scrum, sino que también se aseguran de que otros empleados vinculados a sus equipos entiendan Scrum. Si las organizaciones adoptan Scrum por primera vez, los Scrum Masters son quienes liderarán esta iniciativa planificando la implementación de Scrum, sugiriendo cambios para aumentar la productividad del equipo de Scrum y brindando asistencia durante el período de ajuste. En las grandes empresas, tal iniciativa a veces conlleva trabajar con otros Scrum Masters para aumentar la efectividad de Scrum.
Mientras capacita a otras personas sobre Scrum, es posible que los Scrum Masters necesiten superar el escepticismo colectivo mediante la promoción del valor de Scrum y la explicación de cómo su marco de trabajo y sus principios guía ya generaron resultados significativos en otras empresas.
- Utiliza las competencias políticas corporativas para influir en las personas de toda la organización: los Scrum Masters experimentados saben que podrían llegar a modificar el comportamiento de las personas al darles una razón para cambiar sus acciones, o bien influir en las personas mediante un cambio en la cultura y las condiciones de trabajo, aunque en realidad no pueden transformar a las personas. Dichos Scrum Masters también saben cómo recurrir a la persuasión y la motivación para influir a otros en distintos niveles de una organización porque entienden quién toma las grandes decisiones, cómo pueden capitalizar las alianzas existentes, y cómo tomar desvíos en torno a las personas más propensas a obstaculizar su camino.
Roles del equipo de desarrollo
Las personas que crean el producto se conocen de forma colectiva como el equipo de desarrollo. Este grupo suele incluir a profesionales con experiencia y capacitación como desarrolladores de software, diseñadores de interfaz del usuario, especialistas en bases de datos, ingenieros de operaciones, ingenieros de aseguramiento de la calidad, evaluadores, analistas de sistemas y redactores técnicos (especialistas en documentación). Según la Guía de Scrum, "Scrum no reconoce ningún título para los miembros del equipo de desarrollo más allá de desarrollador, independientemente del trabajo que realice la persona. No hay excepciones a esta regla".
La función principal del equipo de desarrollo es realizar el trabajo necesario para concretar con éxito una serie de sprints e incrementos del producto, seguidos por la entrega de un producto final de alta calidad. Si tiene planeado contratar a alguien para su equipo de desarrollo de Scrum, Schnase sugiere buscar un profesional que esté dispuesto a proporcionar asistencia en las pruebas y realizar otras funciones, como la automatización. "Todos los miembros del equipo deben estar dispuestos a capacitarse y ayudarse mutuamente".
"The Basics of Scrum", publicado por Scrum Inc., también aborda la importancia de contar con un equipo de desarrollo multifuncional. "Además, debe haber al menos dos personas en el equipo que puedan completar cualquier elemento del trabajo pendiente del producto. Esta dinámica contribuye a eliminar la dependencia sobre las competencias de un miembro específico del equipo en caso de que dicha persona se enferme, se tome vacaciones o cambie de trabajo".
En la siguiente lista, se incluyen las responsabilidades compartidas por el equipo de desarrollo, junto con rasgos deseables para alcanzar un desempeño óptimo.
- Ofrece la funcionalidad y el nivel de calidad prometidos: los empleados más adecuados para el trabajo en equipo de Scrum son colaboradores y comunicadores que mejoran constantemente cuanto más tiempo permanecen con un equipo, y son capaces de implementar funciones según lo planificado y entregar un trabajo de alta calidad. A través de sus acciones, demuestran un sólido compromiso con los objetivos y la capacidad de prosperar en un entorno de Scrum.
- Realmente se preocupa por lanzar un producto final que los clientes apreciarán: los miembros del equipo más valiosos son quienes conocen bien a sus clientes y se sentirían decepcionados si no hicieran el esfuerzo necesario para superar las expectativas del cliente. Estos empleados se enorgullecen de su trabajo y se entusiasman cuando reciben comentarios positivos de los clientes.
- Ayuda al equipo a centrarse en la finalización: los equipos de desarrollo son responsables de todas las tareas del trabajo pendiente del sprint. Los equipos de alto rendimiento copian estas tareas a un tablero de Scrum y realizan actualizaciones de manera frecuente para asegurarse de que todos tengan una referencia visual de dónde se encuentran todas las tareas en tiempo real. Las columnas del tablero de Scrum deben indicar claramente qué tareas están finalizadas, y cuánto progreso se realizó en los elementos restantes. Los miembros del equipo que siguen estas pautas eliminarán la confusión y mantendrán al equipo enfocado en avanzar.
- Utiliza las reuniones diarias de Scrum y otras reuniones como herramientas de comunicación: los miembros meticulosos del equipo saben que su tiempo es preciado y limitado, y tratan el tiempo de sus compañeros con el mismo respeto. Utilizan las reuniones diarias de Scrum y otras reuniones según fueron designadas, y se preparan para comunicarse dentro del tiempo estipulado. También se aseguran de que el resto de sus comunicaciones con los compañeros de trabajo sean concisas y vayan al grano.
- Asume compromisos realistas: los gerentes de tiempo efectivos se dan cuenta de que todas las personas necesitan cierta cantidad de tiempo de descanso en el día. Todos necesitamos tiempo para relajarnos y recargarnos, especialmente si queremos fomentar la creatividad. Por este motivo, se necesita cierta holgura en nuestros cronogramas para dar lugar a tales procesos, así como para planificar adecuadamente situaciones inesperadas y emergencias. Los desarrolladores con experiencia están al tanto de este fenómeno y estiman los plazos de sus compromisos teniendo en cuenta estos factores.
- Proporciona ideas para sprints futuros: todos aprecian a un miembro del equipo que toma la iniciativa de proporcionar opciones funcionales para los elementos no abordados que identifican en el trabajo pendiente del producto. Si bien el trabajo pendiente del producto forma parte de la lista de responsabilidades del propietario del producto, ofrecer ideas sobre cómo refinar su contenido es algo que todo el equipo puede hacer. Mejorar los elementos del trabajo pendiente del producto inevitablemente mejora los incrementos del producto y el producto final.
- Aprovecha oportunidades para la capacitación cruzada y el aprendizaje continuo: los miembros del equipo orientados hacia el crecimiento se entusiasman ante las oportunidades de aprendizaje avanzado porque entienden la importancia de la innovación, y se adaptan constantemente a un entorno técnico en rápida evolución. Están abiertos al cambio, y dispuestos a capacitarse y participar en situaciones de colaboración. También demuestran voluntad para compartir sus experiencias con otros empleados y servir como mentores de los nuevos miembros del equipo.
- Combina la experiencia técnica con el conocimiento comercial: los miembros del equipo de desarrollo que entienden los conceptos comerciales casi tanto como la tecnología son valiosos en varios aspectos. No solo pueden explicar la tecnología al personal comercial, sino que también pueden proporcionar información sobre las consecuencias de lanzar un producto que se centre demasiado en el marketing en lugar de los factores técnicos subyacentes.
Por ejemplo, si la incorporación de demasiadas funciones sobreexige el rendimiento general del producto, los desarrolladores informarán al propietario del producto sobre tales inquietudes lo antes posible. Estos desarrolladores son muy valiosos porque pueden explicar sus preocupaciones en términos comerciales que el propietario del producto comprenderá, indicar que están dispuestos a trabajar en posibles soluciones, y mostrar que conocen cómo determinados aspectos técnicos, como el rendimiento, pueden afectar el valor de mercado de un producto.
- Aplica una política de no interferencia para el equipo: otras personas en una empresa pueden sentirse tentadas a imponer sus propias exigencias a un equipo de desarrollo, motivo por el cual probablemente la Guía de Scrum consideró necesario incluir un apartado donde se abordara esta tendencia: "Nadie puede ordenar al equipo de desarrollo que trabaje a partir de un conjunto diferente de requisitos. A su vez, el equipo de desarrollo tiene prohibido actuar conforme a órdenes ajenas".
Consejos generales de contratación para todos los roles del equipo de Scrum
Ahora que hemos cubierto la información específica, revisemos una lista general de cualidades que los expertos de Scrum dicen que buscarían en sus compañeros miembros del equipo.
- Admite errores y aprende de ellos: si bien todos cometemos errores, es importante que los empleados aprendan de estos errores y mejoren como resultado. Antes de contratar o invitar a alguien para que se una a su equipo de Scrum, aprenda a reconocer qué candidatos no admitirán que cometen errores, lo que podría ser un indicador de rasgos más problemáticos, como no aceptar la responsabilidad. Los equipos colaboran en innumerables detalles, por lo que es fundamental que incorpore un candidato que pueda hacer una transición fluida a un rol de equipo sin demostrar una tendencia para evadir la responsabilidad.
- Valora los comentarios: los miembros del equipo conscientes saben cómo dar y recibir comentarios de una manera clara, directa y respetuosa. También saben que los comentarios deben ser útiles y edificantes. Siempre que sea posible, estos miembros del equipo buscarán formas de proporcionar sus comentarios en privado. La confianza también forma una parte importante de la ecuación. Los compañeros de equipo que confían mutuamente trabajan mejor juntos. Evaluar adecuadamente cómo se sienten los candidatos sobre los comentarios y la confianza revela mucho sobre su carácter.
- Aporta humor, energía y diversión al trabajo: formar parte de un equipo y sentir una conexión con los demás requiere el aporte personal de todos. Los empleados que muestran su personalidad a través del humor, la energía y las actividades divertidas suelen conectarse con los demás más rápido. No siempre resulta fácil evaluar estas cualidades durante las entrevistas de trabajo, pero formular preguntas generales sobre sus intereses y pasatiempos favoritos, viajes y actividades de fin de semana puede revelar algunas pistas sobre cuán bien encajaría el candidato en un equipo de Scrum en particular.
Herramientas propias para Scrum
La responsabilidad colectiva es una parte importante de Scrum. Para mejorar como equipo, vale la pena realizar un seguimiento del rendimiento y el progreso mediante diversas herramientas.
- Tablero de Scrum: existen varios tipos de tableros de tareas, pero el modelo más común utilizado en Scrum es el tablero de Scrum mencionado anteriormente en este artículo. Como ya dijimos, el tablero de Scrum incluye columnas generalmente etiquetadas como Pendiente, Trabajo en curso (WIP) y Listo. Cada una de las tareas del trabajo pendiente del sprint se escribe en notas adhesivas, y se coloca dentro de una de estas columnas para ayudar al equipo de Scrum a determinar cuánto trabajo aún debe completarse antes del final del sprint.
Los tableros de Scrum también se pueden usar para realizar un seguimiento de la producción del equipo mediante una métrica conocida como velocidad. Para medir la velocidad, el equipo asigna un valor de punto relativo a cada tarea del trabajo pendiente del sprint. Cuando se finaliza el sprint, el equipo puede agregar puntos en la columna de Listo, y calcular la velocidad total del equipo en ese sprint en particular. El uso de este método ayuda a los equipos a crear una línea de base para el rendimiento del equipo, y predecir cuánto trabajo puede abordar en sprints futuros.
Los equipos también pueden usar la velocidad y los tableros de Scrum para pronosticar la fecha de finalización de un proyecto, o bien analizar si un ajuste en el flujo de trabajo ayudó realmente al equipo a mejorar su tasa de rendimiento. Para obtener más información, consulte los cursos sobre tableros de Scrum en Scrum Inc.
- Diagrama de quemado: durante un sprint, es posible que los equipos quieran usar un diagrama de quemado de sprint diario para mostrar la cantidad de trabajo restante en el trabajo pendiente del sprint. El trabajo restante se registra en el eje vertical, mientras que el tiempo (según los días en un sprint) se registra en el eje horizontal. Este tipo de representación visual puede ayudar a los equipos a medir el progreso y asegurarse de que estén encaminados para cumplir con la fecha de finalización esperada. A su vez, los gráficos de quemado pueden ser útiles para dar seguimiento a las tendencias y trabajar durante el cronograma de lanzamiento de un producto. Para obtener más información sobre cómo crear un diagrama de quemado, consulte los cursos sobre diagramas de quemado de sprint en Scrum Inc.
- Matriz RACI: como todos los equipos saben, a veces es necesaria la rendición de cuentas individual. En estos casos, resulta útil contar con una herramienta como la matriz RACI (responsable, aprobador, consultado, informado) para dividir las tareas y las entregas en un diagrama organizado de funciones y responsabilidades. Para obtener más información sobre esta herramienta, consulte "Guía integral de gestión de proyectos sobre todo aquello vinculado a la matriz RACI".
Utilice Smartsheet para gestionar fácilmente proyectos de Scrum
De la administración básica de tareas y de proyectos hasta la administración compleja de recursos y portafolios, Smartsheet lo ayuda a mejorar la colaboración y acelerar el trabajo. Esto lo empodera para lograr más. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas clave y obtenga visibilidad en tiempo real acerca de trabajo gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en menos tiempo. Pruebe Smartsheet gratis hoy mismo.