Pilares de Scrum

Scrum define 6 principios que son clave para el buen funcionamiento del Marco de Trabajo. Se puede asegurar que son las “reglas” que deben conocer y aplicar los miembros del Equipo Scrum para garantizar el correcto funcionamiento de este marco de trabajo.

dibujos

5.1 - Control empírico de procesos (1)

Scrum se basa en la teoría de control empírico de procesos o empirismo. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Scrum emplea un enfoque iterativo e incremental para optimizar la predictibilidad y el control del riesgo.

Los 3 pilares que soportan toda la implementación del control empírico de procesos son: transparencia, inspección y adaptación.

5.1.1 - Transparencia

Los aspectos significativos del proyecto deben ser visibles para las partes interesadas. La transparencia requiere que dichos aspectos sean definidos por un estándar común, de tal modo que los observadores compartan un entendimiento común de lo que se está viendo.

Por ejemplo:

Todos los participantes deben compartir un lenguaje común para referirse al proceso.
Aquellos que desempeñan el trabajo y aquellos que aceptan el producto de dicho trabajo deben compartir una definición común de “Terminado”.

5.1.1.1 - Transparencia de los Artefactos

Scrum se basa en la transparencia. Las decisiones para optimizar el valor y controlar el riesgo se toman basadas en el estado percibido de los artefactos. En la medida en que la transparencia sea completa, estas decisiones tienen unas bases sólidas. En la medida en que los artefactos no son completamente transparentes, estas decisiones pueden ser erróneas, el valor puede disminuir y el riesgo puede aumentar.

El Scrum Master debe trabajar con el Product Owner, el Equipo de Desarrollo y otras partes interesadas para entender si los artefactos son completamente transparentes. Hay prácticas para hacer frente a la falta de transparencia; el Scrum Master debe ayudar a todos a aplicar las prácticas más apropiadas si no hay una transparencia completa.

Un Scrum Master puede detectar la falta de transparencia inspeccionando los artefactos, reconociendo patrones, escuchando atentamente lo que se dice y detectando diferencias entre los resultados esperados y los reales.

La labor del Scrum Master es trabajar con el Equipo Scrum y la organización para mejorar la transparencia de los artefactos. Este trabajo usualmente incluye aprendizaje, convicción y cambio. La transparencia no ocurre de la noche a la mañana, sino que es un camino.

5.1.2 - Inspección

En los proyectos Scrum se deben inspeccionar frecuentemente los artefactos y el progreso hacia un objetivo, para detectar variaciones.

La inspección no debe ser tan frecuente como para que interfiera en el trabajo, las inspecciones son más beneficiosas cuando se realizan de forma diligente por inspectores expertos en el mismo lugar de trabajo (normalmente el Scrum Master).

5.1.3 - Adaptación

Si un inspector determina que uno o más aspectos de un proceso se desvían de límites aceptables, y que el producto resultante no será aceptable, el proceso o el material que está siendo procesado deben ser ajustados. Dicho ajuste debe realizarse cuanto antes para minimizar desviaciones mayores.

Scrum prescribe cuatro eventos formales, contenidos dentro del Sprint, para la inspección y adaptación, tal y como se describen en la sección Eventos de Scrum de esta guía:

Reunión de Planificación del Sprint.
Scrum Diario.
Revisión del Sprint.
Retrospectiva del Sprint.

5.2 – Autoorganización (2)

Para Scrum, El Equipo de Desarrollo debe ser autoorganizado, esto significa que son los miembros del equipo quienes eligen la mejor opción de llevar a cabo su trabajo sin ser dirigidos por personas externas al equipo.

A continuación, se listan las reglas que garantizan la autoorganización del Equipo:

El Equipo de Desarrollo es quien se autoasigna el trabajo a realizar en los diferentes Sprints, nadie, ni siquiera el Product Owner debe imponer el trabajo al Equipo.
El Equipo debe conocer muy bien sus límites de decisión para así poder tener mayor autonomía.
El Equipo debe tener espacios que le permitan realizar jornadas de investigación y capacitación.
El Equipo debe mantenerse motivado.

Para que un equipo pueda ser autoorganizado, se necesitan como mínimo los siguientes elementos:

Debe existir una meta formalmente definida y de conocimiento para el equipo, “si el equipo no tiene un rumbo definido, no sabrá a donde debe llegar y le será imposible autoorganizarse”.
El Equipo debe entender la visión del proyecto y por qué el proyecto aporta valor a la organización.
La transparencia y la inspección son fundamentales para un equipo autoorganizado.
Los integrantes del Equipo deben ser multifuncionales, además de estar actualizando sus conocimientos y habilidades de manera continua.

