Está en la página 1de 24

Proceso y Roles de Scrum

El proceso

El desarrollo se realiza de forma iterativa e incremental. Cada iteracin, denominada Sprint, tiene
una duracin preestablecida de entre 2 y 4 semanas, obteniendo como resultado una versin del
software con nuevas prestaciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la
funcionalidad ya construida y se aaden nuevas prestaciones priorizndose siempre aquellas que
aporten mayor valor de negocio.

Product Backlog: Conjunto de requisitos demoninados historias descritos en un lenguaje no


tcnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversin
considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso
del proyecto a intervalos regulares.

Sprint Planning: Reunin durante la cual el Product Owner presenta las historias del backlog
por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a
completar en ese sprint, para en una segunda parte de la reunin, decidir y organizar cmo lo va a
conseguir.

Sprint: Iteracin de duracin prefijada durante la cual el equipo trabaja para convertir
las historias del Product Backlog a las que se ha comprometido, en una nueva versin del
software totalmente operativo.

Sprint Backlog: Lista de las tareas necesarias para llevar a cabo las historias del sprint.

Daily sprint meeting: Reunin diaria de cmo mximo 15 min. en la que el equipo se
sincroniza para trabajar de forma coordinada. Cada miembro comenta que hizo el da anterior, que
har hoy y si hay impedimentos.
Demo y retrospectiva: Reunin que se celebra al final del sprint y en la que el equipo
presenta las historias conseguidas mediante una demonstracin del producto. Posteriormente, en la
retrospectiva, el equipo analiza qu se hizo bien, qu procesos seran mejorables y discute acerca de
cmo perfeccionarlos.

Roles

En Scrum, el equipo se focaliza en construir software de calidad. La gestin de un proyecto Scrum se


centra en definir cules son las caractersticas que debe tener el producto a construir (qu construir,
qu no y en qu orden) y en vencer cualquier obstculo que pudiera entorpecer la tarea del equipo
de desarrollo.

El equipo Scrum est formado por los siguientes roles:

Scrum master: Persona que lidera al equipo guindolo para que cumpla las reglas y procesos de la
metodologa. Gestiona la reduccin de impedimentos del proyecto y trabaja con el Product Owner para
maximizar el ROI.

Product owner (PO): Representante de lso accionistas y clientes que usan el software. Se focaliza en la
parte de negocio y el es responsable del ROI del proyecto (entregar un valor superior al dinero invertido).
Traslada la visin del proyecto al equipo, formaliza las prestaciones en historias a incorporar en el Product
Backlog y las reprioriza de forma regular.

Team: Grupo de profesionales con los conocimientos tcnicos necesarios y que desarrollan el proyecto
de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint.

Los roles en Scrum


En este captulo, nos insertamos a fondo, en los roles propuestos por
Scrum. Hablaremos sobre el Dueo de Producto, el Scrum Master y el
Scrum Team. Cules son sus tareas y que aspectos deben cuidar cada uno
de los roles.
Introduccin

Comentamos en el captulo anterior que Scrum propone tres roles diferenciados que deben formalizarse:
Dueo de Producto (o Product Owner), Scrum Master y Scrum Team. Pero all, no termina. Scrum permite
adems, que todas aquellas personas que, ya sean inversores, interesados en el producto como usuarios, y
dems, formen parte del proyecto, respetando los roles formales, participando como audiencia.

Veamos entonces las caractersticas, funciones y aptitudes de cada rol en Scrum.

El Dueo de Producto (Product Owner) en Scrum


Caractersticas:
El Dueo de Producto es la nica persona autorizada para decidir sobre cules funcionalidades y
caractersticas funcionales tendr el producto. Es quien representa al cliente, usuarios del software y todas
aquellas partes interesadas en el producto.

Funciones y responsabilidades:

Canalizar las necesidades del del negocio, sabiendo "escuchar" a las partes interesadas en el producto y
transmitirlas en "objetivos de valor para el producto", al scrum team.
Maximizar el valor para el negocio con respecto al Retorno de Inversin (ROI), abogando por los intereses
del negocio.
Revisar el producto e ir adaptndole sus funcionalidades, analizando las mejoras que stas puedan otorgar
un mayor valor para el negocio.
Aptitudes que debe tener un Dueo de Producto:

Excelente facilicidad de comunicacin en las relaciones interpersonales


Excelente conocimiento del negocio
Facilidad para anlisis de relaciones costo/beneficio
Visin de negocios

El Scrum Master

Caractersticas:
El Scrum Master es el alma mater de Scrum. Un error frecuente es llamarlo "lder", puesto que el Scrum
Master no es un lder tpico, sino que es un un autntico Servidor neutral, que ser el encargado de fomentar
e instruir sobre los principios giles de Scrum.

Funciones y responsabilidades:

Garantizar la correcta aplicacin de Scrum. Esto incluye, desde la correcta trasmicin de sus principios a las
altas gerencias, hasta la prevencin de la inversin roles (es decir, guardar especial cuidado en que el dueo de
producto no acte en nombre del Scrum Team y viceversa, o que la audencia se inmiscuya en tareas que no le
son propicias)
Resolver los conflictos que entorpezcan el progreso del proyecto.
Incentivar y motivar al Scrum Team, creando un clima de trabajo colaborativo, fomentar la auto-gestin del
equipo e impedir la intervensin de terceros en la gestin del equipo.
Aptitudes que debe tener un Scrum Master:
Excelentes conocimientos de Scrum
Amplia vocacin de servicio
Tendencia altruista
Amplia capacidad para la resolucin de problemas
Analtico y observador
Saber incentivar y motivar
Capacidad docente e instructiva
Buen carisma para las negociaciones

El Scrum Team

Caractersticas:
El Scrum Team (o simplemente "equipo"), es el equipo de desarrolladores multidisciplinario, integrado por
programadores, diseadores, arquitectos, testers y dems, que en forma auto-organizada, ser los
encargados de desarrollar el producto.

Funciones y responsabilidades:

