Guia Scrum Level

SCRUM LEVEL
Guía para evaluación de la agilidad

1.10
SCRUM LEVEL
1.10 - Septiembre 2016
http://www.scrumlevel.com
EXENCIÓN DE RESPONSABILIDAD
LOS AUTORES DE ESTE DOCUMENTO SON MIEMBROS Y COLABORADORES

DE LA COMUNIDAD PROFESIONAL SCRUM MANAGER VERSADOS EN GESTIÓN
DE PROYECTOS; REALIZAN ESTE TRABAJO PARA COMPARTIR SU
CONOCIMIENTO PROFESIONAL CON LAS PERSONAS Y ORGANIZACIONES QUE
LO CONSIDEREN ÚTIL.
ESTE TRABAJO SE OFRECE TAL CUAL, SIN GARANTÍA DE NINGÚN TIPO,
EXPRESA O IMPLÍCITA INCLUYENDO GARANTÍAS DE IDONEIDAD PARA UN
PROPÓSITO PARTICULAR. EN NINGÚN CASO, NI LOS AUTORES, NI LOS
TITULARES DE LOS DERECHOS SERÁN RESPONSABLES DE NINGUNA
RECLAMACIÓN, DAÑOS U OTRAS RESPONSABILIDADES.
Han hecho posible esta versión de Scrum Level:
Alexander Menzinsky, Claudia Ruata, José López

Juan Palacio, Marta Ariza, Miguel Santiago
Nelson Monzón y Raquel García.
Imagen de portada cc by Tim Sheerman-Chase
Scrum Level® es una iniciativa creada y coordinada por Iubaris Info 4 Media SL, y
desarrollada como obra colectiva por profesores y colaboradores de la comunidad
profesional Scrum manager.
Iubaris Info 4 Media SL es la propietaria de los derechos, y los libera en las

condiciones de la licencia Creative Commons by nd nc 4.0
Scrum Level® y Scrum Manager® son marcas registradas, propiedad de Iubaris Info 4
Media SL
Derechos registrados en Safe Creative. Nº de registro : 1605097468864

Guía para evaluación
Contenido
PREFACIO ................................................................................................................... 5
Propósito de este documento .................................................................................... 5
Audiencia .................................................................................................................. 5
Organización de esta guía:........................................................................................ 5
Convenciones empleadas ......................................................................................... 5
INTRODUCCIÓN .......................................................................................................... 6
Lo que entendemos por “scrum”................................................................................ 7
1.- Rugby ............................................................................................................... 7
2.- Métodos de trabajo ........................................................................................... 7
Gestión Ágil ............................................................................................................... 9
Técnicas, prácticas y valores .................................................................................... 9
Técnicas y prácticas: ........................................................................................... 10
Valores: ............................................................................................................... 11
Implicación del cliente. ......................................................................................... 11
GESTIÓN DE PROYECTOS PREDICTIVA Y EVOLUTIVA ........................................ 13
ÁMBITO DE SCRUM LEVEL ...................................................................................... 14
Dimensiones ........................................................................................................... 14
Factores analizados ................................................................................................ 14
TÉCNICAS Y PRÁCTICAS .................................................................................. 15
EJES ORGÁNICOS ............................................................................................. 16
Tabla 2: Ejes orgánicos a medir en la organización. ................................................................. 16
EVALUACIÓN Y ANÁLISIS ........................................................................................ 17
Dimensiones ........................................................................................................... 17
Evaluación de la flexibilidad .................................................................................... 17
Evaluación de la flexibilidad: Prácticas y técnicas ................................................ 17
Conocimiento técnico ágil. ................................................................................... 20
Análisis y evaluación de la flexibilidad. .................................................................... 20
Prácticas .............................................................................................................. 21
Evaluación de la flexibilidad: Conocimiento técnico ............................................. 23
Formulación de la flexibilidad ............................................................................... 24
Prácticas .............................................................................................................. 24
Evaluación de la fluidez........................................................................................... 25
Evaluación de la fluidez: Ejes orgánicos .............................................................. 25
Conocimiento profesional de las personas........................................................... 27
Análisis y valoración de la fluidez ............................................................................ 28
Rasgos ................................................................................................................ 28
3
Formulación de la fluidez......................................................................................... 28
Ejes orgánicos ..................................................................................................... 29
ANÁLISIS ................................................................................................................ 31
Informar de la fiabilidad........................................................................................ 31
Analizar los puntos de atención de la evaluación. ................................................ 31
Consideraciones .................................................................................................. 31
Apéndices ................................................................................................................... 32
Documento de evaluación. ...................................................................................... 32
Protocolos ............................................................................................................... 36
Normas y restricciones para protocolos................................................................... 37
Glosario................................................................................................................... 38
Trabajos citados ......................................................................................................... 43
Índice .......................................................................................................................... 44
4
PREFACIO
Scrum Level es un modelo de referencia y buenas prácticas para mejorar la agilidad
en la gestión y producción.
Este modelo se ha desarrollado, y está en continua revisión y mejora, desde el

conocimiento y experiencia aportados por los miembros y colaboradores de la
comunidad profesional Scrum Manager.
Propósito de este documento

Guía y referencia en los procesos de evaluación Scrum Level.
Audiencia
La audiencia de esta guía incluye a todas las personas interesadas en la mejora de la
gestión y producción ágil; resulta adecuada como texto formativo para los interesados
en el conocimiento o estudio de la agilidad, y como documento de referencia para los
responsables de procesos de evaluación, asesoría y mejora.
Organización de esta guía:

Introducción
Puesta en contexto del origen y razón de la agilidad, y de esta guía.
Scrum
Descripción de Scrum, desde la perspectiva de Scrum Manager.
Scrum Level
Presentación esquemática de Scrum Level.
Evaluación y análisis
Guía para evaluaciones Scrum Level, y uso de los resultados en procesos de asesoría
y mejora.
Convenciones empleadas
Los términos recogidos en el glosario aparecen en cursiva siempre que se emplean
con el significado concreto en él definido.
5
INTRODUCCIÓN
“Muchas compañías han descubierto que para mantenerse en el actual mercado
competitivo necesitan algo más que los conceptos básicos de calidad elevada, costes
reducidos, diferenciación. Además de esto también es necesario velocidad y
flexibilidad”
Ikujiro Nonaka, Hirotaka Takeuchi (1986) “The New New Product Development Game”
A esta conclusión llegaron Nonaka y Takeuchi en 1986, tras analizar a las empresas
tecnológicas que mejor respondían al cambio rápido y continuo de sus entornos de
negocio. En ellas identificaron como denominador común, una forma de trabajo a la
que denominaron scrum, porque el factor clave, al igual que en la formación scrum de
rugby, eran equipos comprometidos y atenazados.
El trabajo “en scrum” era el empleado en los departamentos de innovación y desarrollo

de nuevos productos de las empresas tecnológicas, objeto del estudio de Nonaka y
Takeuchi (Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-
Packard) y se propagó durante las dos décadas siguientes al desarrollo de software.
En 2001, diecisiete expertos en desarrollo de software, convocados por Kent Beck,

resumieron de forma breve y memorable en el documento que denominaron
“Manifiesto Ágil” (Agile Manifesto) estos nuevos principios, aplicados al software:
Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra

propia experiencia como ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:
Individuos e interacciones, sobre procesos y herramientas.

Software funcionando, sobre documentación extensiva.
Colaboración con el cliente, sobre negociación contractual.
Respuesta ante el cambio, sobre seguir un plan.
Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la
izquierda.
(2001) Manifesto for Agile Software Development
Las empresas que desarrollan productos, y tienen en la innovación su principal valor o

ventaja competitiva, necesitan desarrollo ágil.
La incorporación de prácticas de ingeniería concurrente, o de agilidad, mejora el

“time to market” de los productos y los mantiene “vivos” y en continua adaptación a
la evolución de su mercado.
La incorporación de los valores de la agilidad en la organización, mejora el valor

innovador de los productos que desarrolla.
Adicionalmente mejora la reputación de la organización frente a los clientes que

valoran la innovación y el compromiso con sus productos, y frente a los profesionales
6
mejor cualificados de su sector, que prefieren las empresas que convierten el modelo
de gestión de recursos humanos, en el de gestión del talento.
NECESIDAD DE UN MARCO DE REFERENCIA

Las organizaciones que desean implantar o mejorar un entorno de trabajo ágil,
necesitan una guía y criterios de referencia para identificar y analizar las áreas de
mejora.
Scrum Level cubre este objetivo, definiendo una guía de referencia y apoyo para
mejorar la agilidad de las organizaciones.
Scrum Level realiza una evaluación estructurada de la organización: de sus ejes

orgánicos, y de las prácticas de trabajo que emplea, revelando los aspectos más y
menos consolidados, y las posibles acciones de revisión y mejora.
El resultado permite la medición y análisis de cada rasgo y práctica por separado, y de