5.2.1 - Colaboración de equipo

La colaboración se da gracias a la constante comunicación que existe en los Equipos Scrum, tanto entre sus miembros como con las Partes interesadas del Proyecto, este concepto es parte integral del Manifiesto Ágil “La forma más eficiente y efectiva de transmitir información hacia y dentro del Equipo de Desarrollo es la conversación cara a cara”.

El Scrum Master es el rol responsable de garantizar una sana comunicación entre todas las partes interesadas del proyecto, en especial de su Equipo de Desarrollo.

Se debe considerar que, según la naturaleza del proyecto, las necesidades de la organización e incluso factores externos, determinan la ubicación de los miembros del Equipo. Es por esto que en Scrum los Equipos se clasifican en 2 categorías:

5.2.1.1 - Equipos Centralizados

Las características de un Equipo Centralizado son:

Los miembros del Equipo se encuentran en la misma ubicación, lo que les permite comunicarse con gran facilidad.
La resolución de problemas es prácticamente inmediata, ya que al estar ubicados en el mismo lugar es fácil realizar sesiones de diálogo.

5.2.1.2 - Equipos Distribuidos

Un Equipo Distribuido es aquel en el que sus miembros no se encuentran en una misma ubicación, por lo general está disperso debido a factores como:

La subcontratación (outsourcing – freelance).
Oficinas ubicadas en diferentes ubicaciones físicas.
Trabajo desde casa.
Etc.

Para garantizar la comunicación permanente en este tipo de equipos se hacen necesarias las siguientes herramientas:

Groupware.
Software Videollamadas o chat.
Software de gestión de proyectos ágiles.
Herramientas de software que simulan la funcionalidad de Scrum boards.

5.2.2 - Colaboración con el cliente

En los proyectos tradicionales, los clientes por lo general se mantenían a distancia y solo se involucraban al principio y al final del proyecto. En Scrum es altamente recomendable que el cliente participe de las revisiones del producto y brinde retroalimentación en todos los puntos de "inspección y adaptación". Esto minimiza el riesgo y le brinda más opciones al cliente y a las partes interesadas.

Por ejemplo, en otros Marcos Ágiles como XP, es obligatorio que el Cliente forme parte del equipo.

El cliente (o sus representantes) deberían trabajar junto al Product Owner para definir las historias de usuario y detallar dichas historias antes o durante las reuniones de planificación.

El cliente y las partes interesadas por lo general participan en la Reunión de Revisión de los Sprint y, dependiendo de la relación entre el cliente y el Product Owner, el Cliente incluso podría participar de algunas reuniones de Retrospectiva de los Sprint.

dibujo

5.2.3 - Equipos multifuncionales

dibujo

Los equipos multifuncionales (también llamadas células ágiles) tienen todas las competencias y habilidades necesarias para llevar a cabo el trabajo sin depender de otras personas que no formen parte del equipo.

Contrario a lo que piensa un equipo multifuncional, no se trata de que todos sus integrantes hagan de todo, se trata de que los integrantes adquieran conocimiento en distintas disciplinas (aplicables a los proyectos de la organización) y así puedan contribuir eficazmente con la colaboración.

La realidad es que incluso cuando un equipo sea experto técnico, siempre necesitarán capacitación adicional, así es que el Product Owner deberá decidir si aprobará el dinero y el tiempo para capacitarse o por el contrario serán los miembros del equipo quienes se encargarán del tema.

5.2.3.1 – Gestionar el conocimiento

Realizar este ejercicio permitirá identificar, recopilar, organizar, transferir y retener el conocimiento necesario para dar soporte a todo el personal en sus actividades laborales, para la toma de decisiones bien fundadas y para aumentar la productividad.

5.2.4 - Propiedad colectiva del producto

Para garantizar una colaboración constante y evitar con el tiempo la aparición de una cultura de la culpa, es importante fomentar una propiedad colectiva del producto, esto significa que todo el Equipo Scrum es dueño del producto, y por tanto cualquiera de sus integrantes podría contribuir al desarrollo de cualquier parte del producto aun cuando no haya sido quien lo desarrolló inicialmente.

Así mismo no deberían existir reconocimientos individuales a los miembros del equipo por sus contribuciones al producto.