Llevar el Backlog de producto, a desarrollos potencialmente funcionales y operativos.


Aptitudes que deben tener los integrantes de un Scrum Team:
Ser profesionales expertos o avanzados en su disciplina
Tener "vocacin" (la buena predisposicin no alcanza) para trabajar en equipo
Capacidad de auto-gestin
Las habilidades de un ScrumMaster
Posted on 20/03/2014 por Maica Trinidad

Cuando hacemos Scrum definimos una serie de roles con diferentes


responsabilidades: el Product Owner, el ScrumMaster, los Stakeholders o el
Equipo.

De todos ellos, el ScrumMaster es el facilitador de todo el proceso. Debe cuidar


que se cumplan las reglas de Scrum, facilitar reuniones, formar y acompaar al
equipo y al Product Owner en el aprendizaje de la metodologa, eliminar
impedimentos, liderar un proceso de mejora continua, motivar
la participacin desde los valores giles y realizar todo un proceso gradual de
cambio de la cultura del trabajo.

El abanico de competencias que abarca es muy variado, incluye la experiencia


en desarrollo de software, la visin estratgica dentro de la compaa y la
capacidad de formar a otros profesionales. Pero adems, necesita dominar
habilidades interpersonales (o soft skills) que le ayuden en la gestin de las
personas y las dinmicas grupales.

Usando un ejemplo musical, en este vdeo, Bobby McFerrin representa a la


perfeccin el rol de ScrumMaster.

Los aspectos tcnicos de su actividad son la habilidad para construir una base rtmica
sobre la que el resto interpretarn la meloda y su capacidad para establecer el tempo y el
tono comn.

Sin duda alguna, el carisma de Bobby McFerrin tiene mucho que ver con el resultado, pero
este carisma procede, mayoritariamente, de su capacidad para captar y entender los
ritmos ajenos, ver el modo de conjuntarlos, anticipar el resultado y creer firmemente en
sus posibilidades de xito. A esto se le unen una serie de tcnicas como movimientos
corporales claros y precisos, correcta expresin verbal y no verbal, saber hacer crticas
constructivas, saber dar feedback, generar entusiasmo y celebrar los logros.

El resultado es una experiencia significativa de la que todos aprenden.

Puede parecer que el carisma es algo innato, sin embargo, responde al manejo correcto de
habilidades de relacin con los dems. En este sentido, los seres humanos somos muy
predecibles: seguimos con mayor facilidad a quienes nos caen bien. Y nos suelen caer
mejor aquellas personas animosas, incluso apasionadas, y al mismo tiempo consideradas,
capaces de escuchar y de mostrarse atentas con los dems, con su realidad y con sus
necesidades.
Todos poseemos unas habilidades ms marcadas que otras y siempre se nos presentarn
situaciones nuevas, y a veces inesperadas, en las que ponerlas a prueba y entrenarlas, pues
se trata de un aprendizaje continuo.

Pero, cul es la gama de habilidades interpersonales que el ScrumMaster debe conocer y


entrenar? Si las agrupamos por reas encontramos multitud de ellas:
Habilidades de comunicacin: lenguaje eficaz, escucha activa,
asertividad, dar y recibir feedback, saber decir no.
Habilidades de negociacin: solucin creativa de problemas,
resistencia a la frustracin, retraso de las gratificaciones, escucha activa,
mediacin, proactividad.
Habilidades de gestin de equipos: trabajo bajo presin, regulacin
de conflictos, construccin de equipos de trabajo, autorregulacin,
liderazgo, proactividad, aprendizaje continuo.
Habilidades de motivacin: habilidades de comunicacin,
responsabilidad personal y social, coherencia, visin estratgica, empata,
retraso de las gratificaciones, autonoma.

Como vemos algunas habilidades estn en ms de un rea, puesto que unas son la base de
otras. Por ejemplo, alguien que no maneje con soltura las habilidades de comunicacin,
contar con serias dificultades para afrontar un proceso de negociacin.
En la cspide hemos ubicado las habilidades de motivacin, para las que resultan
necesarias todas las anteriores, pero a las que hay que aadir la habilidad de que nuestra
comunicacin sea coherente con nuestras prcticas, la habilidad de empatizar con las
necesidades y expectativas de los dems y otras muchas que tienen que ver con la
responsabilidad personal, profesional y social de quien pretende ejercer un rol de
liderazgo y facilitacin. Algunas de ellas, como la humildad, rozan la franja de la actitud,
pero no dejan de ser necesarias para un motivador.

Tenemos una mala noticia y otra buena. La mala es que necesitars dominar todas estas
habilidades si pretendes ser un buen ScrumMaster. La buena es que existen tcnicas
concretas que ayudan a entender y a entrenar cada una de ellas. Con su conocimiento y
manejo irs encontrando otra forma de resolver situaciones.

Y como bonus otra buena noticia ms, todas las habilidades que fortalezcas en la bsqueda
de tu mejora profesional, te servirn para enriquecer las relaciones personales fuera del
trabajo.
Desarrollar este tipo de habilidades es el ejemplo perfecto de un aprendizaje
significativo, en el que estamos involucrados desde que nacemos y que no se termina
hasta el final de nuestra vida. La base sobre la que se construye este aprendizaje son
nuestras propias caractersticas personales, con nuestras debilidades y fortalezas. Slo
conociendo bien esa materia prima seremos capaces de sostener relaciones de calidad con
nuestro entorno. El primer paso nos remite al Orculo de Delfos: Concete a ti mismo.

Scrum Master: recopilacin de datos y


consideraciones importantes
En los ltimos muchos meses no dejan de llegarme correos sobre la figura del Scrum Master. Sobr su relacin con el jefe de
proyecto, las muchas certificaciones que hay, roles, responsabilidades, etc.

Aunque el tema ya lo hemos tratado en alguna ocasin, en su da incluso te dej una infografa que elaboramos sobre el rol del Scrum
Master (infografa que te he vuelto a dejar al final de este post, en el pie, por si quieres ir directo) recopilando las dudas ms
frecuentes, he querido elaborar este post para que aqu encuentres las dudas que ms me enviis sobre el Scrum Master.