la organización, bien de forma global en su conjunto, o parcialmente, en su dimensión
técnica (agilidad técnica).
Lo que entendemos por “scrum”

1.- Rugby
Formación de rugby
Scrum es el término que define a la formación
más reconocible del rugby, en la que ambos
equipos, agazapados y atenazados entre sí,
empujan para obtener el balón, y sacarlo de la
formación sin tocarlo con la mano.
Figura 1. Formación de rugby scrum.
2.- Métodos de trabajo
Ambiente de trabajo ágil autoorganizado
En 1986 los investigadores Nonaka y Takeuchi

dan dimensión polisémica al término
originalmente deportivo scrum, al emplearlo para
bautizar los principios de desarrollo que
descubrieron en las empresas tecnológicas más
innovadoras (Takeuchi & Nonaka, 1986).
Scrum, en la concepción original de Nonaka y Figura 2. Scrum como marco de trabajo: 1986, Hirotaka
Takeuchi, se caracteriza por el protagonismo de Takeuchi, Ikujiro Nonaka "The New New Product
Development Game"
equipos brillantes, autoorganizados y motivados,
que abordan el desarrollo sistemas complejos
partiendo de una visión general y solapando las
fases del desarrollo.
7
Metodología para desarrollo de software

En 1995 Ken Schwaber presentó en OOPSLA
(Conferencia anual “Object-Oriented Programming,
Systems, Language s & Applications”) (Schwaber,
1995) una metodología de desarrollo de software,
basada en un ambiente scrum y uso ese mismo
término para definir el proceso.
Figura 3. Ken Schwaber, "Scrum Development Process”
Marco para desarrollo de software basado

en la metodología scrum de Ken Schwaber
En 2005 Mike Cohn, Esther Derby y Ken Schwaber
constituyeron la organización “Scrum Alliance” para
difundir un marco de trabajo específico para el
desarrollo de software, basado en esta Figura 4. Marco scrum
metodología. y a la que también
denominaron scrum.
Scrum Level usa el término en el significado original de Nonaka y Takeuchi, como un

ambiente de trabajo caracterizado por la composición de equipos autoorganizados que
trabajan de forma ágil: con autonomía y solapamiento de las fases de desarrollo, y
compartiendo el conocimiento y aprendizaje de forma abierta.
8
Gestión Ágil
En el ámbito de gestión de proyectos, personas y organizaciones, el concepto de
agilidad surgió a finales del siglo pasado como antítesis de los modelos tayloristas, y
de producción industrial de ciclos de desarrollo secuenciales y calidad basada en
ingeniería de procesos.
En los últimos 20 años la agilidad ha demostrado que los marcos de desarrollo

iterativo, y calidad basada en el conocimiento tácito de las personas, son los más
apropiados para desarrollar productos o servicios innovadores, que requieren revisión
continua por ser de ciclos de venta breves, o competir en escenarios comerciales de
incertidumbre elevada.
El concepto de agilidad surgió al identificar en la industria manufacturera japonesa

(Takeuchi & Nonaka, 1986) una forma de trabajo de que estaba sorprendiendo en su
sector por la innovación de sus productos y la rapidez con la que los desarrollaban; y
reveló que el denominador común eran la autoorganización de equipos autónomos,
multifuncionales, trabajando en un mismo espacio físico, sin emplear ciclos de
desarrollo secuenciales. Scrum fue el nombre con el que se denomino a esa novedosa
forma de trabajo.
Al mismo tiempo, en otra industria diferente: la del software, algunos equipos de

programadores desafiaban a los ciclos de desarrollo secuencial y a los modelos de
producción basados en procesos, empleando también principios ágiles, bien por propia
iniciativa a través de modelos como XP (eXtreme Programming), o bien trabajando en
ambientes scrum .
El Manifiesto para Desarrollo Ágil de Software, comúnmente llamado “Manifiesto ágil”,

fue redactado en 2001 por 17 ingenieros de software.
Sintetiza los principios de agilidad proclamados como alternativa a la producción

secuencial y procedimentalizada; y se ha convertido en el hito de referencia en cuanto
a principios y consolidación de la agilidad.
Técnicas, prácticas y valores

El resultado de un marco de desarrollo scrum depende del grado en el que se
compaginan sus dos componentes:
 Las técnicas y prácticas empleadas para producir el resultado de forma

incremental y continua.
 Los valores y la cultura de la organización de las personas que trabajan con
esas técnicas.
Usar técnicas y prácticas ágiles en un marco de producción sin una cultura ágil, no es
propiamente agilidad, sino ingeniería concurrente (solapamiento de fases) con ciclo de
vida incremental, o lo que se podría llamar “agilidad técnica”.
La agilidad técnica es adecuada para trabajos en los que por su mecanicidad resulta
más eficiente basar la calidad y homogeneidad del resultado en ingeniería de
procesos, que en el conocimiento profesional de las personas que lo realizan. En este
sentido, la agilidad técnica resulta apropiada cuando la entrega temprana y el
incremento continuo son un valor relevante para el cliente.
9
Figura 5. Agilidad técnica y scrum
Sin embargo, hay entornos profesionales donde la innovación y el ingenio son

imprescindibles para aportar verdadero valor al producto. En estos casos, el
conocimiento profesional de las personas que realizan los distintos procesos es
fundamental, y un ambiente scrum potencia el talento de equipos compuestos por
personas competentes y motivadas. Esto es lo que se conoce como Agilidad.
La potencia de scrum radica en cómo gestiona el ciclo de vida de vida y la

aportación de valor al producto.
Ciclo de vida
Scrum no tiene como objetivo entregar el producto completo y terminado en el tiempo

y con el coste previsto, sino suministrar lo antes posible un producto mínimo viable e
incrementar su valor a través de iteraciones de desarrollo breves y continuas.
Valor del producto
El valor del producto depende y es proporcional al conocimiento profesional de las

personas que lo desarrollan, a diferencia de la producción industrial que confía el valor
del resultado al “know how” explicitado en los procesos y la tecnología empleados.
La gestión de un ciclo de vida que incremente el producto de forma continua e

iterativa, se consigue aplicando determinadas técnicas y prácticas.
Sin embargo la aportación del conocimiento necesario a través de las personas, no se

logra por emplear determinadas técnicas, sino creando ambientes de trabajo scrum
para atraer y hacer brotar el talento.
Técnicas y prácticas:
El ciclo de vida ágil se caracteriza por la entrega temprana de valor, y su incremento
continuo en periodos breves.
Los retos que plantea el ciclo de vida ágil son:
1.- Definición del producto mínimo viable: Funcionalidades suficientes para lanzar
el producto, y forma en la que se deben integrar.
2.- Gestión de la evolución continua de los requisitos.
3.- Monitorización y mantenimiento de un flujo de entregas de valor constantes.
10
El conjunto de prácticas y técnicas ágiles proporciona el inventario de recursos

profesionales para gestionar estos retos.
Así por ejemplo, para representar y gestionar la visión del producto, es habitual el uso
de pilas de producto, estimación en la pared, mockups, etc.
Las prácticas para la definición y gestión de avance en sprints, o las empleadas para
mantener un flujo continuo de tareas con técnicas de gestión visual kanban , resuelven
la monitorización del avance y el mantenimiento de un flujo constante de entregas de
valor, etc.
Valores:
Que el principal responsable del valor entregado al cliente sea el conocimiento
profesional de las personas, implica rasgos culturales de la organización importantes:
1.- Entrega de valor como objetivo.

Un ambiente scrum no centra el objetivo en el valor propio, sino en el entregado al
cliente. No quiere esto decir que la organización no obtenga beneficio por su trabajo,
sino que éste se considera una consecuencia, no un fin; es la consecuencia de la
entrega continua de valor al cliente.
2.- Trabajo en equipo.

La interacción de los miembros del equipo, la difusión del conocimiento compartido y la
fertilización cruzada de las ideas multiplica la potencia del aporte de las personas: el
talento.
3.- Excelencia profesional.

La motivación y el perfil profesional de las personas de la organización, debe ser lo
más alto posible.
Implicación del cliente.

Para mantener un ciclo de vida incremental con un flujo continuo de producción es
necesario emplear prácticas ágiles.
Si además se necesita potenciar el talento de las personas, también son necesarios

determinados rasgos culturales en la organización; pero siempre es imprescindible
la implicación del cliente.
La comunicación e implicación del cliente con el equipo del producto es necesaria,

porque la entrega continua requiere feedback continuo de su parte.
Si además no se trata de agilidad técnica, sino de agilidad, el equipo debe conocer y

compartir la visión del cliente.
11
Figura 6. Agilidad técnica y scrum
12
GESTIÓN DE PROYECTOS PREDICTIVA Y