5.2.5 – Motivación del equipo

Los equipos Scrum se caracterizan por mantener un enfoque hacia la entrega frecuente de resultados; y aunque los miembros del equipo son conscientes de la responsabilidad que esto implica, existe un factor de fondo que facilita el impulso y el esfuerzo para cumplir con los objetivos; la motivación.

La motivación hace referencia a que los miembros del equipo mantengan determinada conducta y estado de ánimo que propicien las interacciones sanas y el alto rendimiento en el proyecto.

Tipos de motivación

Intrínseca: este tipo de motivación es propio de cada persona, es decir que por su propia voluntad e inspiración es capaz de mantener una conducta específica y el impulso necesario para cumplir con una meta que brinda satisfacción interna y realización personal. (Ref: CHAMPFROGS – Moving Motivators)
Extrínseca: este tipo de motivación hace referencia a mantener una conducta específica para responder a un impulso externo, es decir que en este caso la voluntad e inspiración de la persona se ven influenciadas por una recompensa externa (que puede ser algo físico, monetario o psicológico).

Según cómo se maneje la motivación en el equipo Scrum, eventualmente la motivación extrínseca tiende a convertirse en motivación intrínseca, pues los miembros del equipo van adaptando su conducta y mejorando su rendimiento para cumplir los objetivos sin necesidad de que todo el tiempo estén recibiendo recompensas o algo a cambio.

Identificar los motivadores

Cuando hablamos de motivación, es el Scrum Master quien tendrá la mayor participación y responsabilidad pues al estar al servicio del equipo Scrum puede identificar fácilmente qué es lo que aumenta o disminuye la motivación de los miembros del equipo; es por esto que dentro de las tareas del Scrum Master se incluye la identificación y análisis de los elementos motivadores del equipo para construir y desarrollar un Plan de Motivación que posteriormente negociará con el Product Owner para asegurar los recursos necesarios para su ejecución.

Incentivar la investigación

Dentro del conjunto de factores que aumentan la motivación del equipo en Scrum se recomienda impulsar la investigación de nuevos productos o tecnologías lo cual favorece que los miembros del equipo adquieran nuevo conocimiento y se inclinen hacia el logro de nuevos objetivos.

La investigación también propiciará que los miembros del equipo se propongan metas basadas en la autorrealización y desarrollo de sus propias competencias.

Algunas metodologías en el mercado hablan de las técnicas que pueden incentivar la investigación en los equipos, tales como: DemoDay – Hackathon – Exploration Days – TED days, etc.

Los factores claves de la motivación son:

Propósito.
Reto.
Compañerismo y relación con los demás miembros del equipo.
Responsabilidad.
Crecimiento y complementariedad.
Comunicación.

5.3 – Simplicidad (3)

Scrum no sería considerada una metodología ágil de no ser por su simplicidad, es por ello que se intenta al máximo reducir la burocracia en sus prácticas, se trabaja con los artefactos que son esenciales para el proyecto y se sigue un flujo de prácticas simple, sin descuidar todos los elementos necesarios para la correcta gestión del proyecto.

Es responsabilidad del Scrum Master garantizar que la simplicidad será el pilar fundamental para la adopción de Scrum.

5.3.1 - Diseño simple

Lo más importante en el desarrollo de un producto usando el marco Scrum, es el valor que entrega para los clientes/usuarios, considerando además que su desarrollo debería tardar el menor tiempo posible.

Es por esto que es altamente recomendable establecer un alcance para el proyecto que considere suficientes características para que el producto sea de alto valor para el usuario pero que tenga el menor tiempo de desarrollo posible, sin descuidar la calidad.

Este concepto tiene su justificación en los principios del Manifiesto Ágil “El producto funcional es más importante que la documentación exhaustiva”. (Ver más en la sección 6.6)

5.3.2 - Uso de herramientas de software

Las herramientas de software para la gestión de proyectos ágiles se han convertido en un elemento indispensable para garantizar la simplicidad. Algunas de las ventajas de usar estas herramientas son:

Centralizan la información de los proyectos, permitiendo un mejor control de la información.
Permiten automatizar tareas, por ejemplo:
- Estimaciones basadas en históricos.
- Calcular la velocidad del equipo.
- Elaborar gráficos para el seguimiento del presupuesto, progreso del Sprint (Burndown), progreso del proyecto (Diagrama de flujo acumulado), etc.
- Generar actas de reuniones.
Generan notificaciones sobre elementos del Product Backlog con atraso.
Facilitan la interacción de los Equipos Distribuidos geográficamente.
Si los proyectos son de desarrollo de software, permiten, además:
- Integración continua.
- Pruebas automatizadas.
- Trazabilidad bidireccional entre código e historias de usuario.