Vamos a ello

Qu es un Scrum Master?
Empecemos por el principio. Casi tomando la definicin literal de las conversaciones de Jeff Sutherland (creador de Scrum), cuando
estuve con l en Estocolmo El Scrum Master es responsable de asegurar de que se cumplen los valores y las prcticas de Scrum
(por cierto, te dejo el link a la entrevista que hice a Jeff Sutherland por si te interesa)

El Scrum Master es el responsable de que la velocidad del equipo no se vea frenada por problemas en el proceso gil y de que los
problemas, obstculos, impedimentos, se resuelvan (no siempre de resolverlos l, si de preocuparse de que se resuelvan)
Hay quien al Scrum Master le llama el coach del equipo. Tambin hay quien conoce al Scrum Master como el protector del equipo y
del proceso gil. De ah, obviamente, que debe tener amplia formacin en agilidad y actualizarse frecuentemente.

El Scrum Master elimina obstculos que dificultan al equipo para lograr el objetivo del sprint. El Scrum Master potencia la
productividad.

Quin es el Scrum Master?


Resumidamente, el Scrum Master, es quien est capacitado para hacerse con lo anterior. Esta es la respuesta fcil.

Tpicamente, el Scrum Master es un perfil tcnico, un ex responsable tcnico o un ex jefe de proyecto (ahora hablaremos de el Scrum
Master y el jefe de proyecto).

El Scrum Mster y el Jefe de Proyecto


Es importante que recuerdes que en Scrum no hay un jefe de proyecto tradicional y el rol se divide en dos: Product Owner (si no
conoces el trmino aqu tienes una buena recopilacin sobre este rol) y Scrum Master.

Sin olvidar que parte de la responsabilidad recae sobre todos los miembros del equipo Scrum (recuerda que es auto-
organizado y multifuncional).

Por ello, pensar en el Scrum Master como el jefe de proyecto clsico es un error. En mi opinin, recae incluso ms responsabilidad de
las tradicionales del jefe de proyecto en el Product Owner que en el Scrum Master, por lo que, por cierto, pensar en el Product Owner
como un comercial es tambin un error (los comerciales son stakeholder canalizados por el Product Owner).

La autoridad del Scrum Master?


La autoridad del Scrum Master es sobre el proceso no directamente sobre el equipo (aunque luego a la hora de la verdad hay quien
acaba implementando el rol del Scrum Master de muchas maneras diferentes, recuerda que por encima de Scrum estn los valores
giles).

Puede el Scrum Master y el Product Owner ser la misma persona?


No es nada recomendable, normalmente esto termina en un jefe de proyecto clsico o en la tpica figura que hay en las consultoras,
un gerente comercial como responsable del equipo. Con el Scrum Master no queremos eso.

Buscamos equilibrar responsabilidades. El Product Owner trabaja desde la perspectiva del usuario final y el cliente, con el objetivo de
entregar el mayor valor y que se construya lo correcto. El Scrum Master es parte del equipo tcnico y busca que se cumpla el proceso
y eliminar problemas.

Como comenta Mike Cohn, autor de Succeeding with Agile: Software Development Using Scrum, es una mala idea combinar ambos
roles en una misma persona, debido a esa diferencia de intereses entre el Product Owner y el Scrum Master: si un Scrum Master
adopta tambin el rol de Product Owner, tender ms hacia la parte tcnica y dejar de lado ms a menudo las decisiones de negocio,
y viceversa.

Debe el Scrum Master tener dedicacin a tiempo completo?


Hablando siempre en trminos generales, ya te habl antes de las excepciones y que sobre Scrum estn los valores giles, lo normal
es que si, que el Scrum Master est dedicado a ser Scrum Master a tiempo completo.

Yo me encuentro mucho, pero mucho, que el Scrum Master es un ex programador que intenta dar el salto a Scrum Master (lo que
debe hacer ya te lo cont antes), pero que por unas o por otras al final no hace nada de Scrum Master y acaba programado de nuevo.
Con el problema aadido, repito, esto me lo encuentro demasiadas veces, de que el Product Owner si hace su trabajo y acaba
haciendo tambin el del Scrum Master. Problema.
Un Scrum Master para varios equipos?
Los terico puristas te dirn que un Scrum Master debe estar a tiempo completo para un solo equipo. En este ltimo punto yo soy
menos talibn y he visto trabajar bien a Scrum Master a tiempo completo dedicados a varios equipos.

Que impere la lgica y el sentido comn en este punto.

Qu papel juega el Scrum Master en las retrospectivas?


El Scrum Master se asegura de que se realiza la retrospectiva del sprint y de que los asistentes entienden el objetivo de la misma.

Adems, se encarga de que la reunin dure el tiempo estipulado (cosa que aplica a todas las reuniones) y anima al resto del equipo (l
colabora como un miembro del equipo ms) a analizar los errores del sprint y buscar formas de mejorar el proceso.

El Scrum Master, entre otros muchos, debe encargarse de que haya


una visin
La visin es el objetivo que gua al equipo, los miembros del equipo deben tener clara la visin.

Deca Ken Schwaber en Agile Project Management with Scrum, que lo mnimo necesario para empezar un proyecto Scrum es la
visin y el product backlog. La visin describe por qu se realiza el proyecto y qu es lo que se espera conseguir.

La visin del producto estar en el Product Backlog y en el objetivo del Sprint.

El Scrum Master debe asegurar que hay una visin, que se entiende y que se comparte.

Ms responsabilidades de un Scrum Master?


S, hay muchas, la anterior, o las anteriores, las destaqu aparte por ser las ms olvidadas.

En la infografa al final del post te dejo muchas otras responsabilidades y un resumen (pincha en la imagen para ampliarla).
Plantillas Scrum: historias de usuario y criterios de aceptacin