EVOLUTIVA
Dos son los patrones de los ciclos de vida empleados en el desarrollo de productos:
Predictivo
Tiene como objetivo entregar el producto completo y terminado, velando por el

cumplimiento de los requisitos y las estimaciones de fecha de entrega y esfuerzo
necesario.
Evolutivo
Tiene como objetivo entregar lo antes posible un producto suficiente, y mantener sobre
él un ritmo continuo de evolución y mejora.
Figura 7. Ingeniería secuencial, ingeniería concurrente y scrum.
La gestión predictiva comienza con un plan de proyecto calculado a partir de la

descripción completa del producto, y sobre él calcula el tiempo y trabajo de ejecución
necesario, que posteriormente gestiona en fases secuenciales (cascada)
La gestión evolutiva no parte de la descripción completa del producto sino de la visión

inicial, y detalla y desarrolla de forma continua partes del mismo, manteniendo un flujo
de incrementos que desde la primera entrega inicial lo amplían y mejoran de forma
constante.
Las diferentes fases del desarrollo, desde el diseño hasta la validación y entrega se
ejecutan de forma solapada, porque no es el producto completo en bloque el que va
avanzando en cascada a través de las diferentes fases.
La gestión evolutiva puede confiar el conocimiento, el “saber hacer” necesario, al

seguimiento de pautas o procesos institucionalizados (conocimiento explicitado en
procesos) o al conocimiento tácito de las personas que las realizan.
13
En el primer caso, emplea ingeniería de procesos con solapamiento de las fases de

desarrollo; se trata por tanto de ingeniería concurrente aplicada con un ciclo de vida
evolutivo.
Esta estrategia, vista desde la perspectiva de la agilidad se trata de una agilidad
técnica: una “agilidad” que emplea prácticas y técnicas ágiles sobre ingeniería de
procesos. Vista desde la perspectiva de la producción industrial, se trata de la
aplicación de ingeniería concurrente para desarrollar productos de forma incremental.
ÁMBITO DE SCRUM LEVEL

Scrum Level analiza y evalúa el nivel de agilidad en las dos dimensiones que vienen
determinadas por los dos factores vistos: Técnicas y prácticas por un lado, y valores
por otro.
Dimensiones
Scrum Level analiza indicadores y evidencias de
forma separada en dos dimensiones:
 Dimensión técnica: Determinada por las

técnicas y prácticas de trabajo
empleadas. Las evaluaciones de Scrum
Figura 8. Dimensiones del modelo.
Level miden esta dimensión como
flexibilidad.
 Dimensión organizativa: Determinada por los rasgos de personalidad de la
organización. Las evaluaciones de Scrum Level miden esta dimensión como
fluidez.
Factores analizados
Para la evaluación de la flexibilidad:
 Técnicas y prácticas de trabajo.
 Conocimiento técnico de las personas.
Figura 9. Flexibilidad en las prácticas
Para la evaluación de la fluidez:

 Ejes orgánicos
 Conocimiento profesional de las
personas1.
Figura 10. Fluidez en las prácticas
1
El conocimiento profesional de las personas es un factor determinante de la fluidez, pero su
evaluación excede el campo de una evaluación Scrum Level.
14
TÉCNICAS Y PRÁCTICAS
La evaluación de la agilidad técnica de la organización analiza y evalúa de forma
diferenciada el grado de implantación de las siguientes prácticas:
ÁMBITO PRÁCTICA
1. DE PROYECTO 1.1 Reunión diaria.
1.2 Revisión continua del avance por estimación del esfuerzo pendiente.
1.3 Desarrollo incremental.
1.4 Entregas en reunión con el cliente.
1.5 Reuniones de planificación frecuentes.
1.6 Información visual.
1.7 Control del trabajo en proceso (WIP).
1.8 Definición de tarea terminada.
2. DE PRODUCTO 2.1 Propietario de producto único.
2.2 Propietario de producto autónomo.
2.3 Propietario de producto implicado.
2.4 Visión definida.
2.5 Visión compartida.
2.6 Pila de producto.
3. DE ORGANIZACIÓN 3.1 Equipos autoorganizados.
3.2 Reuniones retrospectivas.
3.3 Espacio de trabajo común para el equipo.
3.4 Ritmo sostenido (< 40 horas semana).
3.5 Flexibilidad funcional.
4. DE PRODUCCIÓN 4.1 Comprobación continua.

(ING. SOFTWARE)
4.2 Integración continua.
4.3 Programación en parejas.
4.4 Diseño simple e incremental.
4.5 Estándares de codificación.
4.6 Propiedad colectiva del código.
Tabla 1: Ámbitos y prácticas que definen la agilidad.
15
EJES ORGÁNICOS
El nivel de agilidad organizativa o fluidez, viene determinado por el conjunto de
principios y valores que inspiran la cultura de la organización.
Para determinar los factores culturales que favorecen y los que impiden el desarrollo
de modos de trabajo ágiles, y en qué grado, Scrum Level evalúa 16 rasgos de la
organización.
Para cada rasgo se determina en qué grado facilita o entorpece el trabajo ágil,
representando sobre un hipotético eje la posición en la que se encontraría, más o
menos próxima al extremo ágil o al no ágil.
ÁREA EJE RASGO NO ÁGIL RASGO ÁGIL
1. GESTIÓN 1.1. OBJETIVO ORGANIZACIONAL Objetivo beneficio Objetivo cliente
1.2. CONOCIMIENTO: TIPO Explícito Tácito
1.3. CONOCIMIENTO: Departamentalizado Socializado

DISTRIBUCIÓN
1.4. PERSONAS: GESTIÓN Operarios Artífices
1.5. PERSONAS: MOTIVACIÓN Extrínseca Intrínseca
1.6. ORGANIZACIÓN DEL TRABAJO Trabajo individual Trabajo en equipo
1.7. GOBERNANZA Directiva Colaborativa
1.8. GESTIÓN DEL ERROR Incriminatoria Analítica
2. MÉTODOS 2.1. GESTIÓN DE LA MEJORA Mejora periódica Mejora continua
2.2. COMUNICACIÓN: PROCESO Escrita Directa
2.3. COMUNICACIÓN: ESTILO Jerarquizada Abierta
3. PROYECTO 3.1. ADQUISICIÓN Contractual Colaborativa
3.2. SEGUIMIENTO Cliente pasivo Cliente

participativo
3.3. SUMINISTRO Entrega puntual Entrega continua
3.4. REQUISITOS Cerrados Evolutivos
3.5. GESTIÓN Planificada Orientada al valor

Tabla 2: Ejes orgánicos a medir en la organización.
16
EVALUACIÓN Y ANÁLISIS
Las organizaciones son realidades sistémicas con múltiples relaciones e interacciones
entre sus diferentes áreas, departamentos y equipos. La introducción de prácticas
ágiles de forma departamentalizada, o no alineada con los valores y la visión de la
organización genera fricción cultural.
Scrum Level proporciona un método para la evaluación estructurada de las variables

que determinan las características y grado de agilidad de la organización.
El método incluye criterios de formulación para determinar cuantitativamente cada
factor, y a la organización en su conjunto.
La evaluación puede emplearse como herramienta de diagnóstico para identificar las

áreas de mejora, o posibles desequilibrios entre diferentes sectores de la organización.
También como indicador para referencia y medición de los avances.
Dimensiones
El grado de agilidad de la organización es resultado de la combinación de los patrones
de agilidad en sus dos dimensiones:
 Técnica: Determinada por las técnicas y prácticas de trabajo empleadas. Las

evaluaciones de Scrum Level miden esta dimensión como flexibilidad.
 Organizativa: Determinada por los valores y rasgos de personalidad de la
organización. Las evaluaciones de Scrum Level miden esta dimensión como
fluidez.
Evaluación de la flexibilidad
Medida del grado de agilidad en la dimensión técnica de la organización.
Los factores que la determinan son:

 Prácticas y técnicas de trabajo empleadas.
 Conocimiento técnico que las personas tienen de prácticas de trabajo ágiles.
Evaluación de la flexibilidad: Prácticas y técnicas

Las prácticas y técnicas de trabajo deben ser adecuadas a las características del ciclo
de vida ágil: entrega de valor temprana, iterativa e incremental.
Deben emplearse en las cuatro áreas de la producción:

 Proyecto: gestión del ciclo de vida ágil.
 Producto: gestión ágil de producto.
 Organización: gestión y autoorganización del trabajo.
 Desarrollo: Técnicas específicas para el tipo de producto o servicio
desarrollado.
17
1. PRÁCTICAS DE PROYECTO
1.1 Reunión diaria.