5.4 - Centrado en el valor para cliente (4)

En un proyecto Scrum, la máxima prioridad es satisfacer al cliente desde el inicio y continuamente entregándole el máximo valor posible, para lo cual es importante considerar los siguientes aspectos:

Es importante que en cada uno de los Sprints se generen incrementos de producto que entreguen valor para el cliente y estos a su vez estén “terminados”.
Para realizar la priorización de los elementos que hacen parte del Product Backlog los miembros del Equipo Scrum deberán considerar principalmente el valor que el elemento puede generar, para ello es importante el concepto de transparencia (Sección 5.1.1).
Cada incremento de producto “terminado” debe ser validado con el cliente para asegurar la recolección de retroalimentación.
Es altamente importante que el cliente participe activamente de las revisiones de los prototipos del producto antes de realizar cualquier desarrollo; incluso y según la naturaleza del proyecto, el cliente podrá participar activamente del diseño del producto.

5.5 – Cumplimiento (5)

Cumplir con las reglas establecidas por el Equipo Scrum y por la organización es de vital importancia para garantizar una sana convivencia entre todos los miembros del Equipo Scrum, evitar desvíos en los proyectos y, por último, pero no menos importante, garantizar la satisfacción del cliente.

A continuación, se listan las reglas esenciales que deben ser cumplidas:

Reglas establecidas por el Equipo Scrum.
Reglas establecidas por la organización.
Bloques de tiempo asignados a los eventos Scrum.
Definición de terminado y criterios de aceptación.

5.5.1 - Bloques de tiempo

Los bloques de tiempo asignados a los eventos Scrum, garantizan que no se desperdicia tiempo en los proyectos. Algunas ventajas de respetar los Bloques de Tiempo asignado son los siguientes:

Se evita que el equipo pierda motivación.
Menos gastos generales para el proyecto.
Se garantiza una alta velocidad para los equipos.
Las prácticas relacionadas con el desarrollo de entregables son más eficientes.

5.5.2 - Reglas del Equipo

Gracias al principio de la autoorganización, son los miembros del Equipo Scrum, quienes establecen sus propias reglas, claro, considerando el cumplimiento de las reglas establecidas por la organización. Por lo general, estas reglas se establecen una única vez al inicio del proyecto, y en algunas ocasiones podrán ser globales para múltiples proyectos o múltiples equipos. Al artefacto donde se registran estas reglas suele llamarse “Plan de Colaboración del Equipo Scrum”.

Algunos de los ítems que pueden hacer parte del Plan de Colaboración del Equipo Scrum son:

Principios del equipo.
Herramientas de comunicación.
Horarios de las reuniones.
Penalizaciones por incumplimiento.

5.6 - Desarrollo iterativo (6)

Scrum fue diseñado para que el desarrollo del proyecto se realice por iteraciones, también conocidas como Sprints. El método iterativo es flexible y abierto a los cambios, lo que permite adaptar el proyecto a las necesidades cambiantes del mercado, del cliente o de la organización.

dibujo

Cada iteración está compuesta por las siguientes etapas del Ciclo de vida del Proyecto y sus respectivas prácticas:

Etapa 2: Planificación.
Etapa 3: Desarrollo del Sprint.
Etapa 4: Revisión del Sprint.
Etapa 5: Implementación.

Esto significa que las siguientes etapas tienen prácticas que no necesariamente son iterativas:

Etapa 1: Inicio del proyecto.
Etapa 6: Cierre del proyecto.

dibujo

Algunas de las ventajas del desarrollo iterativo son:

Permite realizar entregas incrementales del producto, permitiendo a los clientes/usuarios disfrutar del valor entregado desde etapas tempranas.
Permite la adaptación continua del proyecto, ya que se puede recolectar retroalimentación de las partes interesadas en cada una de las iteraciones.
La realización de las reuniones de retrospectiva de los distintos Sprint, permiten el aprendizaje continuo del equipo.
El realizar Sprints, le agrega puntos de control frecuentes al proyecto, además proporciona estabilidad a los equipos.
Las reuniones de revisión del Sprint, se realizan frecuentemente, permitiendo reducir la incertidumbre de las partes interesadas respecto a los entregables del proyecto.