Imagen de: La Oficina de Proyectos de Informtica


Una de las principales innovaciones que representa el desarrollo gil frente a los enfoques tradicionales, es en la forma
de levantar los requerimientos del usuario.

A diferencia del enfoque tradicional, en el cual el Diseo de Sistema contiene documentacin detallada del
comportamiento y representa el final de las conversaciones, en las metodologas giles se hace uso de las Historias de
usuario, las cuales se enfocan en definir lo que el usuario necesita hacer, sin describir el cmo, por lo que representa el
inicio y no el final de las conversaciones.

En este artculo, presentamos una plantilla para documentar las historias de usuario, puede utilizarse en un marco de
trabajo de desarrollo gil (por ejemplo Scrum), e incluye la documentacin de los enunciados de las historias y los
criterios de aceptacin en una misma plantilla.

Est plantilla no pretende ser una Pila de Producto, por lo que no incluye su nivel de prioridad (La pila de producto
es otro documento).

El Rol de Scrum Master / lider de equipo


Publicado el 26 marzo 2011 por ngel

Esta semana haba una discusin interesante en Agile Spain y me di por resumir lo que, de alguna
forma, cuento en los cursos de Scrum sobre qu significa para mi el rol de Scrum Master. Creo que ha
quedado apaado, as que lo recojo aqu para que no se me pierda

El problema cuando hablamos del SM es que hay muchos tipos de SM. Para mi (o mejor dicho, en la
escuela de pensamiento en la que yo milito) el SM no es un estado, sino un camino. Este camino
tiene varios estados:

1. Scrunch Master El SM convoca las reuniones y poco ms. Como no tiene mucha dedicacin,
suele ser alguien que trabaja en el equipo y, a ratos, hace de SM. Quizs actua como portavoz del grupo.
Se habla de rotar el puesto de SM entre los miembros del equipo.
2. SM Mam: El SM comienza a tomar decisiones para el equipo en lo relativo a Scrum / Agile y a
los impedimentos a los que el equipo se enfrenta. Elimina impedimentos para el equipo en la forma de Ya
lo hago yo. Si el equipo o el P.O. no cumplen con alguna de sus responsabilidades tambin las asume l
(ya reporto yo en el tabln, ya escribo yo las historias de usuario). Mayordomo y secretaria del
equipo para que el equipo no se desconcentre y no pierda el tiempo, lnea de pensamiento preliminar en
las implementaciones que, si bien puede ser necesaria al principio, es peligrosa a largo plazo, ya que
puede conducir a que el equipo no sea convocado a las reuniones por lo mismo. Interlocutor / Interfaz del
equipo (misma consideracin respecto a peligrosidad en el largo plazo). Comienza a moderar las
reuniones. Es un avance respecto al Scrunch Master, pero no debera quedarse aqu.
3. Scrum Master: Facilita y dinamiza las reuniones. Acta de formador y mentor: ensea a cada uno
a ejecutar su papel dentro de Scrum. Evangeliza en la organizacin y en el equipo sobre las prcticas
giles, no solo Scrum (programacin por parejas, refactorizacin, TDD, propiedad colectiva de cdigo,
estimacin en puntos, planning poker, Kanban). Es un agente del cambio organizativo. Es un lider del
equipo. Mantiene y ejecuta con el equipo un plan de mejora continua. Diagnostica problemas y propone
soluciones.
4. Scrum Sensei / Agile Coach: Maestro de la escucha. Nunca decide ni sugiere soluciones: hace
preguntas. Pero son las preguntas correctas. Respeta las decisiones del equipo, pero hace al equipo
responsable de ellas. Ayuda al equipo a identificar problemas, descubrir soluciones e implementarlas por
ellos mismos. Trabaja aspectos como el trabajo en equipo, la comunicacin, la colaboracin Bajo su
influjo emergen equipos de alto rendimiento con el mximo nivel de compromiso, motivacin y
rendimiento.

DISCLAIMER: utilizar la estrategia del Agile Coach con un equipo principiante solo conduce al
desastre. Al igual que el SM, el equipo debe andar un camino.

Cul es el rol de un Scrum Master en un proyecto gil?


07/04/2014

Tips & Tricks.

Caminar sobre el agua y desarrollar software


a partir de una especificacin son fciles si
ambos estn congelados.
Edward V. Berard, ingeniero de software y
autor estadounidense.

Desde hace tiempo, he venido predicando y evangelizando acerca de las metodologas giles; especialmente
Scrum y Extreme Programming. Ahora bien, muchos de los nefitos suelen ser muy cautelosos y hasta
escpticos en cuanto a los beneficios que stas pueden aportar. Una de las preguntas ms comunes que he
escuchado, consiste en qu rol debe tomar un Scrum Master (SCM) como parte del proyecto gil; la gran
mayora cree que el SCM es un administrador de proyectos o lder tcnico, quien debe asumir la
responsabilidad sobre el proyecto y los integrantes del equipo, dirigiendo las tareas o asignando
responsabilidades durante de la ejecucin del mismo. Nada ms alejado de la verdad, ya que el SCM es el
guardin del proceso y no mucho ms. De hecho, si el equipo de trabajo ya cuenta con el conocimiento
necesario para llevar a cabo las ceremonias y generar los artefactos de manera adecuada, en cada ciclo o
iteracin de desarrollo es posible que el rol de Scrum Master sea tomado por algn miembro del equipo
diferente en cada ocasin; no necesariamente el responsable tcnico o el ms senior del grupo. Debido a esto,
presento a continuacin las tareas desempeadas por un SCM como parte de un proyecto, basndome en mi
propia experiencia durante estos ltimos aos:

Se coordina con el Product Owner (PO). Un Scrum Master debe trabajar en conjunto con el PO para facilitar
las actividades requeridas y cumplir con el release. Estas actividades incluyen aportar activamente durante la
priorizacin del backlog, rastrear actualizaciones relacionadas al sprint actual, alzar la mano cuando se detecte
algn riesgo, o trabajar con el PO para seleccionar los elementos a implementar durante el siguiente sprint.