A diario, las personas de cada equipo mantienen una reunión breve, en la que todos
los miembros comunican la tarea o tareas en las que están trabajando, analizando en
equipo si el ritmo de avance es el esperado, o si se están encontrando o es previsible
algún impedimento.
1.2 Revisión continua del avance por estimación del esfuerzo pendiente.
Los equipos revisan a diario el avance del trabajo, o emplean técnicas de
monitorización visual del mismo que presentan la información actualizada, y que basan
en la estimación del esfuerzo pendiente.
1.3 Desarrollo incremental.

Los equipos entregan a sus respectivos clientes incrementos o mejoras del producto o
servicio en periodos cortos, o de forma continua.
1.4 Entregas en reunión con el cliente.

La entrega de cada incremento del producto se realiza en una reunión del equipo que
la ha desarrollado, con el cliente. En la reunión se ve el resultado en funcionamiento.
1.5 Reuniones de planificación frecuentes

Cada equipo que desarrolla un producto o presta un servicio, mantiene reuniones
frecuentes con el cliente en las que se plantea y planifica la parte de producto, o las
características de la prestación del servicio que se va a producir en el periodo que se
abre hasta la próxima reunión.
1.6 Información visual.

Se utilizan herramientas de información visual que permiten a todos los miembros e
interesados de cada proyecto conocer su estado de avance.
1.7 Control del trabajo en proceso (WIP).

La organización tiene institucionalizadas prácticas de trabajo que limitan en cada
equipo el número de tareas que pueden estar desarrollando de forma simultánea.
1.8 Definición de tarea terminada.

Los equipos tienen definido e institucionalizado el concepto de “tarea terminada” como
la tarea que ya no necesita ninguna intervención ni recurso de desarrollo ni
comprobación.
2. PRÁCTICAS DE PRODUCTO
2.1 Propietario del producto único.
Cada producto o servicio tiene una única persona responsable de las decisiones que
afectan al interés del cliente.
18
2.2 Propietario del producto autónomo.

El propietario del producto tiene atribuciones y autonomía para realizar propuestas y
tomar decisiones relativas al producto e interés del cliente.
2.3 Propietario del producto implicado

El propietario del producto mantiene comunicación y colaboración continua y activa
con el equipo del producto.
2.4 Visión definida.

El propietario del producto tiene una visión definida del objetivo.
2.5 Visión compartida.

El propietario del producto está comprometido con la comunicación y transmisión de la
visión del objetivo a todo el equipo.
2.6 Pila de producto.

El propietario del producto mantiene una lista priorizada de las funcionalidades que
espera del producto. Esta lista es conocida y permanentemente accesible a todo el
equipo.
3. PRÁCTICAS DE ORGANIZACIÓN
3.1 Equipos autoorganizados.
La organización de los equipos y la asignación y distribución de los trabajos la realiza

cada equipo de forma autónoma.
3.2 Reuniones retrospectivas.

Los equipos realizan periódicamente reuniones para analizar las prácticas y métodos
de trabajo para su perfeccionamiento.
3.3 Espacio de trabajo común para el equipo.

Los miembros de cada equipo comparten el espacio físico de trabajo.
3.4 Ritmo sostenido.

Los equipos mantienen una cadencia de trabajo continua (menor a 40 horas semana),
de alto rendimiento, y sin sobrecargas, ni continuadas ni puntuales.
3.5 Flexibilidad funcional.

Las distintas técnicas y conocimiento empleado en el desarrollo del producto o la
prestación del servicio de cada equipo son conocidos o compartidos por distintos
miembros. En los equipos no se producen islas de conocimiento, y una misma tarea
puede ser realizada por diferentes miembros.
19
4. PRÁCTICAS DE PRODUCCIÓN (ING.SOFTWARE)
4.1 Comprobación continua.

La organización tiene institucionalizadas prácticas destinadas a la comprobación
continua de que se está desarrollando el producto esperado por el cliente en la forma
correcta. Algunas de las prácticas esperadas con esta finalidad son: TDD (Test-driven
development), ATDD (Acceptance Test Driven Development) y BDD Behavior-Driven
Development)
4.2 Integración continua.

En la organización está institucionalizado el uso de la práctica de ingeniería del
software: “Integración continua”, o alguna práctica equivalente de integración con la
finalidad de la detección temprana de posibles fallos.
Se entiende por integración la compilación y ejecución de pruebas del proyecto.
4.3 Programación en pareja

En la organización está institucionalizada la programación en pareja.
4.4 Diseño simple e incremental

El diseño del software se basa en los principios:
1. Es una actividad evolutiva que incluye refactorización

2. La calidad del diseño se evalúa con el criterio de la simplicidad de código
3. Las decisiones de diseño se evalúan con el criterio de coste/beneficio
4. Las decisiones de diseño se abordan “justo a tiempo”, en el momento que se
necesitan.
4.5 Estándares de codificación

Los equipos tienen institucionalizados estándares de codificación.
4.6 Propiedad colectiva del código

En cada equipo se escribe el código dentro de la arquitectura y diseño del sistema, y
todos los miembros son responsables del código de todo el sistema.
Conocimiento técnico ágil.

El segundo factor del grado de flexibilidad es el conocimiento técnico de las personas
para aplicar prácticas y métodos ágiles.
Un ejemplo para ilustrar la participación de los dos factores de la flexibilidad: prácticas

empleadas y conocimiento técnico.
Además de estar institucionalizado el uso de pilas de producto en la gestión de

requisitos, los responsables de producto deben conocer y saber gestionar una pila de
producto.
Análisis y evaluación de la flexibilidad.

El estudio de la flexibilidad analiza y evalúa los dos factores vistos: las prácticas ágiles
empleadas, y conocimiento técnico de agilidad, aplicando los criterios siguientes.
20
Prácticas
Verificación pericial o técnica de los siguientes parámetros para cada una de las
prácticas.
Escala
0 - No implementada
Poca o ninguna evidencia de que la práctica se realice.
1 - Parcialmente implementada
La práctica se aplica pero no siempre o no en todos los proyectos del ámbito de la

evaluación, ni de forma homogénea.
2 - Ampliamente implementada
La práctica se aplica siempre, pero no está institucionalizada (sin garantía de

homogeneidad y mejora continua)
3 - Completamente implementada
La práctica se aplica siempre y se encuentra institucionalizada (con formación y en

mejora continua)
21
Ejemplo de un posible resultado de la verificación de valores en las prácticas.
PRÁCTICA GRADO DE IMPLEMENTACIÓN
1.1 Reunión diaria 1 Parcial

1.2 Cálculo del avance 3 Completo
1.3 Desarrollo iterativo o continuo 2 Amplio
PROYECTO
1.4 Entrega iterativa o continua 2 Amplio

1.5 Reuniones de planificación 3 Completo
1.6 Información visual 3 Completo
1.7 Control del WIP 0 Ninguno
1.8 Definición de tarea terminada 2 Amplio
2.1 Propietario de producto único 3 Completo
2.2 Propietario de producto autónomo 1 Parcial
PRODUCTO
2.3 Propietario de producto implicado 2 Amplio

2.4 Visión definida 2 Amplio
2.5 Visión compartida 1 Parcial
2.6 Pila de producto 3 Completo
3.1 Autoorganización 2 Amplio
ORGANIZACIÓN
3.2 Reuniones retrospectivas 0 Ninguno

3.3 Espacio de trabajo común 3 Completo
3.4 Ritmo sostenido 2 Amplio
3.5 Flexibilidad funcional 2 Amplio
4.1 TDD 1 Parcial
PRODUCCIÓN
4.2 Integración continua 2 Amplio

4.3 Programación en parejas 0 Ninguno
4.4 Estándares de codificación 1 Parcial
4.5 Propiedad colectiva del código 1 Parcial
Tabla 3: Prácticas y grado de implementación.
22
Evaluación de la flexibilidad: Conocimiento técnico

Verificación pericial o técnica del conocimiento técnico de las personas del grupo
evaluado.
Escala
0. - Insuficiente
La persona no tiene un conocimiento suficiente para desempeñar las tareas propias de
su trabajo empleando prácticas y técnicas ágiles.
Referencia para la evaluación;
 El nivel de conocimiento es insuficiente para superar un examen de

acreditación Scrum Manager de nivel técnico, o un examen estándar de Scrum
Master (scrumstudy.org, scrum.org, Scrum Alliance)
1.- Nivel técnico

La persona tiene un conocimiento suficiente para desempeñar las tareas propias de su
trabajo empleando prácticas y técnicas ágiles.
Referencia para la evaluación:

 El nivel de conocimiento es suficiente para superar un examen de acreditación
Scrum Manager de nivel técnico, o un examen estándar de Scrum Master
(scrumstudy.org, scrum.org, Scrum Alliance)
2.- Nivel experto

La persona tiene conocimientos holgados para desempeñar las tareas propias de su
trabajo empleando prácticas y técnicas ágiles.
Referencias para la evaluación:

