IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
CURSO VIRTUAL
Scrum para proyectos
informáticos
Docente: Nicolás Carena
1 | ipap.gba.gob.ar
IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
MÓDULO 2
Scrum team y sus roles
2 | ipap.gba.gob.ar
IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
MÓDULO 2. Scrum team y sus roles
Los roles o responsabilidades de scrum: producto, desarrollo y funcionamiento.
Palacio1 advierte que el funcionamiento de scrum en la organización depende de tres
condiciones:
1. Características del entorno (organización y proyecto) adecuadas para desarrollo
ágil.
2. Conocimiento de la metodología de trabajo en todas las personas de la
organización y las implicadas del cliente.
3. Asignación de responsabilidades o roles:
a. Del producto.
b. Del desarrollo.
c. Del funcionamiento de scrum
Un equipo scrum (o scrum team) no suele tener más de diez personas, divididas entre
esos tres roles2.
El propietario de producto (también llamado dueño de producto o product owner) es
una única persona que desarrolla y comunica el objetivo del producto -nadie más define
requerimientos-, se responsabiliza del product backlog y de que el equipo siempre
aborde el trabajo de mayor valor posible para los usuarios o clientes. Conoce y
comprende el mercado y le encanta ofrecer los resultados que los clientes y los usuarios
desean y necesitan3. Es responsable de la financiación necesaria para el proyecto, de
decidir cómo debe ser el resultado final, del lanzamiento y del retorno de la inversión;
en desarrollos para clientes externos lo más aconsejable es que sea el responsable del
proceso de adquisición del cliente4. Además, los propietarios de productos exitosos
encarnan fuertes cualidades de liderazgo, que se caracterizan por habilidades de
comunicación excepcionales, empatía y adaptabilidad. Su capacidad para adaptarse a
las cambiantes necesidades de los clientes y la dinámica del sector industrial es clave,
pues se esfuerza por lograr productos que superen las expectativas.
Si bien puede delegar algunas tareas en el equipo, mantiene las responsabilidades:
1. Definen la visión del producto.
2. Gestionan el backlog del producto, asegurando que sea visible, transparente y claro
para todos -más para el equipo de desarrollo- y que muestra en qué se trabajará.
3. Equilibran necesidades y brechas entre interesados, clientes y desarrolladores.
4. Toman decisiones sobre compensaciones.
5. Establecen prioridades y toman decisiones sobre el alcance.
6. Maximizan el valor del producto.
7. Mantienen siempre al cliente en el centro de lo que hacen.
El equipo de desarrollo (o development team) está compuesto por profesionales, es
auto-organizado –nadie, ni siquiera el scrum master, indica al equipo de desarrollo cómo
convertir elementos de la product backlog en incrementos de funcionalidad
1
Palacio, J. (2008). Flexibilidad con Scrum. Principios de diseño e implantación de campos de Scrum.
https://es.slideshare.net/slideshow/flexibilidad-con-scrum-13580946/13580946
2
Kniberg, H. y Skarin, M. (2010). Parte I – Comparación. En Kniberg, H. y Skarin, M. (Eds.), Kanban y
Scrum – obteniendo lo mejor de ambos (pp. 11-13 y 29-31). Librería del Congreso.
3
Srinivasan, R. y Maloney, B. (31 de mayo de 2024). Acerca de scrum y ágil ¿Qué es el scrum?
ScrumAlliance®. https://www.scrumalliance.org/get-certified/product-owner-track/certified-scrum-
product-owner
4
Palacio (op. cit.)
3 | ipap.gba.gob.ar
IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
potencialmente desplegables-, multifuncional (las habilidades necesarias dependen del
tipo de producto); para esto son estructurados y empoderados por la organización,
mientras que la sinergia resultante optimiza la eficiencia y efectividad del equipo de
desarrollo. El equipo de desarrollo genera los incrementos del producto ‘terminado’ que
potencialmente se pueda poner en producción al final de cada sprint, y ejecuta con
trabajo colaborativo todos los aspectos del producto. Scrum no reconoce títulos ni sub-
equipos en los equipos de desarrollo. Según caracteriza Palacio, deben conocer la
metodología scrum y son los auténticos responsables -como equipo, no
individualmente- del resultado. El tamaño óptimo del equipo de desarrollo es, a decir
de Schwaber y Sutherland, lo suficientemente pequeño como para permanecer ágil y lo
suficientemente grande como para completar una cantidad de trabajo significativa;
debería balancear aspectos como interacción, productividad, limitaciones en
habilidades, coordinación y complejidad de gestión empírica.
El scrum master garantiza el funcionamiento de los procesos y metodologías que
emplea5. Entre sus tareas, se encuentran eliminar los impedimentos, proporcionar
liderazgo en el proceso, guiar y capacitar a la organización y a las partes interesadas en
la adopción y práctica de scrum, y ayudar a encarnar los principios ágiles. Asiste al
equipo y a sus integrantes para construir el producto y convertirse en el mejor equipo
posible: lo entrena al equipo en el uso eficaz de los eventos y artefactos6. Ayuda a las
personas externas al scrum team a entender qué interacciones con dicho grupo pueden
ser de ayuda y cuáles no; ayuda a todos a modificar estas interacciones para maximizar
el valor creado por el equipo scrum.
Si bien el rol puede ser a nivel de proyecto o a nivel de la organización; y en algunos
casos resultará más apropiado un rol exclusivo (tipo scrum master) y en otros, puede ser
mejor que las responsabilidades de funcionamiento las asuman los responsables del
área de procesos o de gestión de proyectos, Palacio hace dos sugerencias:
1. Que en lugar de una persona con la función de scrum master, sean las personas y
puestos más adecuados en cada organización los que reciban la formación adecuada y
asuman las funciones correspondientes para cubrir esta responsabilidad.
2. Que al compromiso de funcionamiento del proceso se sume la dirección de la
organización, con el conocimiento de gestión y desarrollo ágil, y facilitando los recursos.
A continuación, se enlistarán algunas tareas del scrum master:
Al dueño de producto lo asiste en: hallar técnicas para gestionar la lista de producto
de manera efectiva; ayudar al equipo scrum a entender la necesidad de contar con
elementos claros y concisos de dicha lista; comprender la planificación del producto en
un entorno empírico; garantizar que el dueño conozca cómo ordenar el product backlog
para maximizar el valor; entender y practicar la agilidad; y facilitar los eventos de scrum.
Da servicio al equipo de desarrollo al: guiarlo en ser auto-organizado y
multifuncional; asistirlo para crear productos de alto valor; eliminar impedimentos para
su progreso; facilitar los eventos de scrum; y conducirlo en organizaciones ajenas a
scrum.
Asiste a la organización al: liderarla y guiarla en la adopción de scrum; planificar las
implementaciones de dicho marco de trabajo; ayudar a los empleados e interesados a
5
Palacio (op. cit.)
6
Se otorga el mismo sentido al término ‘elementos de scrum’ que a ‘artefactos de scrum’, ya que ambos
términos son análogos en la bibliografía de la materia. Y se va a referir como tales a la lista de producto,
a la lista de pendientes y al incremento.
4 | ipap.gba.gob.ar
IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
entender y llevar a cabo esa metodología y el desarrollo empírico de producto; motivar
cambios que incrementen la productividad del scrum team; y trabajar con otros scrum
masters para incrementar la efectividad de scrum en la organización.
En el caso de un director de proyectos tradicional, muchas responsabilidades se dividen
entre las responsabilidades del equipo, mientras que otras responsabilidades de gestión
de proyectos pueden resultar innecesarias. Por ejemplo, el rol de jefe de proyectos
puede ser muy necesario en un proyecto grande, siendo quien ayuda a múltiples
equipos y dueños de producto a sincronizarse; en un proyecto pequeño puede ser un
desperdicio, dar lugar a la sub-optimización y la micro-gestión.
Pilares y valores del marco de trabajo ágil scrum.
Scrum se basa en el empirismo, que postula que el conocimiento procede de la
experiencia y de tomar decisiones basándose en lo que se conoce. Emplea un enfoque
iterativo e incremental para optimizar la predictibilidad y el control del riesgo. Ken
Schwaber y Jeff Sutherland7 identifican tres pilares soportan esta implementación:
1. Transparencia. En el proceso, los aspectos importantes y las tomas decisiones
deben ser visibles para los que son responsables del resultado y ser definidos por un
estándar común para que los observadores compartan un entendimiento.
2. Inspección. Los usuarios de scrum deben inspeccionar con frecuencia los
artefactos de scrum y el progreso hacia un objetivo para detectar desvíos; debe ser de
forma diligente por inspectores expertos en el mismo lugar de trabajo (no tan frecuente
como para interferir en el trabajo). La revisión y la planificación del sprint son una
oportunidad, así como las retrospectivas sobre trabajo en equipo, sus colaboraciones y
sus procesos. Así, se promueve la mejora continua y se garantiza un progreso sin frenos.
3. Adaptación. Si un inspector establece variaciones de límites aceptables en
aspectos de un proceso, y que el producto resultante no será aceptable, el proceso o el
material deben ser ajustados cuanto antes para minimizar desviaciones mayores. Los
equipos tienen flexibilidad para adaptar el product backlog, el producto y sus planes
futuros en cada sprint.
El Manifiesto Ágil, por su parte, menciona cuatro valores:
I. Los individuos y su interacción, por encima de los procesos y las herramientas
(o la tecnología). Si bien los procesos guían la operación y las herramientas mejoran la
eficiencia, sin personas con conocimiento técnico y actitud adecuada, no producen
resultados; en particular cuando los trabajos necesitan creatividad e innovación.
II. El software que funciona, por encima de la documentación exhaustiva. Ver antes
cómo se comportan las funcionalidades previstas, sobre prototipos o sobre partes ya
elaboradas del sistema final ofrece un feedback muy estimulante y enriquecedor, que
genera ideas y posibilidades; previo a comenzar el proyecto serían difícil de concebir e
incluir en un documento de requisitos detallados. Los documentos se consideran menos
trascendentales para aportar valor al producto, que se logra con la comunicación directa
entre las personas y a través de la interacción con los prototipos.
III. La colaboración con el cliente, por encima de la negociación contractual. Es un
miembro más del equipo, que se integra y colabora en el grupo de trabajo. Vale más en
productos difíciles de definir con detalle al principio o que tendrían menos valor que al
ir enriqueciendo la funcionalidad con la retroalimentación del desarrollo; o en los casos
7
Schwaber, K. y Sutherland J. (2014). La Guía de Scrum.
https://scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf
5 | ipap.gba.gob.ar
IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
de inestabilidad en los requisitos por la velocidad del entorno. Un contrato no aporta
valor al producto; expresa responsabilidades, requisitos, fechas y costos previstos.
IV. La respuesta al cambio, por encima del seguimiento de un plan. Para entornos
inestables, con cambios y evolución rápida y continua, aportan más valor las
capacidades de respuesta, la anticipación y la adaptación que las de planificación,
seguimiento y aseguramiento (control).
Además, scrum se basa en procesos de optimización continuos y empíricos, que
se corresponden con el principio Kaizen (mejora continua) de Lean.
Por otra parte, Srinivasan, R. y Maloney8 destacan otros valores de scrum que son
esenciales para construir una cultura ágil:
Compromiso. Los equipos de scrum deben colaborar y apoyarse en la búsqueda
del objetivo del producto y los objetivos del sprint. Y deben confiar entre sí para cumplir
con lo sus compromisos; ante dudas en el progreso del trabajo, preguntan. Solo aceptan
asumir tareas que consideran que pueden completar, sin comprometerse por demás.
Coraje. Los equipos deben ser seguros como para decir no, pedir ayuda y probar
innovaciones. Con valor, deben cuestionar el status quo si limita su capacidad de éxito.
Foco. Cada miembro se debe centrar en el trabajo para lograr el objetivo del
sprint.
Franqueza. Los equipos deben buscar de modo permanente nuevas ideas y
oportunidades de aprendizaje, ser honestos como para pedir ayuda y ser abiertos con
su equipo y los interesados sobre los retos a afrontar.
Respeto. Los miembros deben respetarse entre sí, al propietario del producto, a
los interesados y al scrum master, en cuanto a las ideas, conocimientos y capacidades
de los demás; admiten los errores y reconocen los logros ajenos: su fuerte es la correcta
colaboración y la diversidad de contribuciones.
Por último, Palacio agrega otros dos valores:
Delegación de atribuciones (empoderamiento) al equipo que le permita auto-
organizarse y tomar las decisiones sobre el desarrollo.
Responsabilidad y auto-disciplina (no disciplina impuesta).
Concepto de scrum team.
Los equipos scrum son auto-organizados y multifuncionales. Por un lado, seleccionan la
que consideran la mejor forma de efectuar su labor y quienes los dirigen son individuos
que pertenecen al mismo equipo. Por otro lado, en conjunto cuentan con las habilidades
requeridas para su trabajo sin depender de otras personas externas. De esta manera,
optimiza la flexibilidad, la creatividad y la productividad. Entregan productos
‘terminados’ de forma iterativa e incremental, maximizando las oportunidades de
obtener retroalimentación, de modo que siempre estará disponible una versión
potencialmente útil y funcional del producto.
Scrum es un sistema de planificación tipo ‘tirar’, principio de gestión de inventario ‘Just
In Time’ propio de Lean. El equipo elige cuándo y cuánto trabajo acometer; sus
componentes ‘tiran’ del trabajo cuando están listos (desde el exterior no se ‘empuja’ al
equipo a hacerlo).
Software, procesos y recursos (capital, humano, materia prima).
8
Srinivasan, R. y Maloney, B. (op. cit.).
6 | ipap.gba.gob.ar
IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
Siguiendo a Palacio, se puede observar que es factible producir más rápido, mejor y con
menores costos, porque la naturaleza del software y la manera en que se gestione su
desarrollo son factores de oportunidades y ventajas competitivas, antes que de riesgos
y problemas. No se trata de elegir la primera opción que se nos presente como ‘solución’
ni tampoco de perderse entre la multiplicidad de modelos de calidad, de procesos y de
técnicas de trabajo: “La evolución hacia entornos de ingeniería del software requiere (…)
sobre todo el diseño de un modelo de producción propio, que sepa aprovechar la
personalidad de la organización, y responder a las particularidades de su negocio”.
Respecto a los procesos, hay un continuo entre los extremos de no aplicar una
metodología y seguir alguna. A la primera alternativa, el Software Engineering Institute
(SEI) le atribuye el 1 en su escala de 1 a 5, que evalúa el grado de madurez de una
organización y la probabilidad resultante de garantizar calidad, predictibilidad en los
resultados y eficiencia en el desarrollo de software. Serían organizaciones ‘poco
maduras’, aunque no necesariamente significa que vayan a producir un mal producto,
sino que los resultados serán tan buenos como el ‘saber hacer’ de las personas que los
desarrollan y el cumplimiento de agendas dependerá de su capacidad de previsión y
organización; es la llamada ‘programación heroica’, tal como inician muchas start-up.
El reto de crecimiento que afrontan es pasar de un grupo de personas que saben hacer
software hacia una organización que sabe hacerlo produciendo de forma eficiente y
repetible en todos sus proyectos con resultados de calidad. Una de las herramientas
sugeridas para este desafío es la gestión por procesos, de la cual surgen cuatro factores:
1. Repetitividad de resultados. Cuando la calidad del resultado deriva del proceso,
la producción que aplica el mismo proceso garantiza la homogeneidad de los resultados.
2. Escalabilidad. Como consecuencia de la repetitividad, todos los equipos logran
resultados homogéneos en todos los proyectos, no sólo un equipo.
3. Mejora continua. Al aplicar procesos macros sobre los procesos de producción,
midiendo y analizando resultados, se alcanzan criterios de gestión para aplicar medidas
de mejora continua sobre la eficiencia y calidad de los procesos base y de los resultados.
4. Un know-how propio, una organización que ‘sabe hacer’, pues su modelo de
procesos contiene un activo valioso: la clave para hacer las cosas bien, de modo eficiente
y homogéneo.
Los procesos marcan pautas para realizar el trabajo, pero se requieren las personas y las
herramientas (tecnología) para producir resultados; sin estos últimos dos componentes
sería imposible -y sólo con estos dos plantearía limitaciones-. Sostiene Palacio: “en el
triángulo personas - procesos - tecnología cada elemento actúa con un peso específico,
diferente en función del tipo de producción, e incluso de las características de
personalidad de cada empresa”.
Para producir productos (bienes y/o servicios), una organización necesita dos tipos de
capitales, cuya influencia varía de acuerdo al sector de industria e, incluso dentro del
mismo sector, responde a cada organización en particular:
Cada organización deberá conocerse a sí misma y, en base a ello, analizar y
descubrir la potencia de cada uno de los tres elementos de la producción para
diseñar ‘su’ sistema de producción.
7 | ipap.gba.gob.ar
IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
Capital estructural: son los bienes de la organización excluyendo a las personas,
como edificios, patentes, licencias, cartera de clientes, equipos, maquinaria y vehículos.
Capital humano: es el valor que se emplea en el negocio y que es inseparable de
las personas.
En la ilustración de Palacio, las barras celestes representan el valor que suele aportar
cada elemento al sistema de producción como ventaja competitiva (y no un reto más
del negocio) para una organización determinada. Entre la variedad de combinaciones
posibles para cada negocio, factores como la innovación en la tecnología, en los
procesos o la formación del personal influyen en el potencial de cada elemento.
“La homogeneidad y calidad de los resultados, y la eficiencia del sistema en su conjunto
serán consecuencia del equilibrio logrado. (…) La clave del éxito es conseguir que cada
factor aporte al conjunto hasta el límite de su mejor relación eficiencia/calidad. En esta
tarea nunca está dicha la última palabra, y la labor de innovación constante en procesos
y tecnología puede ir ampliando los límites de valor a un factor, y dibujar un nuevo
equilibrio con mejores parámetros de eficiencia y calidad en el sistema”.
El autor pone de relieve cuatro características que diferencian a las organizaciones de
software a las de producción industrial, y a sus proyectos de los de ingenierías civiles:
Costo de la materia prima. Los recursos físicos necesarios para la construcción
de sistemas en ninguna ingeniería son despreciables, salvo en la de software.
Maleabilidad del producto. Como el software no es físico, la maleabilidad puede
ser muy alta como opción de desarrollo para efectuar ampliaciones y modificaciones del
sistema con técnicas de refactorización.
Maleabilidad y coste permiten plantear ciclos de construcción ágil, a pequeños
incrementos en iteraciones breves, durante las que se van refinando y descubriendo los
requisitos.
8 | ipap.gba.gob.ar
IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
Valor aportado por las personas. Sería mejor denominar procedimientos a los
procesos, que suelen ser una mezcla de procesos (conocimiento) o rutinas (ayuda) en
diversas proporciones. El factor de producción ‘personas’ combina ejecución y talento,
en distintas magnitudes según cada situación. Por ello, en algunas organizaciones se
puede gestionar a las personas con un departamento de recursos humanos, y en otras
con un departamento de gestión del conocimiento o del talento. Cuando el mayor
conocimiento reside en las personas, que aportan el talento, y los procedimientos en
son los que ayudan a las personas (rutinas), hay grandes diferencias de resultados entre
los mediocres y los mejores.
Factor de escala del producto. El software tiene un factor de escala
prácticamente infinito en cuanto a la inversión de desarrollo: cuesta lo mismo producir
uno que cien, mil, diez mil o millones.
“Si el producto necesita el máximo valor posible, un modelo de plan y requisitos
cerrados, para hacerlo bien a la primera, y evitar costes de modificaciones; puede
ser un ahorro miope. El cuestionamiento, los requisitos siembre abiertos, la
apertura al cambio, y la inyección de valor continuo durante todo el desarrollo son
una gran inversión”.
La flexibilidad y la gestión sistémica en la estrategia de scrum; los proyectos
tecnológicos de software.
Dado que no hay dos proyectos iguales (varían la estabilidad del entorno, la innovación,
la criticidad del producto a construir, la cultura organizacional, etc.), ni dos
organizaciones iguales, por lo tanto, no existe un modelo único o ‘bueno’ de gestión de
proyectos para el software. La flexibilidad se consigue al conocer las perspectivas
predictivas y ágiles, y emplear la más adecuada a las circunstancias de cada proyecto u
organización. El scrum manager debe tener experiencia de trabajo en su industria y, en
particular, combinar y emplear modelos y prácticas desde el conocimiento de su forma
y -especialmente- desde su fondo.
La organización es un sistema interrelacionado: cuanto más clara sea la definición de su
identidad con una visión y misión concretas, más coherentes y alineados estarán los
departamentos y las personas como un todo sistémico relacionado. El tipo de producto
o servicio que se desarrolla, los criterios para contratación de personal, el modelo de
calidad, las prácticas de programación, los procesos de presupuesto y contratación con
clientes forman parte del mismo sistema; en esa línea, la implementación de un modelo
de producción incumbe a toda la organización.
Scrum management es la estrategia de gestión que trabaja con la síntesis del
conocimiento desarrollado por:
1. Las teorías de agilidad, de cuales toma el patrón de campo de scrum como
ambiente para el desarrollo de los proyectos.
2. Las teorías de procesos, de donde toma los beneficios de la mejora continua y la
institucionalización de los procedimientos.
“De esa síntesis extrae que personas y procesos no son elementos simples, sino
combinaciones ejecución-talento, y de proceso-rutina, respectivamente; y con este
criterio base flexibiliza los procedimientos y las estrategias de gestión, adoptando el
grado más adecuado entre agilidad y disciplina para cada subsistema de la organización,
tras analizar cuánto tiene el factor ‘personas’ de ejecución y cuánto de trabajo; y qué
9 | ipap.gba.gob.ar
IPAP | Programa Organismos Provinciales
Scrum para proyectos informáticos
grado de proceso y de rutina tiene el factor ‘procedimiento’” describe Palacio, a la vez
que enuncia los criterios de síntesis:
Beneficio del trabajo en equipos pequeños: productividad, comunicación directa.
Desarrollo incremental e iterativo: producción frecuente de partes del producto que
puede evaluar el cliente, integración y pruebas tempranas.
Diseño de procesos o rutinas en función de la principal necesidad del proyecto:
previsibilidad o creatividad e innovación.
Grado de institucionalización de los procedimientos (procesos o rutinas) adecuado
al tamaño y previsión de crecimiento de la organización.
Gestión sistémica de la organización.
Scrum management es un modelo de gestión de conocimiento tácito. El gestor no
aporta ejecución para implantar un modelo, sino talento para desarrollar el propio.
10 | ipap.gba.gob.ar