Se convierte en el enlace entre el equipo de trabajo y el Product Owner. En muchas ocasiones, el PO es una
persona con un background de negocios, por lo que hablarle en bits y bytes puede convertirse en todo un reto;
esto es especialmente crtico, ya que para que Scrum sea exitoso, es necesaria una interaccin constante entre el
Product Owner y los desarrolladores. Por ello es importante que el Scrum Master mantenga a todos en sintona,
ya sea mediante sesiones grupales para aclaracin de dudas o reuniones uno a uno donde el Scrum Master
participa como moderador. De acuerdo a mi experiencia, el equipo usualmente pregunta poco durante la sesin
de planeacin del sprint, dejando casi todas las dudas para sesiones de preguntas y respuestas posteriores.
Entonces, es recomendable calendarizar este tipo de reuniones una vez que inicie el anlisis de historias de
usuario, incluso a manera de reverse knowledge transfer, en el que el desarrollador le explica al PO, en sus
propias palabras, qu es lo que entendi de la historia de usuario a implementar. As mismo, para evitar que una
sesin de este tipo se convierta en una reunin maratnica, es una buena idea acordar un tiempo fijo o timebox.
El SCM debe entonces evitar que la reunin se desve del tema principal y todos los involucrados vayan directo
al grano.

Facilita la demostracin del sprint y la retrospectiva. El SCM es usualmente el indicado para calendarizar y
facilitar la revisin al final del sprint, en la que los miembros del equipo muestran a los stakeholders el trabajo
terminado. Ya que seguramente los participantes harn preguntas y proporcionarn retroalimentacin al equipo,
el Scrum Master puede actuar como escriba o moderador. Para las retrospectivas, un SCM experimentado puede
ayudar a que los participantes se aflojen, para que las preguntas Qu sali bien? Qu sali mal? Cmo
podemos mejorar para la prxima en base a nuestras lecciones aprendidas? Puedan contestarse de forma
honesta y ordenada, ayudando a que el equipo se concentre en cmo mejorar, en vez de designar culpables. Para
proyectos pequeos o medianos en los que existan de uno a tres equipos de desarrollo, la revisin al final del
sprint as como la retrospectiva pueden realizarse de manera combinada mediante videoconferencia; cuando
el staffing del proyecto sobrepase ms de 30 participantes, es mucho ms cmodo que el equipo lder (Scrum de
Scrum Masters, Arquitecto Lder, Product Owner de Product Owners) sea la nica voz de cara a los
stakeholders; dejando a cada equipo hacer sus propias retrospectivas.

Protege al equipo del Product Owner. El Scrum Master debe impedir a como d lugar que el objetivo del
sprint cambie una vez que ha iniciado. Si el SCM se da cuenta que el PO est cambiando los objetivos a mitad
del sprint, su labor deber ser la de negociar con el Product Owner cmo intercambiar historias de usuario
equivalentes en esfuerzo de acuerdo a la prioridad de entrega, dejando las historias removidas de vuelta en
el product backlog para su posterior implementacin. Esto no es ideal, pero es bastante ms sano que cancelar el
sprint completo. Por otro lado, si esta re-priorizacin se vuelve la norma, es aconsejable adoptar un modelo
de Scrumban, en el que se acuerda con el PO limitar el monto de trabajo por fase (por hacer, en ejecucin,
terminado), permitiendo intercambiar las tareas o entregables en cualquier momento. Tambin es recomendable
aclarar con el Product Owner que este intercambio de tareas tiene un costo: el cambio de contexto o tiempo
mnimo necesario para cambiar de la tarea A a la tarea B, puede incrementar hasta en 24% el tiempo del
proyecto si se le usa de manera constante.

Representa al equipo en el Scrum de Scrums (SoS). Slo stakeholders de alto nivel participan en esta
reunin. Si el equipo tiene mltiples reuniones internas, tpicamente cada SCM representar a su equipo en un
SoS. El Scrum Master puede ir acompaado durante esta reunin, ya que cualquier miembro del equipo puede
proporcionar estas actualizaciones. Sin embargo, el SCM es quien debera saber lo que est pasando con su
equipo en todo momento, y debera estar al tanto de cualquier plan de accin que pretenda llevarse a cabo.
Durante el SoS es bastante comn que se discutan cuestiones de diseo tcnico as como reglas de negocio e
impedimentos que afecten al proyecto en su conjunto, tales como problemas de infraestructura y regulatorios.
Los participantes idealmente debern ser Scrum Masters, Product Owners, arquitectos, gerentes de proyecto,
etctera.

Facilita los daily standups. El scrum diario es una reunin en la que los miembros del equipo proporcionan
actualizaciones sobre su trabajo, comentando qu hicieron ayer, que piensan hacer hoy y qu obstculos se
encuentran en su camino. El SCM debe asegurarse que los standups tengan una duracin definida y que la
conversacin fluya correctamente es decir, evitar concentrarse en los detalles o permanecer demasiado tiempo
hablando acerca de un tema particular. Si es necesario, el Scrum Master puede tomar nota y calendarizar
sesiones adicionales para tratar temas puntuales.

Ayuda a remover impedimentos que bloqueen el trabajo del equipo. Esta es de hecho, la tarea ms
importante que debe desempear el Scrum Master. Si el equipo se enfrenta a un reto que impida entregar el
trabajo acordado, el SCM debe entender de qu se trata y cmo resolverlo, coordinndose con otros
stakeholders para despejar el camino. Si el problema est fuera de su jurisdiccin, es indispensable que el
Scrum Master escale el problema lo ms pronto posible.

Se convierte en un coach gil. En caso de que algn miembro del equipo no conozca del todo el proceso gil,
es responsabilidad del Scrum Master que todos aprendan y sigan las prcticas de la metodologa correctamente.