Scrum Manager de nivel experto.
(scrumstudy.org, scrum.org, Scrum Alliance) y tiene al menos 12 meses de
experiencia de trabajo en equipos empleando técnicas ágiles.
3.- Nivel Autoridad

La persona es un conocedor experto de la gestión ágil de proyectos y organizaciones,
y de scrum.
Referencias de contrastación:
 La persona tiene certificado un nivel de autoridad en Scrum Manager de más

de 200 PDAs.
(scrumstudy.org, scrum.org, Scrum Alliance) y tiene al menos 24 meses de
experiencia trabajando en equipos ágiles, empleando técnicas ágiles.
23
Formulación de la flexibilidad
Una vez realizadas las verificaciones de los distintos factores, el análisis de su
combinación determina la flexibilidad general de la organización.
Los tres principios que deben guiar el análisis son:
1.- Valores medios

La flexibilidad global refleja el promedio de las flexibilidades parciales que la
componen. Se debe considerar la media aritmética, y no la moda o la mediana.
2.- Homogeneidad
La falta de homogeneidad entre los valores parciales de flexibilidad es síntoma de
tensiones o fricciones en la organización, y disminuye, o incluso neutraliza los efectos
de scrum.
Cuando se produce, en la ponderación se deben analizar siempre las causas y

considerar la valoración de sus consecuencias.
3.- Ponderación
El análisis de la flexibilidad pondera los valores medios obtenidos considerando al
menos:
Las evaluaciones técnicas deben incluir criterios de formulación que consideren el

impacto atenuador, cuando se produce falta de homogeneidad.
Las evaluaciones expertas, a diferencia de las técnicas, son actuaciones ágiles y en

ellas prevalece el criterio experto de la persona que realiza la evaluación, por encima
del criterio técnico de la formulación.
La ponderación de las evaluaciones expertas incluye el razonamiento y argumentación
de los ajustes realizados a los valores medios de la formulación.
Prácticas
1.- Valoración de la flexibilidad parcial por cada área de prácticas
Con los valores verificados en las diferentes prácticas se obtienen los promedios de
cada grupo: prácticas de proyecto, producto, organización y producción.
Ejemplo de un posible resultado de la verificación de un grupo de prácticas.
PRÁCTICAS DE PROYECTO 0 1 2 3
1.1 Reunión diaria
1.2 Revisión continua del avance
1.3 Desarrollo iterativo o continuo
1.4 Entrega iterativa o continua
1.5 Reuniones de planificación
1.6 Información visual
1.7 Control del WIP
1.8 Definición de tarea terminada
Tabla 4. Flexibilidad parcial por cada área.
24
2.- Valoración de la flexibilidad parcial por las prácticas

Con las flexibilidades parciales de los cuatro grupos de prácticas se calcula el
promedio de la flexibilidad parcial de las prácticas.
Ejemplo de un posible resultado de la verificación de los grupos de prácticas.
ÁREAS DE PRÁCTICAS 0 1 2 3
1.- De proyecto
2.- De producto
3.- De organización
4.- De producción
Tabla 9. Flexibilidad parcial por prácticas.
3.- Valoración de la flexibilidad parcial por el conocimiento técnico.

Con los valores verificados del conocimiento técnico de las personas se obtiene el
promedio.
Siguiendo el principio de homogeneidad, el análisis debe considerar siempre en la

ponderación de esta media, la presencia de más de un 20% de las personas que
forman parte del ámbito de la evaluación con valoración 0.
Ejemplo de un posible resultado de la verificación del conocimiento técnico. .
CONOCIMIENTO TÉCNICO 0 1 2 3
Nombre de la persona
Tabla 10. Flexibilidad parcial por conocimiento técnico.
Evaluación de la fluidez
Medida que expresa el grado de agilidad en la dimensión cultural de la organización.
Los factores que la determinan son:
 Valores ágiles de los ejes orgánicos.

 Conocimiento profesional de las personas.
Evaluación de la fluidez: Ejes orgánicos

Scrum Level identifica 16 ejes que polarizan los rasgos que configuran la personalidad
y valores culturales de la organización.
Estos 16 ejes orgánicos se agrupan en tres áreas:
25
1.- Gestión.
Se encuentran en esta área los ejes con los rasgos que definen el estilo de gestión,
tanto de la organización como de las personas.
2.- Métodos.
Pertenecen a esta los rasgos que determinan el modo de proceder las personas de la
organización en su relación, comunicación, y mejora continua.
3.- Proyecto.
Área con los rasgos que determinan la estrategia de gestión de proyectos
Área 1. GESTIÓN
Eje 1.1 OBJETIVO ORGANIZACIONAL.

Determina el punto en el que se sitúa el foco de atención de la organización entre estos
dos objetivos: a) obtención de beneficio, b) entrega al cliente del mayor valor posible.
Eje 1.2 CONOCIMIENTO: TIPO.

Determina cuál de estos tipos de conocimiento tiene más peso, y en qué grado, en el
desarrollo de los productos o en la prestación de los servicios que ofrece la organización:
El conocimiento explicitado en los procesos y la tecnología, o el conocimiento tácito de las
personas que producen o prestan los servicios.
Eje 1.3 CONOCIMIENTO: DISTRIBUCIÓN.

Determina en qué medida el conocimiento se encuentra más próximo a uno de los
extremos siguientes: a) es compartido dentro de la organización y entre departamentos. B)
se encuentra confinado a las especialidades departamentales, y es utilizado como
instrumento de poder para fortalecer perímetros funcionales.
Eje 1.4 PERSONAS: GESTIÓN.

Determina si las pautas de gestión de recursos humanos son más idóneas para la gestión
de operadores u operarios (delimitación de horarios y tareas) o de artífices (autonomía y
responsabilidad global).
Eje 1.5 PERSONAS: MOTIVACIÓN.

Determina el grado de preferencia de la organización, entre motivadores extrínsecos
(incentivos económicos y recompensas) e intrínsecos (satisfacciones inherentes al
desarrollo del propio trabajo: autonomía, maestría y propósito).
Eje 1.6 ORGANIZACIÓN DEL TRABAJO.

Determina si la empresa tiene un modelo organizativo basado en individualidades
profesionales o en equipos.
Eje 1.7 GOBERNANZA.

Determina el estilo de gerencia de la organización entre los polos: directivo y colaborativo.
Eje 1.8 GESTIÓN DEL ERROR.

Determina la actitud general de la organización frente a los errores y la apreciación de los
mismos como necesarios para el aprendizaje.
Área 2. MÉTODOS.
26
Eje 2.1 GESTIÓN DE LA MEJORA.

Determina el grado de institucionalización de prácticas de mejora continua.
Eje 2.2 COMUNICACIÓN: PROCESO.

Determina el grado de "intermediación" en la comunicación entre personas de la
organización; entendiendo por "intermediación" tanto la física por el uso de medios de
transmisión como alternativa a la comunicación “cara a cara”, como la temporal o
comunicación asíncrona (telefónica, videoconferencia, correo electrónico, chat, foros, etc.).
Eje 2.3 COMUNICACIÓN: ESTILO.

Determina el grado de "transversalidad jerárquica" de la comunicación. Por ejemplo, si la
comunicación entre distintos niveles jerárquicos es considerada un “puenteo”, o existe una
“política de puertas abiertas”, o se realizan reuniones del tipo “skip-level meetings”.
Área 3. PROYECTO.
Eje 3.1 ADQUISICIÓN.

Determina el modelo de adquisición de los requisitos del cliente, si se basa en una
formulación contractualizada en forma rígida (con penalizaciones y métricas estrictas) o
está abierta a una dinámica de colaboración más flexible entre cliente y proveedor (por ej.
definición de capacidad fija y alcance negociado).
Eje 3.2 SEGUIMIENTO.

Determina el grado de colaboración entre el cliente y el equipo de trabajo de su proyecto.
Eje 3.3 SUMINISTRO.

Determina en qué medida la entrega del producto o servicio es completa o evolutiva.
Eje 3.4 REQUISITOS.

Determina si el modelo de adquisición cliente <-> proveedor se basa en requisitos
cerrados o evolutivos.
Eje 3.5 GESTIÓN.

Determina si la organización emplea un modelo de gestión de proyectos predictivo o
evolutivo.
Conocimiento profesional de las personas

Los procesos y la tecnología empleados por la ingeniería concurrente minimizan las
diferencias de calidad entre el trabajo realizado por personas con niveles de
conocimiento profesional diferentes. Sin embargo cuando las características del
producto o servicio no hacen posible explicitar el conocimiento necesario en los
procesos y la tecnología empleados, resulta necesario abordarlo desde la agilidad, y
en este tipo de trabajos basados en el conocimiento tácito de las personas, la
diferencia de resultados entre los mediocres y los mejores puede ser muy grande.
Al mismo tiempo, resulta difícil y cuestionable determinar la capacidad

