Organización del marco Scrum
- mateosolorzanov
- 5 oct 2024
- 11 Min. de lectura
3.1 Introducción
La organización en Scrum es aplicable a proyectos de cualquier tamaño o industria. Esta sección aborda la estructura organizacional de un proyecto Scrum, incluyendo los roles principales y no principales. También se discute la formación de equipos Scrum de alto rendimiento y cómo el marco de trabajo puede ser utilizado en diversas áreas, desde productos hasta servicios. El término "producto" hace referencia a un producto, servicio o cualquier otro entregable.
3.2 Guía de roles
Esta sección establece qué partes del capítulo deben ser leídas por los diferentes roles. El Product Owner debe revisar todo el capítulo, mientras que el Scrum Master y el Equipo Scrum tienen partes específicas en las que enfocarse, como los roles principales y no principales, así como la gestión de responsabilidades dentro del equipo.
3.3 Roles en un proyecto Scrum
Los roles Scrum se dividen en dos categorías:
Roles principales: Los roles principales (core roles) son aquellos que se requieren obligadamente para crear el producto del proyecto, están comprometidos con el proyecto, y por último son los responsables del éxito de cada sprint del proyecto y del proyecto en su totalidad.
Roles secundarios: Los roles secundarios (non-core roles) no son necesariamente obligatorios para el proyecto Scrum, y pueden incluir miembros de los equipos que tengan interés en el proyecto, pero que no tienen ninguna función formal en el equipo del proyecto.
Roles en Scrum
3.3.1 Roles principales
Son responsables de cumplir con los objetivos del proyecto, son tres roles que conforman el equipo principal de Scrum, además de estos tres roles, ningún rol tiene autoridad sobre los demás.
Product Owner: Persona responsable de maximizar el valor del negocio en el proyecto. Este rol es responsable de articular los requisitos del cliente y de mantener la justificación del negocio del proyecto. El Product Owner representa la voz del cliente.
Scrum Master: Es un facilitador que asegura que el Equipo Scrum esté dotado de un ambiente propicio para completar con éxito el desarrollo del producto. El Scrum Master guía, facilita y enseña las prácticas de Scrum a todos los participantes en el proyecto; elimina los impedimentos que enfrenta el equipo y se asegura de que se estén siguiendo los procesos de Scrum.
Cualquier persona del Equipo Scrum que aprenda a facilitar proyectos Scrum puede convertirse en el Scrum Master de un proyecto o sprint.
Equipo Scrum: Es un grupo o equipo de personas responsables de entender los requerimientos del negocio especificados por el Product Owner, de estimar las historias de usuarios y de la creación final de los entregables del proyecto.
Equipo principal de Scrum
3.3.2 Roles secundarios
Los roles secundarios no son obligatorios para el proyecto Scrum y pueden no participar en el proceso de Scrum. Podrían desempeñar un rol importante en algunos proyectos de Scrum.
Interesados del negocio: Interesados del negocio (business stakeholders) es un término colectivo que incluye a clientes, usuarios y patrocinadores que generalmente interactúan con el Product Owner, el Scrum Master y el Equipo Scrum para proporcionarles información y facilitar la creación del producto del proyecto, servicio, o cualquier otro resultado. La definición de los roles de los interesados es:
Cliente: El cliente es la persona o la organización que adquiere el producto, servicio o cualquier otro resultado del proyecto.
Usuarios: Es el individuo o la organización que utiliza directamente el producto, servicio o cualquier otro resultado del proyecto. Al igual que los clientes, para cualquier organización, puede haber usuarios internos y externos.
Patrocinador: El patrocinador es la persona o la organización que provee recursos y apoyo para el proyecto, le deben rendir cuentas al final.
Servicios de apoyo: Grupos internos y externos que apoyan o se vean afectados por el proyecto de Scrum. Por ejemplo: capacitación, logística, publicidad, finanzas, infraestructura, etc.
Proveedores: Personas u organizaciones externas que ofrecen productos y servicios que no están dentro de las competencias básicas de la organización del proyecto.
Scrum Guidance Body: Rol opcional, se compone de un grupo de documentos o un grupo de expertos que normalmente están involucrados en definir los objetivos relacionados a la calidad, regulaciones gubernamentales, etc., los cuales guían el trabajo que lleva a cabo el Equipo Scrum.
3.4 Product Owner
Representa los intereses de la comunidad de interesados del negocio para el Equipo Scrum, es el responsable de asegurar una comunicación clara sobre el producto y los requisitos de funcionalidad del servicio con el Equipo Scrum, definir los criterios de aceptación y asegurar que se cumplan dichos criterios.
Las responsabilidades del Product Owner en los procesos de Scrum son:
Responsabilidades del Product Owner
El Product Owner no siempre representa a un negocio o cliente externo, también puede ser un arquitecto técnico, Líder técnico, etc.
3.4.1 La voz del cliente
Como representante del cliente y de otros interesados del negocio, al Product Owner se le conoce como “la voz del cliente”, ya que asegura de que las necesidades explícitas e implícitas del cliente se reflejen en las historias de usuario en el backlog priorizado del producto y que más adelante se utilicen para crear los entregables del proyecto para el cliente.
Características del Product Owner
3.5 Scrum Master
Es el “líder de apoyo” del Equipo Scrum que modera y facilita las interacciones del equipo como su coach y motivador. Este rol es responsable de asegurar que el equipo tenga un ambiente de trabajo productivo protegiéndolo de influencias externas, eliminando todos los obstáculos y haciendo que se cumplan los principios, aspectos y procesos de Scrum.
Las responsabilidades del Scrum Master en los procesos de Scrum son:
Responsabilidades del Scrum Master
3.6 Equipo Scrum
En ocasiones se le conoce como equipo de desarrollo, ya que es responsable del desarrollo del producto, servicio o de cualquier otro resultado. Consiste en un grupo de personas autoorganizadas que trabajan en las historias de usuario en el backlog del sprint para crear los entregables del proyecto.
Las responsabilidades del Equipo Scrum en los procesos de Scrum son:
Responsabilidades del Equipo Scrum
3.6.1 Selección de personal
Las características que deben tener los roles principales de Scrum son:
Características del rol principal de Scrum
3.6.2 Tamaño del Equipo Scrum
El tamaño óptimo de un Equipo Scrum es de seis a diez miembros, lo suficientemente grande para asegurar habilidades adecuadas, pero lo suficientemente pequeño como para
facilitar la colaboración.
3.7 Scrum en proyectos, programas y portafolios
3.7.1 El funcionamiento de Scrum en un proyecto grande
La definición de lo que constituye un proyecto grande generalmente depende de la organización o de la complejidad de los proyectos emprendidos. Un criterio clave para saber si un proyecto se considera pequeño en vez de grande es si requiere de múltiples Scrum Masters o múltiples Product Owners.
Algunos de los motivos tras la necesidad de utilizar entradas, herramientas y salidas adicionales para grandes proyectos son:
Product Owners: La necesidad de colaborar entre Product Owners al trabajar con interesados del negocio; al refinar el backlog priorizado del producto y al trabajar con múltiples Equipo Scrum.
Scrum Masters: La necesidad de colaboración entre Scrum Masters al atender impedimentos y sincronizar el trabajo de múltiples Equipo Scrum.
Equipos Scrum:
Mayor interacción y dependencias entre los equipos Scrum, ya que la complejidad aumenta en los grandes proyectos.
La necesidad de gestionar conflictos, resolver problemas y establecer prioridades entre los equipos Scrum.
La necesidad de establecer un ambiente o área de trabajo en un proyecto grande que después utilizarán todos los equipos Scrum.; etc.
3.7.2 Roles principales adicionales en proyectos grandes
3.7.2.1 Chief Product Owner
Esta persona o rol es el Chief Product Owner. Este rol es responsable de coordinar el trabajo de múltiples Product Owners. Con la ayuda de los Product Owners, el Chief Product Owner prepara y mantiene el backlog priorizado del producto en general para el proyecto grande utilizándolo para coordinar el trabajo a través de los Product Owners de los equipos Scrum. El Chief Product Owner será el responsable del entregable final del proyecto.
3.7.2.2 Chief Scrum Master
Los grandes proyectos requieren que varios equipos Scrum trabajen en paralelo. La información obtenida de un equipo pudiera ser comunicada apropiadamente a otros equipos. El Chief Scrum Master es responsable de dicha actividad. El rol de un Chief Scrum Master es necesario para garantizar una colaboración apropiada entre los equipos Scrum. La coordinación entre los varios equipos Scrum que trabajan en un proyecto generalmente se da mediante la reunión de Scrum de Scrums.
Algunas preguntas que se hace en la reunión de Scrum de Scrum son:
Preguntas en una reunión de Scrum de Scrums
3.7.3 El funcionamiento de Scrum en una empresa
Para aplicar las prácticas de Scrum en proyectos que forman parte de un modelo empresarial es necesario entender la configuración y la forma de gobierno de la empresa. Esto se maneja por medio de programas y portafolios.
Programa: Grupo de proyectos relacionados con la finalidad de entregar resultados de negocio definidos en la declaración de la visión del programa.
Portafolio: Grupo de programas o proyectos relacionados con la finalidad de entregar resultados de negocio tal como se define en la declaración de la visión del portafolio.
3.7.4 Roles principales adicionales en una empresa
3.7.4.1 Program Product Owner
Define los objetivos estratégicos y las prioridades del programa. Es responsable de maximizar el valor de negocio en un programa articulando claramente de los requisitos del cliente y manteniendo la justificación del negocio en el programa. El Program Product Owner también gestiona el Backlog del Producto del Programa. Es responsable de impulsar la creación y refinamiento de los entregables al nivel del programa y requiere la coordinación entre los proyectos subyacentes en el programa.
3.7.4.2 Portfolio Product Owner
Toma las decisiones a nivel de portafolio. Tiene una mejor perspectiva para decidir cómo organizar la empresa para cumplir con la visión. El Portfolio Product Owner es responsable de la creación y refinación del Backlog del Producto del Portafolio.
3.7.4.3 Program Scrum Master
Facilitador que se asegura de que todos los equipos del proyecto cuenten con un ambiente adecuado para concluir con éxito sus proyectos. El Program Scrum Master guía, organiza y enseña las prácticas de Scrum a todos los involucrados en el programa; brinda orientación a los Scrum Masters de proyectos individuales; elimina impedimentos que enfrenten los distintos equipos del proyecto, etc.
3.7.4.4 Portfolio Scrum Master
El rol del Portfolio Scrum Master es similar al rol del Scrum Master, a diferencia de que busca cumplir las necesidades del portafolio o de la unidad de negocios en vez de las necesidades de un solo Equipo Scrum.
Información de los roles adicionales en una empresa
3.7.5 Ejemplos de proyectos, programas y portafolios
Ejemplos de proyectos, programas y portafolios en diferentes industrias y sectores:
Ejemplos de proyectos, programas y portafolios
La forma en la que Scrum se puede utilizar para portafolios, programas o proyectos en la organización son:
Definición de proyectos, programas y portafolios
3.8 Resumen de responsabilidades
Las responsabilidades pertinentes en la organización son:
Resumen de las responsabilidades de una organización
3.9 Scrum vs. Gestión tradicional de proyectos
Se comparan las diferencias entre Scrum y los métodos tradicionales de gestión de proyectos. En Scrum, la estructura es más horizontal y se fomenta la autoorganización, mientras que, en la gestión tradicional, la estructura es jerárquica, con la autoridad delegada desde la alta dirección hasta los miembros del equipo.
3.10 Teorías populares de recursos humanos y su relevancia en Scrum
3.10.1 Modelo de dinámica de grupo de Tuckman
Un nuevo Equipo Scrum se desarrolla, por lo general, a través de un proceso de cuatro etapas durante su primer proyecto de Scrum. Este proceso se conoce como Modelo de dinámica de grupo de Tuckman. La idea principal es que las cuatro etapas: formación, enfrentamiento, normalización y desempeño, son imprescindibles para que un equipo se desarrolle y mitigue los problemas y desafíos, encuentre soluciones, planifique el trabajo y entregue resultados.
Las cuatro etapas del modelo son las siguientes:
Formación: Generalmente es una etapa divertida, ya que todo es nuevo y el equipo aún no ha encontrado ninguna dificultad con el proyecto.
Enfrentamiento: Durante esta etapa, el equipo trata de cumplir con el trabajo; sin embargo, puede encontrar conflictos de poder y, con frecuencia, existe un caos o confusión entre los miembros del equipo.
Normalización: Es cuando el equipo empieza a madurar, a resolver sus diferencias internas, y a encontrar soluciones para trabajar juntos. Se considera un período de ajuste.
Desempeño: Durante esta etapa, el equipo está unido y opera en su nivel más alto en términos de rendimiento. Los miembros se han convertido en un equipo eficiente de profesionales consistentemente productivos.
Etapas del modelo de dinámica de grupo de Tuckman
3.10.2 Gestión de conflictos
Las organizaciones que aplican el marco de trabajo de Scrum fomentan un ambiente abierto y el diálogo entre los empleados. Los conflictos entre los integrantes del Equipo Scrum generalmente se resuelven en forma independiente, con poca o ninguna participación de la gerencia o de personas ajenas al equipo.
3.10.3 Técnicas de gestión de conflictos
Hay generalmente cuatro métodos para gestionar conflictos en una organización que aplica los procesos de Scrum:
Ganar-Ganar
Perder-Ganar
Perder-Perder
Ganar-Perder
3.10.3.1 Ganar-Ganar
Las organizaciones que implementan Scrum deben promover un ambiente donde los empleados se sientan cómodos para dialogar y enfrentarse a los problemas y atenderlos para lograr resultados de ganar-ganar.
3.10.3.2 Perder-Ganar
Algunos miembros del equipo a veces pueden sentir que sus aportaciones no son reconocidas ni valoradas por los demás, o que no se les trata igual. Esto puede conducir a que no contribuyan de manera efectiva al proyecto y a que estén de acuerdo con todo lo que se les pida, incluso si están en desacuerdo. Este enfoque se llama perder-ganar.
3.10.3.3 Perder-Perder
Los miembros del equipo pueden intentar negociar o buscar soluciones que aporten solo un grado parcial o medida temporal de satisfacción a las partes en una disputa. Esta situación podría presentarse en equipos Scrum si los integrantes intentan negociar soluciones sub-óptimas para resolver un problema. Este enfoque suele implicar un poco de “dar para recibir” a fin de satisfacer a cada miembro del equipo, en vez de intentar resolver el verdadero problema.
3.10.3.4 Ganar-Perder
Un Scrum Master u otro miembro influyente del equipo, pueden creer ser un líder de facto o manager y tratar de imponer su punto de vista sin tomar en cuenta los puntos de vista de los demás. Esta técnica de gestión de conflictos a menudo se caracteriza por la competitividad y por lo general resulta en ganar perder.
Definición de las técnicas de gestión de conflictos
3.10.4 Estilos de liderazgo
Los estilos de liderazgo varían dependiendo de la organización, la situación, e incluso en los individuos y los objetivos específicos del proyecto Scrum. Algunos estilos de liderazgo comunes son los siguientes:
Líder de apoyo: Los líderes saben escuchar, tienen empatía, compromiso y conocimiento, y comparten el poder y la autoridad con los miembros del equipo.
Líder que delega: Los líderes que delegan están involucrados en la mayoría de la toma de decisiones; sin embargo, delegan parte de las responsabilidades de planificación y decisiones a los miembros del equipo, particularmente si son competentes para manejar las tareas asignadas.
Líder autocrático: Los líderes autocráticos toman decisiones por su cuenta, dándoles poco o nada de tiempo a los miembros del equipo antes de tomar una decisión.
Líder directivo: Los líderes directivos instruyen a los miembros del equipo sobre las tareas que se requieren y sobre cómo y cuándo deben llevarse a cabo.
Líder Laissez Faire: Es un estilo de liderazgo en el que el equipo se queda sin supervisión y donde el líder no interfiere con las actividades laborales diarias.; etc.
3.10.4.1 Liderazgo de apoyo
El estilo de liderazgo preferido en los proyectos Scrum es el liderazgo de apoyo. Larry Spears identifica diez rasgos que debe tener cada líder eficaz:
Escucha: Se busca que los líderes escuchen con atención y sean receptivos a lo que se dice o no se dice. Estos son capaces de ponerse en contacto con su voz interior para comprender y reflexionar sobre sus propios sentimientos.
Empatía: Los buenos líderes buenos aceptan y reconocen a los individuos por sus destrezas únicas y habilidades especiales. Asumen que los trabajadores tienen buenas intenciones y los aceptan como individuos, incluso cuando existen problemas de comportamiento o rendimiento.
Resiliencia: La motivación y la capacidad de recuperarse a sí mismo y la relación con los demás es un fuerte rasgo de los líderes. Reconocen y se dan la oportunidad de ayudar a sus colegas que están pasando por dolor emocional; etc.
Caracteristicas de un lider
3.10.5 Teoría de jerarquía de necesidades de Maslow
Maslow (1943) presenta una jerarquía de necesidades la cual reconoce que diferentes personas se encuentran en diferentes niveles en sus necesidades. Por lo general, la gente se preocupa de las necesidades fisiológicas y después se desplaza progresivamente hacia las necesidades jerárquicas. La siguiente figura representa la jerarquía de necesidades de Maslow.
Jerarquía de necesidades de Maslow
Para lograr el éxito, un Equipo Scrum necesita miembros principales y secundarios que hayan alcanzado los niveles de reconocimiento y autorrealización. El concepto de equipos autoorganizados, lo cual es un principio clave en Scrum, requiere que los miembros del equipo sean automotivados, que participen y contribuyan plenamente en el cumplimiento de los objetivos del proyecto.
3.10.6 Teoría X, Teoría Y, Teoría Z
Douglas McGregor (1960) propuso dos teorías de gestión:
Teoría X: En la Teoría X, los líderes asumen que los empleados están inherentemente desmotivados y evitarán el trabajo si es posible, lo cual justifica un estilo autoritario de gestión.
Teoría Y: En la Teoría Y, los líderes asumen que los empleados son auto motivados y buscan aceptar una mayor responsabilidad. La Teoría Y implica un estilo más participativo de gestión.
Abraham H. Maslow (1960) propuse la Teoría Z y William Ouchi (1980) presentó otra versión de la Teoría Z, que abunda sobre la Teoría X y la Teoría Y:
Teoría Z: En la versión de Maslow, los líderes de la Teoría Z suponen que los empleados pueden ser motivados aprovechando su deseo de trascender sin ignorar sus motivaciones relacionadas a la jerarquía de necesidades.
Definición de Teorías X, Y y Z
Comments