Tiene que hacer cumplir la definicin de Terminado. El SCM debe asegurarse que el equipo se adhiere a la
Definicin de Terminado; es decir, una lista previamente negociada y aceptada entre los integrantes del
equipo, en la que se define bajo qu criterios el trabajo es considerado como finalizado. Por ejemplo, (1) debe
cumplir con los criterios de aceptacin definidos en la historia de usuario, (2) las pruebas unitarias, de
integracin y de aceptacin deben haber sido terminadas, (3) deben existir cero defectos de severidad alta y (4)
la revisin de cdigo por algn colega debe haberse completado.

Facilita la sesin de planeacin. La sesin de planeacin es aquella en la que el equipo decide el objetivo del
sprint y cules elementos del Product Backlog sern seleccionados para implementarse durante la presente
iteracin. Usualmente durante los primeros sprints, el Scrum Master es quien definir o reforzar las reglas
del Planning Poker usado para dimensionar las historias de usuario en trminos de puntos de historia (por
ejemplo: la serie de Fibonacci o puntos perro).

Conclusiones

Aunque la mayora de las actividades que desempea un SCM han sido cubiertas en este post, pueden
presentarse muchas ms actividades que dependen de la naturaleza del proyecto. Por ejemplo, en un equipo de
desarrollo, el SCM era un excelente arquitecto en Java, por lo que adems de sus funciones como Scrum
Master, colabor con el lder tcnico del equipo para definir una arquitectura que fuese fcil de implementar y
mantener. Por otro lado, en un caso que me toc personalmente, en el que desempeando la labor de Scrum de
Scrum Masters, tambin tena que fungir como Program Manager, llevando el tracking de varios equipos y
proyectos operando simultneamente, comunicando el avance y problemas a la alta direccin mediante
presentaciones especialmente hechas para este fin as es, de esas con portafolios, semforos y tiburones
listos para desayunarse al presentador si ellos ven algo que no les gusta.
Lista de tareas de la iteracin (Sprint Backlog)
Lista de tareas que el equipo elabora en la reunin de planificacin de la iteracin (Sprint planning) como
plan para completar los objetivos/requisitos seleccionados para la iteracin y que se compromete
ademostrar al cliente al finalizar la iteracin, en forma de incremento de producto preparado para ser
entregado.

Esta lista permite ver las tareas donde el equipo est teniendo problemas y no avanza, con lo que le
permite tomar decisiones al respecto.

Para cada uno de los objetivos/requisitos se muestran sus tareas, el esfuerzo pendiente para finalizarlas y
la autoasignacin que han hecho los miembros del equipo.

El progreso de la iteracin y su velocidad con respecto a tareas u horas pendientes se muestra mediante
un grfico de trabajo pendiente (Burndown chart).

Uso de la lista

Los objetivos/requisitos estn ordenados por orden de prioridad para el cliente.


Por ello, signos de falta de foco, problemas o impedimentos seran que se estn
completando objetivos que no son los primeros de la lista, as como tener demasiados objetivos/requisitos
en progreso simultneamente.

Si una tarea depende de otra, se coloca en algn punto por debajo de la que depende.

Las tareas deben estar identificadas de manera que tengan un coste semejante para ser
completadas, entre 4 y 16 horas. Este tamao permitir:

Que las tareas sean suficientemente pequeas como para poder detectar progreso o
estancamiento de manera diaria.

Que las tareas no sean muy pequeas, que sean suficientemente relevantes, no generen ruido
ni microgestin.

Medir la velocidad de desarrollo del equipo y extrapolar si es posible finalizarlas dentro de la


iteracin.

El tablero de tareas (Scrum Taskboard)

La lista de objetivos a completar en la iteracin (Product Backlog Items) se puede gestionar mediante
un tabln de tareas (Scrum Taskboard). Al lado de cada objetivo se ponen las tareas necesarias para
completarlo, en forma de post-its, y se van moviendo hacia la derecha para cambiarlas de estado
(pendientes de iniciar, en progreso, hechas). Para cada miembro del equipo se puede utilizar
adhesivos de colores ms pequeos sobre cada tarea, de manera que se pueda ver en qu tareas
est trabajando cada cual.

El equipo elabora esta lista de tareas en la segunda parte de la reunin de planificacin de la iteracin. La
lista va evolucionando (nuevas tareas, cambios, estado, esfuerzo pendiente, ) a medida que la iteracin
avanza, especialmente durante la reunin diaria de sincronizacin.

Este tabln o cuadro de mandos acta como radiador de informacin tanto para el equipo como
para cualquier otra persona relacionada con el proyecto.

En el siguiente artculo se muestra cmo construirlo y un ejemplo de su uso: Ejemplo de uso del
tablero o pizarra de tareas (Scrum Taskboard).
Facilitador (Scrum Master)
Lidera al equipo llevando a cabo las siguientes responsabilidades:

Velar por que todos los participantes del proyecto sigan los valores y principios giles, lasreglas y
proceso de Scrum y guiar la colaboracin intraequipo y con el cliente de manera que las sinergias sean
mximas. Esto implica:

Asegurar que exista una lista de requisitos priorizada y que est preparada antes de la
siguiente iteracin.

Facilitar las reuniones de Scrum (planificacin de la iteracin, reuniones diarias de


sincronizacin del equipo, demostracin, retrospectiva), de manera que sean productivas y consigan sus
objetivos.

Ensear al equipo a autogestionarse. No da respuestas, si no que gua al equipo con


preguntas para que descubra por s mismo una solucin.

Quitar los impedimentos que el equipo tiene en su camino para conseguir el objetivo de cada
iteracin (proporcionar un resultado til al cliente de la manera ms efectiva) y poder finalizar el proyecto con
xito. Estos obstculos se identifican de manera sistemtica en las reuniones diarias de sincronizacin del
equipo y en las reuniones de retrospectiva.

Proteger y aislar al equipo de interrupciones externas durante la ejecucin de la