profesional de las personas, por lo que una evaluación Scrum Level no aborda
su verificación.
27
Sin embargo en los procesos tanto de asesoría como de evaluación orientados a la

mejora de la agilidad se debe:
 Formar o informar de la relevancia de ese factor a las personas responsables

de la gestión de la organización.
 Las evaluaciones expertas pueden, y deben incluir ponderación sobre este
factor, si cuentan con información o evidencias que así lo aconsejan.
Análisis y valoración de la fluidez

El estudio de la fluidez se centra en el análisis y evaluación de los ejes orgánicos. El
nivel de agilidad de cada eje se determina combinando los valores verificados en el
rasgo no ágil y ágil que polariza el eje.
Rasgos
Escala
0. - Ausencia
Poca o ninguna presencia del rasgo.
1.- Presencia parcial

Presencia parcial del rasgo. No se puede verificar su aplicación sistemática, y ésta se
produce sólo puntualmente en áreas, equipos o momentos determinados.
2.-Presencia amplia
Presencia generalizada del rasgo. No se puede verificar que su aplicación se deba a la
institucionalización determinada de la dirección de la organización y / o que se aplique
en todas las ocasiones, pero es de aplicación generalizada.
3.-Presencia completa
Presencia permanente del rasgo. Se puede verificar que su aplicación se aplica en
todas las ocasiones, y que responde a una institucionalización determinada desde la
dirección de la organización.
Formulación de la fluidez
Una vez realizadas las verificaciones de los distintos ejes, el análisis de su
combinación determina la fluidez general de la organización.
Los tres principios que deben guiar el análisis son:
1.- Valores medios.

La fluidez de cada área refleja el promedio de la fluidez de los diferentes ejes que la
componen, y a su vez la fluidez global de la organización es reflejo del promedio de la
fluidez de las diferentes áreas.
Se debe considerar la media aritmética, y no la moda o la mediana.
28
2.- Homogeneidad.
La falta de homogeneidad entre los valores parciales, tanto entre los diferentes ejes de
una misma área, como entre los valores de las diferentes áreas, es síntoma de
tensiones o fricciones en la organización y disminuye, o incluso neutraliza los efectos
de scrum.
Cuando se produce, en la ponderación se deben analizar siempre las causas y

considerar la valoración de sus consecuencias.
3.- Ponderación
El análisis de la fluidez pondera los valores medios obtenidos considerando al menos:
 Las evaluaciones técnicas deben incluir criterios de formulación que consideren

el impacto atenuador generado por la falta de homogeneidad.
 Las evaluaciones expertas, a diferencia de las técnicas, son actuaciones
ágiles, y en ellas prevalece el criterio experto de la persona que realiza la
evaluación, por encima del criterio técnico de la formulación.
La ponderación de las evaluaciones expertas incluye el razonamiento y argumentación

de los ajustes realizados a los valores medios de la formulación.
Ejes orgánicos
La tabla siguiente refleja el criterio para determinar la fluidez de un eje, en base a la
valoración del rasgo ágil y no ágil que polariza.
Fluidez del eje Rasgo no ágil Rasgo ágil

0.- Muy baja 3 0
1.- Escasa * 1–2
2.- Parcial * 2-3
3.- Completa 0–1 3
Tabla 11. Escala de valoración de rasgos que definen la agilidad organizacional.
El carácter “*” representa a cualquier valor. La ponderación de la evaluación debe

considerar el principio de homogeneidad, y las posibles distorsiones motivacionales en
los resultados obtenidos con formularios o entrevistas.
Ejemplo de un posible resultado de la verificación de valores en los ejes del área de

gestión.
EJES DEL ÁREA DE GESTIÓN 0 1 2 3

1.1 Objetivo organizacional
1.2 Conocimiento: tipo
1.3 Conocimiento: distribución
1.4 Personas: gestión
1.5 Personas: motivación
1.6 Organización del trabajo
1.7 Gobernanza
1.8 Gestión del error
Tabla 12. Fluidez parcial por ejes de gestión.
29
Ejemplo de un posible resultado de la verificación de valores de cada área.
ÁREA 0 1 2 3
1.- Gestión
2.- Métodos
3.- Proyecto
Tabla 13: Fluidez parcial por ejes de gestión.
30
ANÁLISIS
La evaluación Scrum Level identifica y valora de forma estructurada la información
clave para el análisis en actividades de asesoría y mejora.
Las asesorías que toman como referencia el marco y los resultados de una evaluación
Scrum Level, deben:
Informar de la fiabilidad
La documentación de los procesos de asesoría o mejora debe indicar la fiabilidad de
los datos de la evaluación empleados:
Por un lado, si se realiza una evaluación con un protocolo que no incluye indicadores
de distorsión motivacional se debe indicar “Desconocida”; por el otro lado, si incluye
indicadores de distorsión motivacional se debe indicar la fiabilidad obtenida en la
evaluación: baja, media o alta.
Analizar los puntos de atención de la evaluación.

Además de los aspectos de análisis cubiertos por las circunstancias de la organización
y el criterio del asesor, no se deben omitir los puntos identificados en la evaluación
como “puntos de atención”.
Consideraciones
Objetividad en el tratamiento de la gestión predictiva y la gestión ágil.

En las referencias que el análisis pueda abordar sobre la gestión predictiva y la gestión
evolutiva, se recomienda un enfoque neutro y una consideración objetiva de cada una
de ellas respecto a las características de los productos y servicios desarrollados en la
organización o en sus diferentes áreas.
Diferenciar entre scrum, e ingeniería concurrente o agilidad técnica.

Analizar con objetividad la idoneidad de ingeniería concurrente o de agilidad, en
función de las características de la empresa y los productos o servicios que desarrolla.
No ofrecer de forma ambigua o confusa una mejora de ingeniería concurrente o

agilidad técnica, como mejora de Agilidad global o scrum.
31
Apéndices
Documento de evaluación.
El resultado de una evaluación Scrum Level se compone de un resumen o diploma, y
un informe de evaluación.
Contienen la siguiente información:
Información En el resumen o En el informe

diploma
Rango de la evaluación  
Tipo de evaluación  
Organización evaluadora (si procede) ( ) *
Evaluador responsable (si procede)  
Nivel de independencia (si procede)  
Protocolo empleado 
Organización evaluada  *
Categoría de la evaluación  
Ámbito (si procede) 
Dimensión o dimensiones  
Resultado de la evaluación  *
Resultados parciales 
Puntos de atención 
( ) Opcional |  * Información completa, además del nombre.
Rango de la evaluación
Con la indicación “Oficial”, “Independiente” o “Autoevaluación” según sea el caso.
Evaluador responsable Debe indicar

No certificado por Scrum Manager Independiente
Certificado por Scrum Manager Oficial
Sin evaluador (Evaluación técnica) Autoevaluación
Las evaluaciones oficiales son emitidas por Scrum Level.
Tipo de evaluación
Con la indicación “Experta” o “Técnica” según las valoraciones estén o no ponderadas
por el criterio experto de un evaluador responsable.
Organización evaluadora
No debe indicarse en las autoevaluaciones.
Las evaluaciones oficiales las debe realizar una organización evaluadora acreditada
por Scrum Level.
En el resumen o diploma:
 Nombre comercial de la organización evaluadora y razón social (en el caso de
que sean diferentes).
En el informe de evaluación:
32
 Nombre comercial de la organización evaluadora y razón social (en el caso de

que sean diferentes).
 Dirección completa: vía, ciudad, país y código postal.
 Teléfono y, o dirección de correo electrónico para contacto relacionado con las
evaluaciones Scrum Level.
 Persona de contacto para cuestiones relacionadas con la evaluación realizada.
Evaluador responable
No debe indicarse en las autoevaluaciones.
Nombre completo del evaluador
Nivel de independencia
Debe indicarse si la evaluación forma parte de un proceso de asesoría o mejora, o si
se ha realizado en la organización evaluada un proceso de asesoría en los 6 meses
previos a la evaluación.
Nivel 1.- Algún evaluador (responsable o auxiliar) ha participado también en el

proceso de asesoría.
Nivel 2.- Ni el evaluador responsable, ni los posibles evaluadores auxiliares han
participado en el proceso previo de asesoría.
Nivel 3.- Evaluación con nivel de independencia 2, realizada por una organización
distinta e independiente de la responsable de la asesoría previa.
Protocolo empleado
Nombre y versión del protocolo empleado para realizar la evaluación.
Organización evaluada
 Nombre comercial de la organización evaluada y razón social (en el caso de

que sean diferentes)
En el informe de evaluación:
 Nombre comercial de la organización evaluada y razón social (en el caso de

que sean diferentes)
 Dirección completa: vía, ciudad, país y código postal.
 Teléfono y, o dirección de correo electrónico para contacto relacionado con las
evaluaciones Scrum Level.
 Persona de contacto para cuestiones relacionadas con la evaluación realizada.
Categoría de la evaluación
Indicación de la categoría de la evaluación: 1, 2 o 3.
Categoría 1: El sistema está compuesto por un único equipo de personas, y puede

comprender un único proyecto o varios.
Categoría 2: El sistema está compuesto por más de un equipo de personas y más de
un proyecto. Todos los equipos y proyectos pertenecen a la misma unidad organizativa
(área, departamento o sucursal).
Categoría 3: El sistema incluye a más de una unidad organizativa (área, departamento
o sucursal) y cada una de ellas puede incluir un único o varios equipos y / o proyectos.
33
Ámbito de la evaluación
Opcional en evaluaciones de categoría 1
En evaluaciones de categoría 2: relación de proyectos y equipos objeto de evaluación.

En evaluaciones de categoría 3: relación de secciones o departamentos de la
organización objeto de evaluación, con indicación en cada uno de ellos de los
proyectos y equipos incluidos.
Dimensión
Indicación de una de las dos opciones de evaluación posibles:
 Técnica: La evaluación abarca la dimensión técnica.

 Técnica y organizativa: La evaluación abarca las dimensiones técnica y
organizativa.
Resultado de la evaluación
 Indicación del nivel alcanzado en la dimensión o dimensiones evaluadas:

insuficiente, apto o alto según el criterio de valoración.
En el informe de evaluación
 Indicación del nivel alcanzado en la dimensión, o dimensiones evaluadas: Bajo

o insuficiente, medio o alto, según el criterio de valoración.
 Valor numérico del nivel alcanzado en la dimensión, o dimensiones evaluadas,