iteracin(introduccin de nuevos requisitos, "secuestro" no previsto de un miembro del equipo, etc.). De esta
manera, el equipo puede mantener su productividad y el compromiso que adquiri sobre los requisitos que
completara en la iteracin [notar, sin embargo, que el equipo debe reservar tiempo para colaborar con al
cliente en la preparacin de la lista de requisitos para la prxima iteracin].
Cmo funciona Scrum

Fundamentos de Scrum
Scum se basa en:

El desarrollo incremental de los requisitos del proyecto en bloques temporales cortos y


fijos (iteraciones de un mes natural y hasta de dos semanas, si as se necesita).

La priorizacin de los requisitos por valor para el cliente y coste de desarrollo en cada iteracin.

El control emprico del proyecto. Por un lado, al final de cada iteracin se demuestra al cliente el
resultado real obtenido, de manera que pueda tomar las decisiones necesarias en funcin de lo que
observa y del contexto del proyecto en ese momento. Por otro lado, el equipo se sincroniza diariamente y
realiza las adaptaciones necesarias.

La potenciacin del equipo, que se compromete a entregar unos requisitos y para ello se le otorga
la autoridad necesaria para organizar su trabajo.

La sistematizacin de la colaboracin y la comunicacin tanto entre el equipo y como con el cliente.

El timeboxing de las actividades del proyecto, para ayudar a la toma de decisiones y conseguir
resultados.

Estas prcticas se apoyan unas a otras y su seleccin tiene origen en un estudio de la manera de trabajar
de equipos altamente productivos.
Requisitos para poder utilizar Scrum
Los siguientes puntos son de especial importancia para la implantacin de una gestin gil de
proyectos como Scrum:

Cultura de empresa basada en trabajo en equipo, delegacin, creatividad y mejora continua.

Compromiso del cliente en la direccin de los resultados del proyecto, gestin del ROI y disponibilidad
para poder colaborar.

Compromiso de la Direccin de la organizacin para resolver problemas endmicos y realizar cambios


organizativos, formando equipos autogestionados y multidisciplinares y fomentando una cultura de gestin
basada en la colaboracin y en la facilitacin llevada a cabo por lderes al servicio del equipo.

Compromiso conjunto y colaboracin de los miembros del equipo.

Relacin entre proveedor y cliente basada en ganar-ganar, colaboracin y transparencia.

Facilidad para realizar cambios en el proyecto.

Tamao de cada equipo entre 5 y 9 personas (con tcnicas especficas de planificacin y coordinacin
cuando varios equipos trabajan en el mismo proyecto).

Equipo trabajando en un mismo espacio comn para maximizar la comunicacin.

Dedicacin del equipo a tiempo completo.

Estabilidad de los miembros del equipo

Cultura de empresa

La cultura de la empresa proveedora del proyecto debe estar alineada con la filosofa de una gestin gil de
proyectos como Scrum. Debe fomentar:

El trabajo en equipo y la colaboracin entre todas las personas implicadas en un proyecto.

Equipos autogestionados a los que se ha delegado la responsabilidad y autoridad para hacer su


trabajo, en contraposicin a la direccin y control de personas que ejercera un jefe de proyecto tradicional (en
lugar del jefe de proyecto existe la figura del Facilitador).

La creatividad del equipo.

La transparencia y la mejora continua, tanto del contexto de la organizacin y del proyecto y como
de las herramientas del equipo.

Scrum sistematiza la identificacin de obstculos que pueden impedir el correcto progreso del proyecto. Los
problemas previamente existentes en la organizacin (procesos, personas, herramientas, etc.) y que atentan
contra la productividad se harn ms evidentes cuando se aplique Scrum y ser necesario irlos solucionando.
Compromiso del cliente

Scrum exige del cliente una alta implicacin y una dedicacin regular:

El cliente tiene la responsabilidad de dirigir los resultados del producto o proyecto:

El cliente debe disponer de una visin de alto nivel del producto o proyecto y tener reflejadas
sus expectativas en forma de lista de requisitos priorizada donde ha indicado el valor que le aportar cada
uno. A partir de los costes de desarrollo que le proporcione el equipo, priorizar los requisitos en funcin
del Retorno de la Inversin (ROI) ms rpido.

El cliente replanifica el proyecto en cada iteracin para maximizar este ROI de manera
continua.

Al tratarse de un proyecto que va entregando resultados en iteraciones regulares, el cliente debe


colaborar participando en el inicio de cada iteracin (reunin de planificacin) y en el fin de cada iteracin
(demostracin), y debe estar disponible durante la ejecucin de cada iteracin para resolver dudas.

Compromiso de la Direccin

La Direccin debe estar comprometida y apoyar el uso de Scrum:

Se harn muy evidentes los obstculos ya existentes y por venir que impiden el correcto desarrollo
de los proyectos (a nivel de expectativas del cliente, productividad, calidad, etc.), sean organizativos, tcnicos,
procesos, relaciones entre personas/departamentos, habilidades de los equipos, etc.

Ser necesario tomar decisiones, realizar cambios organizativos, alinear a personas y proporcionar
recursos para hacer la transicin. Gestores y equipos debern desaprender formas de trabajar y de
relacionarse a las que estaban habituados y aprender nuevas dinmicas.

Un proyecto ya no consistir en que cada Departamento/rea/Unidad realice su parte del


trabajo y se la pase al siguiente. Ser necesario formar equipos autogestionados y
multidisciplinares capaces de conseguir un objetivo por ellos mismos.