con precisión de 2 decimales.
Si se evalúan las dos dimensiones (técnica y organizativa:

 Posición del valor en ambas dimensiones, representado sobre un gráfico de
coordenadas.
34
Resultados parciales
El informe de evaluación incluye los resultados parciales de las prácticas, y en su caso
rasgos que se han analizado.
Puntos de atención
El informe de evaluación incluye un apartado denominado “Puntos de atención” si en
la evaluación se detecta al menos alguna de las circunstancias siguientes:
 Falta de homogeneidad (desviación estándar poblacional > 1) entre los valores

de flexibilidad de las áreas de prácticas.
 Falta de homogeneidad (desviación estándar poblacional > 1) entre los valores
de fluidez de los ejes organizacionales.
 En la verificación del conocimiento técnico más del 50% de las personas que
forman parte del equipo de evaluación tienen valoración 0.
35
Protocolos
Un protocolo detalla la procedimentalización de un método específico para realizar una
evaluación conforme al modelo Scrum Level.
Los componentes de un protocolo son:
Componente
Guía del protocolo Siempre
Cuestionarios o listas de verificación Opcional
Herramientas de formulación Opcional
Formatos de documentación Opcional
Guía del protocolo

Incluye:
 Ficha técnica con:
o Nombre del protocolo.
o Versión.
o Validez.
o Derechos y / o licencia.
o Categoría o categorías de evaluación para las que es apto.
o Tipo o tipos de evalución para las que es apto.
 Exposición del método con explicación suficiente de su operativa y formulación.
Cuestionarios o listas de verificación.

Son componentes necesarios si el protocolo los emplea en verificaciones técnicas.
Incluyen instrucciones de usuario para su ejecución, e instrucciones de administración
y formulación, para el evaluador.
Herramientas de formulación
Los protocolos que incluyen verificaciones técnicas, pueden facilitar herramientas para
el cálculo de la formulación, tales como hojas de cálculo o aplicaciones de software.
Formatos de documentación
Formatos o modelos para la hoja o resumen diploma, y para el informe de la
evaluación.
36
Normas y restricciones para protocolos

El modelo Scrum Level es de uso libre como guía en procesos de asesoría y
evaluación.
El desarrollo de protocolos específicos para evaluaciones Scrum Level está también

liberado, si bien deben cumplir las siguientes normas y restricciones.
Validez:
Para incluir la indicación: “válido para evaluaciones Scrum Level” el protocolo debe ser
conforme formal y funcionalmente con las indicaciones de esta guía.
Para incluir la indicación “homologado por Scrum Level” es necesario solicitar y
obtener la evaluación del protocolo a Scrum Level.
Número de proyectos
El procedimiento definido por el protocolo debe exigir que el número de proyectos
incluido en las evaluaciones sea al menos el 33% de los que formen parte del ámbito
de la misma.
Número de personas
El número de personas incluidas en el equipo de evaluación debe ser al menos el 20%
de los implicados en el grupo evaluado e incluir todas las áreas de responsabilidad de
la organización.
Selección de proyectos y personas.

La selección de los proyectos que conforman el ámbito, y de las personas que forman
parte del equipo de evaluación, debe realizarse de forma aleatoria, o determinada por
el criterio de un evaluador (responsable o auxiliar) pero no son admisibles selecciones
realizadas por la organización evaluada.
37
Glosario
Términos que se muestran en la documentación de Scrum Level con tipografía
cursiva, cuando se emplean con el significado concreto aquí definido.
Ágil
Dicho de una técnica, procedimiento o método de trabajo o de gestión, indica que es
compatible con los principios del Manifiesto Ágil, y facilita la implantación de los
mismos en la organización.
Agilidad
Conjunto de características que definen los modelos organizativos basados en los
principios del Manifiesto Ágil.
Agilidad técnica.
Referida a un equipo u organización, indica que los procedimientos, tecnología y
técnicas de trabajo empleadas son adecuados para el desarrollo evolutivo de
productos o servicios con ciclos iterativos e incrementales y aplicación de ingeniería
concurrente.
Ámbito de la evaluación
En evaluaciones de categoría 2: relación de proyectos y equipos objeto de evaluación.
En evaluaciones de categoría 3: relación de secciones o departamentos de la
organización objeto de evaluación, con indicación en cada uno de ellos de los
proyectos y equipos incluidos.
Categoría (de evaluación)

Término que se aplica a un análisis o evaluación Scrum Level de una organización
para determinar su amplitud según el tamaño del sistema de personas y proyectos que
comprende.
Las categorías son:
Categoría 1 o “evaluación de equipo”: El sistema está compuesto por un único equipo

de personas, y puede comprender un único proyecto o varios.
Categoría 2 o “evaluación de departamento”: El sistema está compuesto por más de
un equipo de personas y más de un proyecto. Todos los equipos y proyectos
pertenecen a la misma unidad organizativa (área, departamento o sucursal).
Categoría 3 o “evaluación de empresa o corporación”: El sistema incluye a más de una
unidad organizativa (área, departamento o sucursal) y cada una de ellas puede incluir
un único o varios equipos y / o proyectos.
Conocimiento profesional
Conocimiento tácito relativo al cometido que la persona desempeña en la
organización. Es un factor del grado de fluidez.
Conocimiento técnico
Conocimiento de la tecnología, técnicas y métodos empleados en el trabajo. Es un
factor del grado de flexibilidad.
38
Distorsión motivacional
Indicador que detecta si la información facilitada por una persona a través de un
formulario o entrevista resulta poco fiable por estar distorsionada. La distorsión se
puede producir de forma intencionada por el entrevistado para aparentar o simular una
situación que no es real, o no intencionada por no comprender correctamente o
tergiversar las preguntas.
Eje orgánico
Elemento para la representación visual del punto de situación más o menos ágil que
muestra la organización en una determinada faceta.
Equipo de evaluación
Grupo de personas pertenecientes a la organización evaluada e implicadas en los
proyectos que forman parte del ámbito de una evaluación, y que participan en la
misma. Se refiere sólo a los miembros del grupo evaluado que participan en la
evaluación.
Evaluación experta
Evaluación dirigida por una persona que desempeña el rol y las responsabilidades de
evaluador.
Evaluación independiente
V. Rango.
Evaluación oficial
V. Rango.
Evaluación técnica
Evaluación sin rol de evaluador, procedimentada y verificada a través de formularios y
/ o aplicativos de evaluación. V- Tipo.
Evaluador auxiliar
Persona que auxilia al evaluador responsable.
Evaluador responsable
Persona que dirige una evaluación. En función del ámbito de la evaluación el
evaluador responsable puede hacerse auxiliar por evaluadores auxiliares.
Fiabilidad
Referido a una evaluación: Indicador del grado de confianza en la veracidad de los
datos empleados para la evaluación.
Flexibilidad
Medida que expresa el grado de agilidad técnica con el que la organización desarrolla
su trabajo
Fluidez
Medida que expresa el grado de agilidad en la dimensión cultural de la organización.
39
Formulación
Criterio para la cuantificación de la agilidad de un determinado parámetro.
Grupo evaluado
Todas las personas pertenecientes a la organización evaluada e implicadas en la
gestión o desarrollo de los proyectos que forman parte del ámbito de una evaluación.
A diferencia del equipo de evaluación, pueden participar o no en la evaluación.
Nivel de independencia
Parámetro aplicable a las evaluaciones en organizaciones que con carácter previo han
realizado actividades de asesoría o formación relacionadas con la evaluación.
Nivel 1.- Algún evaluador (responsable o auxiliar) ha participado en las actividades

previas de asesoría o formación.
Nivel 2.- Ni el evaluador responsable, ni los posibles evaluadores auxiliares han

participado en las actividades previas de asesoría o formación.
Nivel 3.- Además de cumplirse el nivel de independencia 2, las personas que han
participado en las actividades previas de asesoría o formación, y los evaluadores
pertenecen a organizaciones distintas, sin relaciones societarias o de colaboración.
Protocolo
Conjunto de instrucciones específicas de procedimiento y recursos diseñados para
guiar evaluaciones Scrum Level en un ámbito o ámbitos concretos, determinados por
el tamaño de la organización que se va a evaluar y el tipo de evaluación empleado.
Rango
Caracteriza a una evaluación, y puede ser:
Oficial: Si ha sido gestionada por un centro oficial de Scrum Level, y en ella ha
intervenido como evaluador responsable un evaluador certificado de Scrum Level.
Independiente: En caso contrario.
Rasgo
Cada una de las características propias de la organización que en su conjunto definen
su cultura y valores. En este sentido se puede considerar como rasgo de la
personalidad de la organización. Cada eje orgánico polariza en sus extremos dos
rasgos de características opuestas: uno de carácter ágil y otro no ágil.
Scrum
Scrum en su acepción amplia de conjunto de principios y valores de autoorganización
y desarrollo ágil.
Tipo (de evaluación)

Término que se aplica a un análisis o evaluación Scrum Level de una organización
para determinar si está dirigida por un evaluador o no. Los tipos posibles son: experta
(v. evaluación experta) y técnica (v. evaluación técnica)
40
Validez (de un protocolo)

Característica de un protocolo, que puede ser:
1.- Comprobada: el protocolo es formal y funcionalmente conforme con el modelo de
evalulación Scrum Level.
2.- Homologada: la validez del modelo ha sido revisada y aprobada por Scrum Level.
La indicación de validez debe incluir la versión de Scrum Level para la que ha sido
comprobada u homologada.
Verificación
Comprobación del valor de un determinado parámetro.
41
Verificación mixta
Verificación que basa sus resultados en la ponderación que el asesor o evaluador

realizar sobre los obtenidos con una verificación técnica previa.
Verificación pericial
Verificación realizada por el asesor o evaluador basada en su criterio experto.
Verificación técnica
Verificación basada en los resultados de un cuestionario o lista de comprobación.
42
Trabajos citados
Schwaber, K. (1995). SCRUM Development Process. OOPSLA 95 , 17.
Takeuchi, H., & Nonaka, I. (1986). The New New Product Development Game.
Cambridge: Harvard Business Review.
43
Índice
Ingeniería concurrente, 6, 9
Ingeniería de procesos, 9, 14
A Ingeniería secuencial, 13
agilidad técnica, 13
Agilidad técnica, 9, 31 K
Análisis, 31
Kanban, 11
C
M
Ciclo de vida, 10
Cliente, 11 Manifiesto Ágil, 6, 9
Conocimiento explícito, 13
Conocimiento tácito, 13
Conocimiento técnico, 20
N
Nonaka, 7
D
Dimensión (Scrum Level), 14, 17
O
OOPSLA, 8
E
Ejes orgánicos, 16, 25, 29
P
gestión, 26 Ponderación, 24, 29
métodos, 26 Prácticas ágiles, 10, 15, 17
proyecto, 27 Prácticas de organización, 19
Evaluación de la flexibilidad Prácticas de producción, 20
conocimiento técnico, 23 Prácticas de producto, 18
formulación, 24, 28 Prácticas de proyecto, 18
prácticas, 21 Producto mínimo viable, 10
Evaluación de la fluidez Protocolo, 40
rasgos, 28 componentes, 36
eXtreme Programming, 9 guía, 36
validez, 37, 40
F
Fiabilidad, 31
R
Flexibilidad, 14, 17 Rasgos, 16, 28
evaluación, 20 Rugby, 7
Fluidez, 14, 25
evaluación, 28
formulación, 28
S
Formulación Scrum, 7, 9
flexibilidad, 24 Scrum Alliance, 8
flexibilidad - prácticas, 24
T
G
Takeuchi, 7
Gestión ágil, 9, 31
Gestión evolutiva, 13
Gestión predictiva, 13, 31 V
Valores ágiles, 11
I
Independencia, niveles, 40
44

Guia Scrum Level

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Guia Scrum Level

Cargado por

Copyright:

Formatos disponibles

SCRUM LEVEL

Guía para evaluación de la agilidad

LOS AUTORES DE ESTE DOCUMENTO SON MIEMBROS Y COLABORADORES

Han hecho posible esta versión de Scrum Level:

Alexander Menzinsky, Claudia Ruata, José López

Imagen de portada cc by Tim Sheerman-Chase

Iubaris Info 4 Media SL es la propietaria de los derechos, y los libera en las

Derechos registrados en Safe Creative. Nº de registro : 1605097468864

Este modelo se ha desarrollado, y está en continua revisión y mejora, desde el

Propósito de este documento

Organización de esta guía:

El trabajo “en scrum” era el empleado en los departamentos de innovación y desarrollo

En 2001, diecisiete expertos en desarrollo de software, convocados por Kent Beck,

Manifiesto por el Desarrollo Ágil de Software

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra

Individuos e interacciones, sobre procesos y herramientas.

(2001) Manifesto for Agile Software Development

Las empresas que desarrollan productos, y tienen en la innovación su principal valor o

La incorporación de prácticas de ingeniería concurrente, o de agilidad, mejora el

La incorporación de los valores de la agilidad en la organización, mejora el valor

Adicionalmente mejora la reputación de la organización frente a los clientes que

NECESIDAD DE UN MARCO DE REFERENCIA

Scrum Level realiza una evaluación estructurada de la organización: de sus ejes

El resultado permite la medición y análisis de cada rasgo y práctica por separado, y de

Lo que entendemos por “scrum”

Figura 1. Formación de rugby scrum.

2.- Métodos de trabajo

Ambiente de trabajo ágil autoorganizado

En 1986 los investigadores Nonaka y Takeuchi

Metodología para desarrollo de software

Figura 3. Ken Schwaber, "Scrum Development Process”

Marco para desarrollo de software basado

Scrum Level usa el término en el significado original de Nonaka y Takeuchi, como un

En los últimos 20 años la agilidad ha demostrado que los marcos de desarrollo

El concepto de agilidad surgió al identificar en la industria manufacturera japonesa

Al mismo tiempo, en otra industria diferente: la del software, algunos equipos de

El Manifiesto para Desarrollo Ágil de Software, comúnmente llamado “Manifiesto ágil”,

Sintetiza los principios de agilidad proclamados como alternativa a la producción

Técnicas, prácticas y valores

 Las técnicas y prácticas empleadas para producir el resultado de forma

Figura 5. Agilidad técnica y scrum

Sin embargo, hay entornos profesionales donde la innovación y el ingenio son

La potencia de scrum radica en cómo gestiona el ciclo de vida de vida y la

Scrum no tiene como objetivo entregar el producto completo y terminado en el tiempo

Valor del producto

El valor del producto depende y es proporcional al conocimiento profesional de las

La gestión de un ciclo de vida que incremente el producto de forma continua e

Sin embargo la aportación del conocimiento necesario a través de las personas, no se

Los retos que plantea el ciclo de vida ágil son:

El conjunto de prácticas y técnicas ágiles proporciona el inventario de recursos

1.- Entrega de valor como objetivo.

2.- Trabajo en equipo.

3.- Excelencia profesional.

Implicación del cliente.

Si además se necesita potenciar el talento de las personas, también son necesarios

La comunicación e implicación del cliente con el equipo del producto es necesaria,

Si además no se trata de agilidad técnica, sino de agilidad, el equipo debe conocer y

Figura 6. Agilidad técnica y scrum

GESTIÓN DE PROYECTOS PREDICTIVA Y

Tiene como objetivo entregar el producto completo y terminado, velando por el

Figura 7. Ingeniería secuencial, ingeniería concurrente y scrum.

La gestión predictiva comienza con un plan de proyecto calculado a partir de la

La gestión evolutiva no parte de la descripción completa del producto sino de la visión

La gestión evolutiva puede confiar el conocimiento, el “saber hacer” necesario, al