Habr gestores que tendrn que cambiar sus roles para ser Facilitadores (Ver el artculo "El
buen gestor de un equipo gil") o Clientes, en una jerarqua de equipos haciendo Scrum de Scrums.

Se tendr que gestionar aquellas conductas personales que no permiten que otras personas
puedan aportar ideas sobre el qu y el cmo de un proyecto, que defienden a toda costa su parcela de
responsabilidad, que les cuesta mucho cederla al equipo y dejar de controlarlo, que no son capaces de
delegar tareas o de colaborar con otras personas en la resolucin de problemas.

Compromiso del equipo

Scrum se basa en el compromiso conjunto y la colaboracin entre los miembros del equipo.
La transparencia entre todos es fundamental para poder inspeccionar la situacin real del proyecto y as
poder hacer las mejores adaptaciones que permitan conseguir el objetivo comn. Por ello, ser difcil trabajar
utilizando Scrum para las personas que:
No confan en los dems, no permiten que otras personas puedan aportar ideas sobre el qu y el
cmo, no son capaces de colaborar en la resolucin de problemas ni de delegar tareas.

No son transparentes respecto a su trabajo personal, sea por que defienden a toda costa su parcela de
responsabilidad o por inseguridad para comunicarse o colaborar, cosa que no permite que sean ayudados.

Su modo de relacin se basa en la generacin de conflicto o bien evitan entrar en conflictos sanos en
que ambas partes ganen (ganar/ganar), con lo que los problemas realmente no se resuelven sino que crean
conversaciones veladas, de manera que estas personas no acaban de adquirir un compromiso real con el
equipo.

Priorizan su ego, sus intereses personales, de carrera o de departamento, por encima de los intereses
del equipo.

No son capaces de cambiar sus hbitos y salir de su zona de confort, tienen miedo al cambio,
prefieren que se les diga qu tienen que hacer o quieren decir a los dems qu tienen que hacer.

Quieren seguir siendo los hroes que solucionan los proyectos y/o las personas de las que depende la
empresa.

Relacin entre proveedor y cliente

La relacin entre el cliente y el proveedor del proyecto debe estar basada en el principio de ganar
ganar. En lugar de estar ligados por un contrato frreo de alcance, tiempo y coste, las dos partes asumen
que habr cambios para que cliente pueda obtener lo que realmente necesita, no lo que est escrito en un
documento inicial o seguir un plan inicial que vaya perdiendo su sentido. La relacin contractual se aproxima a
un contrato de un equipo por meses, donde el cliente dirige mes a mes los resultados que el proyecto debe ir
proporcionando.

Debe existir transparencia en la ejecucin del proyecto para facilitar esta relacin. Esta transparencia
la facilita de manera regular el propio proceso de Scrum, especialmente en la actividad de demostracin de
los requisitos completados al final de cada iteracin.

Facilidad para realizar cambios en el proyecto

Para poder utilizar Scrum se debe poder ir incorporando requisitos de manera incremental en el producto del
proyecto y realizar cambios de forma controlada sin un coste prohibitivo para el cliente. Para ello es necesario:

Disponer de tcnicas y herramientas que faciliten el crecimiento incremental y la introduccin de


cambios.

Mantener la simplicidad y calidad interna del producto que se est creando. Para cubrir los
requisitos actuales del cliente no hay que realizar ms esfuerzo del que sea necesario y, a la vez, se debe
vigilar no hacer nada en contra de futuros requisitos.

Dado que los requisitos se desarrollan priorizados por su valor, es ms improbable que ocurran cambios
sustanciales en los primeros requisitos desarrollados, cuando se construye la base del producto. Se fomenta
que los cambios que suelen aparecen cuando el proyecto ya est avanzado se realicen sobre requisitos que
no son tan importantes.
La arquitectura emerge conforme se va necesitando, iteracin a iteracin, con lo que se asegura que todo lo
que se disea se utiliza y se prueba.

Tamao del equipo

El tamao de un equipo est entre 5 y 9 personas. Por debajo de 5 personas cualquier imprevisto o
interrupcin sobre un miembro del equipo compromete seriamente el compromiso que han adquirido y, por
tanto, el resultado que se va a entregar al cliente al finalizar la iteracin. Por encima de 9 personas, la comunicacin
y colaboracin entre todos los miembros se hace ms difcil y se forma subgrupos.

De cualquier manera, se puede hacer Scrum con 3 personas y se ha utilizado en proyectos con 250 personas
en varios equipos. Cuando es necesario que ms de un equipo trabaje de manera gil en un mismo proyecto,
existen diferentes tcnicas que permiten esta colaboracin, desde el Scrum de Scrums hasta equipos de
integracin que dedican parte de su tiempo a trabajar con los equipos de desarrollo, siempre completando
incrementos de producto de manera regular, con el resultado integrado de los diferentes equipos.

Equipo trabajando en un mismo espacio comn

Todos los miembros del equipo trabajan en la misma localizacin fsica, para poder maximizar la
comunicacin entre ellos mediante conversaciones cara a cara, diagramas en pizarras blancas, tarjetas en el
tabln de tareas, etc. De esta manera se minimizan otros canales de comunicacin menos eficientes
(llamadas telefnicas, correos electrnicos, documentos, etc.), que hacen que las tareas se transformen en un
pasa pelota o que hacen perder el tiempo en el establecimiento de la comunicacin (como cuando se tiene
que llamar repetidas veces por telfono a una persona que no est en su puesto, o cuando se interrumpe con
una llamada telefnica a una persona que est concentrada en una tarea).

Dedicacin del equipo a tiempo completo

Los miembros del equipo dedicarse al proyecto a tiempo completo para de esta manera:

Evitar daar su productividad, que se vera afectada si tuviesen que ir cambiando de tarea para
diferentes proyectos o duplicando el nmero de reuniones para estos diferentes proyectos. Si el equipo est
dedicado a un nico proyecto es ms sencillo mantener el compromiso que adquiere en cada iteracin. Como
ayuda adicionala conseguir la mxima productividad, el Facilitador se encarga de proteger al equipo
de interrupciones externas.

Facilitar la gestin de recursos humanos de la organizacin. Esta gestin se simplifica si en la


organizacin las personas se reservan a un proyecto por iteraciones completas.

Por otro lado, el cliente y el facilitador deben estar dedicados al proyecto el tiempo necesario para cumplir con
sus responsabilidades.
Estabilidad del equipo

El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo mnimo posible, para
poder aprovechar el esfuerzo que les ha costado construir sus relaciones interpersonales, engranarse
y establecer su organizacin del trabajo.

También podría gustarte