Metodología scrum

1 Metodología SCRUM....................................................................................................3

1.1 Historia.............................................................................................................................3

1.2 Qué es Scrum....................................................................................................................4

1.3 Fundamentos....................................................................................................................51.3.1 Desarrollo iterativo e incremental...............................................................................................5

1.3.1.1 Beneficios............................................................................................................................61.3.1.2 Restricciones.......................................................................................................................81.3.1.3 Recomendaciones...............................................................................................................8

1.3.2 Priorización de los requisitos por valor y coste...........................................................................91.3.3 Control empírico........................................................................................................................101.3.4 Potenciación del equipo.............................................................................................................131.3.5 Colaboración y comunicación entre el equipo y con el cliente.................................................141.3.6 Timebox.....................................................................................................................................14

1.3.6.1 Ejemplos...........................................................................................................................151.3.6.2 Beneficios.........................................................................................................................151.3.6.3 Recomendaciones.............................................................................................................16

1.4 Requisitos para utilizar Scrum......................................................................................171.4.1 Cultura de empresa....................................................................................................................181.4.2 Compromiso del cliente.............................................................................................................181.4.3 Compromiso de la Dirección.....................................................................................................191.4.4 Compromiso del equipo............................................................................................................201.4.5 Relación entre proveedor y cliente............................................................................................211.4.6 Facilidad para realizar cambios en el proyecto.........................................................................211.4.7 Tamaño del equipo....................................................................................................................221.4.8 Equipo trabajando en un mismo espacio común.......................................................................221.4.9 Dedicación del equipo a tiempo completo................................................................................221.4.10 Estabilidad del equipo.............................................................................................................23

1.5 Beneficios de Scrum.......................................................................................................23

1.6 Cómo funciona Scrum....................................................................................................291.6.1 Proceso......................................................................................................................................29

1.6.1.1 Planificación de la iteración..............................................................................................301.6.1.2 Ejecución de la iteración....................................................................................................311.6.1.3 Inspección y adaptación.....................................................................................................31

1.6.2 Actividades................................................................................................................................321.6.2.1 Planificación de la iteración (Sprint Planning)..................................................................32

1.6.2.1.1 Beneficios..................................................................................................................331.6.2.2 Ejecución de la iteración (Sprint)......................................................................................34

1.6.2.2.1 Recomendaciones......................................................................................................341.6.2.2.2 Restricciones..............................................................................................................341.6.2.2.3 Terminación anormal de la iteración.........................................................................35

1.6.2.3 Reunión diaria de sincronización del equipo (Scrum Daily Meeting)..............................351.6.2.3.1 Beneficios..................................................................................................................361.6.2.3.2 Restricciones..............................................................................................................371.6.2.3.3 Recomendaciones......................................................................................................38

1.6.2.4 Demostración de los requisitos completados (Sprint Review)..........................................381.6.2.4.1 Beneficios..................................................................................................................381.6.2.4.2 Restricciones..............................................................................................................39

1.6.2.5 Retrospectiva (Sprint Retrospective).................................................................................391.6.2.5.1 Beneficios..................................................................................................................401.6.2.5.2 Restricciones..............................................................................................................40

1.6.2.6 Replanificación del proyecto.............................................................................................401.6.2.6.1 Beneficios..................................................................................................................41

1.6.3 Responsabilidades (Roles)........................................................................................................421.6.3.1 Cliente (Product Owner) ..................................................................................................421.6.3.2 Facilitador (Scrum Master)................................................................................................43

1.6.3.2.1 El buen gestor de un equipo ágil................................................................................44

1.6.3.3 Equipo (Team)...................................................................................................................481.6.3.3.1 Skills en un equipo ágil..............................................................................................50

1.6.3.3.1.1 Características de un equipo ágil.......................................................................511.6.3.3.1.2 Skills de un miembro de equipo ágil..................................................................54

1.6.4 Herramientas (Artefactos).........................................................................................................581.6.4.1 Lista de requisitos priorizada (Product Backlog)..............................................................581.6.4.2 Lista de tareas de la iteración (Sprint Backlog).................................................................621.6.4.3 Gráficos de trabajo pendiente (Burndown Chart)..............................................................64

1.7 Scrum vs. Metodologías Tradicionales.........................................................................65

1 Metodología SCRUM

1.1 Historia

El concepto se origina en la investigación de Takeuchi y Nonaka (1986), sobre

los procesos de desarrollo de los productos exitosos en Japón y los Estados

Unidos. Los desarrolladores de estos productos partían de requerimientos

generales que debían salir al mercado en menos tiempo del que se tardó en

lanzar productos anteriores. Todos los desarrolladores que se investigaron

seguían patrones similares en el desarrollo. Los investigadores compararon la

forma de de trabajo de estos equipos altamente productivos y multidisciplinares

con la colaboración entre los jugadores de Rugby y su formación de Scrum

(melé en español).

Según Sutherland et alter (1993), el primer Scrum para el desarrollo de

software se realizó en 1993, y en 1995 según Schwaber (1995), se formalizó el

proceso para la industria de desarrollo de software.

Desde 1995 miles de proyectos en todo el mundo han utilizado Scrum para el

desarrollo de productos, tanto en empresas pequeñas, “startups” con tan sólo 5

personas desarrollando un producto, como en multinacionales, entre las que se

encuentran las siguientes:

Tabla 1 Empresas que usan metodologías ágiles como Scrum

Sectores Ejemplos de empresas que utilizan metodologías

ágiles como Scrum

Media y

Telcomunicaciones

BBC, BellSouth, British Telecom, DoubleYou, Motorola,

Nokia, Palm, Qualcomm, Schibsted, Sony/Ericsson,

Telefonica I+D,TeleAtlas, Verizon

Software, Hardware Adobe, Autentia, Biko2, Central Desktop, Citrix, Gailén,

IBM, Intel, Microfocus, Microsoft, Novell, OpenView

Labs, Plain Concepts, Primavera, Proyectalis,

Softhouse, Valtech,VersionOne.

Internet Amazon, Google, mySpace, Yahoo

ERP SAP

Banca e Inversión Bank of America, Barclays Global Investors, Key Bank,

Merrill Lynch

Sanidad y Salud Patientkeeper, Philips Medical

Defensa y

Aeroespacial

Boeing, General Dynamics, Lockheed Martin

Juegos Blizzard, High Moon Studios, Crytek, Ubisoft, Electronic

Arts

Otros 3M, Bose, GE, UOC, Ferrari

Fuente: Xavier Albaladejo (2009)

En la actualidad, Scrum se está utilizando en diferentes tipos de negocio y,

especialmente, en el desarrollo de software. La Scrum Alliance es la

organización sin ánimo de lucro que se encarga de difundir Scrum en este

ámbito (Albaladejo, 2009).

1.2 Qué es Scrum

Scrum es un proceso en el que se aplican de manera regular un conjunto de

buenas prácticas para trabajar colaborativamente, en equipo, y obtener el

mejor resultado posible de un proyecto, especialmente combinadas para dar

soporte a la creación de productos innovadores y enfocar el trabajo del equipo

en producir valor directo para el cliente final. Estas prácticas se apoyan unas a

otras y su selección tiene origen en un estudio de la manera de trabajar de

equipos altamente productivos.

En Scrum se realizan entregas parciales y regulares del producto final,

priorizadas por el beneficio que aportan al receptor del proyecto. Por ello,

Scrum está especialmente indicado para proyectos en entornos complejos,

donde se necesita obtener resultados pronto, donde los requisitos son

cambiantes o poco definidos, donde la innovación, la competitividad, la

flexibilidad y la productividad son fundamentales.

Scrum también se utiliza para resolver situaciones en que no se está

entregando al cliente lo que necesita, cuando las entregas se alargan

demasiado, los costes se disparan o la calidad no es aceptable, cuando se

necesita capacidad de reacción ante la competencia, cuando la moral de los

equipos es baja y la rotación alta, cuando es necesario identificar y solucionar

ineficiencias sistemáticamente o cuando se quiere trabajar utilizando un

proceso especializado en el desarrollo de producto. (Albaladejo, 2009).

1.3 Fundamentos

1.3.1 Desarrollo iterativo e incremental

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).

En un desarrollo iterativo e incremental el proyecto se planifica en diversos

bloques temporales (en el caso de Scrum de un mes natural o hasta de dos

semanas, si así se necesita) llamados iteraciones.

Las iteraciones se pueden entender como miniproyectos: en todas las

iteraciones se repite un proceso de trabajo similar (de ahí el nombre “iterativo”)

para proporcionar un resultado completo sobre producto final, de manera que el

cliente pueda obtener los beneficios del proyecto de forma incremental. Para

ello, cada requisito se debe completar en una única iteración: el equipo debe

realizar todas las tareas necesarias para completarlo (incluyendo pruebas y

documentación) y que esté preparado para ser entregado al cliente con el

mínimo esfuerzo necesario. De esta manera no se deja para el final del

proyecto ninguna actividad arriesgada relacionada con la entrega de requisitos.

En cada iteración el equipo evoluciona el producto (hace una entrega

incremental) a partir de los resultados completados en las iteraciones

anteriores, añadiendo nuevos objetivos/requisitos o mejorando los que ya

fueron completados. Un aspecto fundamental para guiar el desarrollo iterativo e

incremental es la priorización de los objetivos/requisitos en función del valor

que aportan al cliente.

1.3.1.1Beneficios

• Se puede gestionar las expectativas del cliente (requisitos desarrollados,

velocidad de desarrollo, calidad) de manera regular, puede tomar

decisiones en cada iteración. Esto es especialmente interesante cuando:

o El cliente no sabe exactamente qué es lo que necesita, lo va

sabiendo conforme va viendo cuales son los resultados del

proyecto.

o El cliente necesita hacer cambios a corto plazo (nuevos requisitos

o a cambios en los ya realizados) por:

o Cambios en las condiciones del mercado (por un cambio

de necesidades, por un nuevo producto que ha lanzado la

competencia, urgencias).

o La reacción y aceptación del mercado respecto al uso de

los primeros resultados del proyecto.

o Cualquier cambio en el entorno (recursos, etc.), que pueda

incluso finalizar el proyecto manteniendo como mínimo los

resultados alcanzados hasta ese momento.

o El equipo necesita saber si lo que ha entendido es lo que el

cliente espera.

El cliente puede comenzar el proyecto con requisitos de alto nivel,

quizás no del todo completos, de manera que se vayan refinando en

sucesivas iteraciones. Sólo es necesario conocer con más detalle los

requisitos de las primeras iteraciones, los que más valor aportan. No es

necesario realizar una recolección completa y detallada de todos los

requisitos antes de empezar el desarrollo del proyecto.

El cliente puede obtener resultados importantes y usables ya desde las

primeras iteraciones.

Se puede gestionar de manera natural los cambios que van apareciendo

durante el proyecto. La finalización de cada iteración es el lugar natural

donde el cliente puede proporcionar su feedback tras examinar el

resultado obtenido Con esta información ya es posible planificar los

cambios necesarios para alinearse con las expectativas del cliente

desde las primeras iteraciones, de manera que al finalizar el proyecto el

cliente obtenga los objetivos esperados.

El cliente como máximo puede perder los recursos dedicados a una

iteración, no los de todo el proyecto.

La finalización de cada iteración es el lugar natural donde el equipo

puede decidir cómo mejorar su proceso de trabajo, en función de la

experiencia obtenida. Con esta información ya es posible planificar los

cambios necesarios para aumentar la productividad y calidad desde las

primeras iteraciones.

Permite conocer el progreso real del proyecto desde las primeras

iteraciones y extrapolar si su finalización es viable en la fecha prevista.

El cliente puede decidir repriorizar los requisitos del proyecto, añadir

nuevos equipos, cancelarlo, etc.

Permite mitigar desde el inicio los riesgos del proyecto. Desde la primera

iteración el equipo tiene que gestionar los problemas que pueden

aparecer en una entrega del proyecto. Al hacer patentes estos riesgos,

es posible iniciar su mitigación de manera anticipada.

Permite gestionar la complejidad del proyecto.

o En una iteración sólo se trabaja en los requisitos que aportan más

valor en ese momento.

o Se puede dividir la complejidad para que cada parte sea resuelta

en diferentes iteraciones.

Dado que cada iteración debe dar como resultado requisitos terminados,

se minimiza el número de errores que se producen en el desarrollo y se

aumentar la calidad.

1.3.1.2 Restricciones

• La disponibilidad del cliente debe ser alta durante todo el proyecto dado

que participa de manera continua:

o El inicio de una iteración, el cliente ha de detallar (o haber

detallado previamente) los requisitos que se van a desarrollar.

o En la finalización de cada iteración, el cliente ha de revisar los

requisitos desarrollados.

• La relación con el cliente ha de estar basada en los principios de

colaboración y ganar/ganar más que tratarse de una relación contractual

en la cual cada parte únicamente defiende su beneficio a corto plazo.

• Cada iteración debe dar como resultado requisitos terminados, de

manera que el resultado sea realmente útil para el cliente y no deje

tareas pendientes para futuras iteraciones o para la finalización del

proyecto.

• Cada iteración ha de aportar un valor al cliente, entregar unos resultados

cerrados que sean susceptibles de ser utilizados por él.

• Es necesario disponer de técnicas y herramientas que permitan hacer

cambios fácilmente en el producto, de manera que pueda crecer en cada

iteración de manera incremental sin hacer un gran esfuerzo adicional,

manteniendo su complejidad minimizada y su calidad.

1.3.1.3 Recomendaciones

• Utilizar iteraciones cortas de 2 a 4 semanas incrementa la productividad

del proyecto, dado que el equipo trabaja de forma más eficiente cuando

tiene objetivos a corto plazo. Asímismo, con iteraciones cortas la

precisión de las estimaciones aumenta. El tamaño depende de:

o Los condicionantes del proyecto.

o La necesidad de tener feedback más o menos rápido.

o Que no se degrade la relación trabajo útil / gestión operativa (por

ejemplo reuniones, actividades necesarias que no producen valor

directo, etc.).

• Utilizar iteraciones regulares, de manera que todas sean un timebox de

la misma duración.

o El equipo aprende a calcular la velocidad de desarrollo, la

cantidad de trabajo que puede hacer en una iteración (sin tener

que hacer extrapolaciones si las iteraciones no fuesen regulares).

o El cliente puede proyectar cuantas iteraciones se necesitan para

tener cada entrega, en función de la velocidad de desarrollo del

equipo (el trabajo que pudo completar en iteraciones anteriores

del mismo tamaño), y tomar decisiones al respecto.

o Permite gestionar y sincronizar de manera sencilla las

necesidades del proyecto con respecto a las de otros proyectos

(integración con el trabajo realizado por otros equipos,

compartición de personas que son difíciles de asignar a un único

equipo).

o Las iteraciones coincidiendo con meses naturales permiten

sincronizar el trabajo del equipo con el de otros departamentos y

con el resto de la organización (por ejemplo, la organización

puede tener medidas de resultados y objetivos a nivel trimestral o

cuatrimestral).

1.3.2 Priorización de los requisitos por valor y coste

La priorización de los requisitos por valor para el cliente y coste de desarrollo

en cada iteración.

Para que un proyecto proporcione el mejor resultado posible, y como soporte

fundamental al control empírico del proyecto, es necesario repriorizar los

requisitos de manera regular, cada iteración, según el valor que proporcionan al

cliente en ese momento y su coste estimado de desarrollo. Como resultado de

esta repriorización se actualiza la lista de requisitos priorizada (Product

Backlog).

Puede llegar a un punto en que no valga la pena desarrollar los requisitos

restantes, dado el poco retorno de inversión (ROI) que tienen.

1.3.3 Control empírico

El control empírico del proyecto. Por un lado, al final de cada iteración se

demuestra al cliente el resultado real obtenido, de manera que pueda tomar las

decisiones necesarias en función 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.

Asume que hay un horizonte de predicción de las variables del proyecto dado

que siempre hay cambios en el contexto del proyecto debido a la

indeterminación y complejidad propios. Para gestionar la complejidad y obtener

el mayor valor posible, el proceso de control del proyecto debe ser empírico,

basado en inspección y adaptación regular en función de los resultados que se

van obteniendo y del propio contexto del proyecto (de manera similar a como

funciona el control de procesos industriales, o siguiendo el ciclo de mejora

continua PDCA de Deming). Al cliente le resulta más sencillo ir entendiendo el

producto que necesita conforme se va desarrollando, cosa que le implica un

esfuerzo menor cada vez que debe tomar decisiones.

Como ejemplo de adaptación, los requisitos a desarrollar en la siguiente

iteración dependen del conocimiento que el cliente va adquiriendo acerca del

proyecto, de la velocidad de desarrollo, de las demandas del mercado, de los

movimientos de los competidores, etc. Los requisitos "emergen" y es necesario

adaptarse a ellos.

Aunque en principio parece que un control empírico tiene un coste adicional

respecto a utilizar un proceso predictivo, en proyectos complejos este coste se

ve compensado por evitar el gasto todavía mayor en que se incurre si al

finalizar el proyecto (en un proyecto tradicional en cascada) no se cumplen las

expectativas del cliente respecto a cómo se han desarrollado los requisitos del

producto o su calidad, lo cual obligaría a rehacer partes del producto,

incrementando el tiempo de entrega, aumentando su coste (para el proveedor

y/o para el cliente) y minando la relación cliente/proveedor.

En Scrum el control empírico del proyecto se aplica de manera regular

mediante las siguientes prácticas:

• El cliente aporta feedback del proyecto inspeccionando los resultados en

la demostración que se realiza al final de cada iteración. A partir de

datos objetivos realiza las adaptaciones necesarias en la lista de

requisitos priorizada.

• El equipo mejora de manera continua su metodología de trabajo y el

entorno del proyecto en la retrospectiva que se realiza al final de cada

iteración. Las tareas resultantes se incluyen en las planificaciones de las

siguientes iteraciones.

• Los miembros del equipo se comunican en cada reunión diaria de

sincronización para poder realizar las adaptaciones necesarias entre

ellos que permitan conseguir el objetivo de la iteración en curso y del

proyecto.

1.3.4 Potenciación del equipo

La potenciación del equipo, que se compromete a entregar unos requisitos y

para ello se le otorga la autoridad necesaria para organizar su trabajo.

1.3.5 Colaboración y comunicación entre el equipo y con el cliente

Scrum sistematiza la colaboración entre el cliente y el equipo:

• El equipo participa con el cliente en la creación de la lista de

objetivos/requisitos priorizada del producto o proyecto, en las reuniones

de replanificación del producto o proyecto, proporcionando la estimación

de su esfuerzo y aportando mejoras, nuevas ideas e innovación.

• En el inicio de cada iteración, en la reunión de planificación de la

iteración el equipo pregunta al cliente los detalles que pueda necesitar

de los requisitos para poder dimensionar mejor el contenido de la

iteración.

• Al finalizar cada iteración el equipo realiza una demostración al cliente

de los requisitos completados.

Scrum sistematiza la colaboración dentro del equipo mediante las siguientes

actividades:

• Reunión de planificación de la iteración

• Reunión diaria de sincronización del equipo

• Retrospectiva

También es de especial importancia que todo el equipo trabaje en un mismo

espacio abierto, de manera que se maximice la comunicación cara a cara.

1.3.6 Timebox

La técnica del timebox consiste en fijar el tiempo máximo para conseguir unos

objetivos, tomar una decisión o realizar unas tareas, y hacer lo mejor que

podamos en ese intervalo. De esta manera, en lugar de ponerse a trabajar en

algo hasta que esté hecho, de antemano se acuerda sólo se dedica un tiempo

limitado.

La consciencia de esta limitación temporal favorece la priorización de

objetivos/tareas y fuerza la toma de decisiones.

1.3.6.1 Ejemplos

• Limitar el tiempo a dedicar en la búsqueda de información para elaborar

un artículo.

• Todas las actividades de Scrum: la reunión de planificación de la

iteración (Sprint planning), la ejecución de la iteración (Sprint), la reunión

diaria de sincronización del equipo (Scrum daily meeting), la

demostración de los requisitos completados (Sprint Demostration) y la

Retrospectiva (Sprint Retrospective).

1.3.6.2 Beneficios

• Productividad, efectividad y creatividad

o Se prioriza los objetivos o tareas más importantes a realizar.

o Timebox da soporte al lema “lo perfecto es enemigo de lo bueno”.

Dado que existe una tendencia a ocupar todo el tiempo disponible

para conseguir un objetivo, sean 2 días o una semana (ley de

Parkinson), con un timebox las personas trabajan más enfocadas

y de manera más eficiente, al existir una fecha límite a corto plazo

para entregar un resultado. Similarmente, el timebox ayuda a

eliminar los procesos, tareas y “adornos” no necesarios.

o Aumenta la creatividad y fuerza a tomar decisiones para que las

cosas estén hechas al final del timebox. Evita “dejar las cosas

para el final”.

• Aprendizaje

o Timebox ayuda a aprender cuánto tiempo es necesario para

hacer una tarea.

o La finalización del timebox es el momento ideal para obtener

feedback del trabajo realizado (como por ejemplo en la

demostración de los requisitos completados en una iteración):

¿los objetivos conseguidos son suficientes, se cumplen las

expectativas, o bien es necesario un nuevo timebox para

profundizar más o conseguir nuevos objetivos?

1.3.6.3 Recomendaciones

• Objetivos claros y realizables

o Los objetivos y resultados entregables deben estar claros para

que al final del timebox se pueda demostrar que se ha

conseguido el resultado esperado.

o Sólo se deben escoger objetivos que se puedan completar en el

timebox. Alternativamente, el tiempo elegido de timeboxing debe

ser suficiente para poder conseguir estos objetivos; antes de

iniciar el timebox, se debe planear las tareas a realizar para poder

conseguir los objetivos esperados y estimar su coste temporal

(por ejemplo en la reunión de planificación de la iteración).

o Las herramientas con que realizar las tareas deben ser

conocidas.

• Tiempo y recursos fijos, objetivos variables.

o El tiempo y los recursos (por ejemplo, las personas dedicadas)

son fijos, mientras que los objetivos son reducibles. En caso de

no estar llegando a lograr todos los objetivos, se reduce su

número de manera que los objetivos que sí se consiga al final del

timebox mantengan una calidad determinada y se pueda

demostrar que se han completado. Como complemento a este

planteamiento, es importante que los objetivos estén priorizados

por el valor que aportan, de manera que queden sin completar los

menos importantes.

• Sin interrupciones

o Para poder lograr los objetivos acordados, mientras se está

trabajando en el timebox se debe impedir las interrupciones

externas, de manera que se mantenga la concentración y la

productividad (una de las tareas del Scrum Master dentro de la

ejecución de una iteración).

o En caso de que las interrupciones externas (o entrada de nuevos

objetivos) sean habituales, el timebox puede ser suficientemente

pequeño como para permitir que estas interrupciones puedan

esperar a la finalización del timebox para ser atendidas (o iniciar

su desarrollo).

• Equipo de tamaño suficiente

o El tamaño del equipo debe ser suficiente para reducir el impacto

de imprevistos (como una petición externa no alineada con los

objetivos del timebox, o la enfermedad repentina de un miembro

del equipo) de manera que no se comprometan seriamente los

objetivos del timebox.

1.4 Requisitos para utilizar Scrum

Los siguientes puntos son de especial importancia para la implantación de una

gestión ágil de proyectos como Scrum:

• Cultura de empresa basada en trabajo en equipo, delegación,

creatividad y mejora continua.

• Compromiso del cliente en la dirección de los resultados del proyecto,

gestión del ROI y disponibilidad para poder colaborar.

• Compromiso de la Dirección de la organización para resolver problemas

endémicos y realizar cambios organizativos, formando equipos

autogestionados y multidisciplinares y fomentando una cultura de

gestión basada en la colaboración y en la facilitación llevada a cabo por

líderes al servicio del equipo.

• Compromiso conjunto y colaboración de los miembros del equipo.

• Relación entre proveedor y cliente basada en ganar-ganar, colaboración

y transparencia.

• Facilidad para realizar cambios en el proyecto.

• Tamaño de cada equipo entre 5 y 9 personas (con técnicas específicas

de planificación y coordinación cuando varios equipos trabajan en el

mismo proyecto).

• Equipo trabajando en un mismo espacio común para maximizar la

comunicación.

• Dedicación del equipo a tiempo completo.

• Estabilidad de los miembros del equipo.

1.4.1 Cultura de empresa

La cultura de la empresa proveedora del proyecto debe estar alineada con la

filosofía de una gestión ágil de proyectos como Scrum. Debe fomentar:

• El trabajo en equipo y la colaboración 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 contraposición a la dirección y

control de personas que ejercería 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

organización y del proyecto y como de las herramientas del equipo.

Scrum sistematiza la identificación de obstáculos que pueden impedir el

correcto progreso del proyecto. Los problemas previamente existentes en la

organización (procesos, personas, herramientas, etc.) y que atentan contra la

productividad se harán más evidentes cuando se aplique Scrum y será

necesario irlos solucionando.

1.4.2 Compromiso del cliente

Scrum exige del cliente una alta implicación y una dedicación regular:

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

proyecto:

o El cliente debe disponer de una visión 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 función del Retorno de la

Inversión (ROI) más rápido.

o El cliente replanifica el proyecto en cada iteración 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

iteración (reunión de planificación) y en el fin de cada iteración

(demostración), y debe estar disponible durante la ejecución de cada

iteración para resolver dudas.

1.4.3 Compromiso de la Dirección

La Dirección debe estar comprometida y apoyar el uso de Scrum:

• Se harán muy evidentes los obstáculos ya existentes y por venir que

impiden el correcto desarrollo de los proyectos (a nivel de expectativas

del cliente, productividad, calidad, etc.), sean organizativos, técnicos,

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 transición.

Gestores y equipos deberán desaprender formas de trabajar y de

relacionarse a las que estaban habituados y aprender nuevas dinámicas.

o 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.

o Habrá gestores que tendrán que cambiar sus roles para ser

Facilitadores o Clientes, en una jerarquía de equipos haciendo

Scrum de Scrums.

o Se tendrá que gestionar aquellas conductas personales que no

permiten que otras personas puedan aportar ideas sobre el qué y

el cómo 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 resolución de problemas.

1.4.4 Compromiso del equipo

Scrum se basa en el compromiso conjunto y la colaboración entre los

miembros del equipo. La transparencia entre todos es fundamental para poder

inspeccionar la situación real del proyecto y así poder hacer las mejores

adaptaciones que permitan conseguir el objetivo común. Por ello, será difícil

trabajar utilizando Scrum para las personas que:

• No confían en los demás, no permiten que otras personas puedan

aportar ideas sobre el qué y el cómo, no son capaces de colaborar en la

resolución 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 relación se basa en la generación 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 hábitos 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 demás qué tienen que hacer.

• Quieren seguir siendo los héroes que solucionan los proyectos y/o las

personas de las que depende la empresa.

1.4.5 Relación entre proveedor y cliente

• La relación 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 férreo 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 relación 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 ejecución del proyecto para facilitar

esta relación. Esta transparencia la facilita de manera regular el propio

proceso de Scrum, especialmente en la actividad de demostración de los

requisitos completados al final de cada iteración.

1.4.6 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 técnicas y herramientas que faciliten el crecimiento

incremental y la introducción 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 más 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 más

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, iteración a iteración, con

lo que se asegura que todo lo que se diseña se utiliza y se prueba.

1.4.7 Tamaño del equipo

El tamaño de un equipo está entre 5 y 9 personas. Por debajo de 5 personas

cualquier imprevisto o interrupción 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 iteración. Por encima de 9 personas, la

comunicación y colaboración entre todos los miembros se hace más difícil 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

más de un equipo trabaje de manera ágil en un mismo proyecto, existen

diferentes técnicas que permiten esta colaboración, desde el Scrum de Scrums

hasta equipos de integración 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.

1.4.8 Equipo trabajando en un mismo espacio común

Todos los miembros del equipo trabajan en la misma localización física, para

poder maximizar la comunicación entre ellos mediante conversaciones cara a

cara, diagramas en pizarras blancas, tarjetas en el tablón de tareas, etc. De

esta manera se minimizan otros canales de comunicación menos eficientes

(llamadas telefónicas, correos electrónicos, documentos, etc.), que hacen que

las tareas se transformen en un “pasa pelota” o que hacen perder el tiempo en

el establecimiento de la comunicación (como cuando se tiene que llamar

repetidas veces por teléfono a una persona que no está en su puesto, o cuando

se interrumpe con una llamada telefónica a una persona que está concentrada

en una tarea).

1.4.9 Dedicación del equipo a tiempo completo

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

esta manera:

• Evitar dañar su productividad, que se vería afectada si tuviesen que ir

cambiando de tarea para diferentes proyectos o duplicando el número

de reuniones para estos diferentes proyectos. Si el equipo está dedicado

a un único proyecto es más sencillo mantener el compromiso que

adquiere en cada iteración. Como ayuda adicional a conseguir la

máxima productividad, el Facilitador se encarga de proteger al equipo de

interrupciones externas.

• Facilitar la gestión de recursos humanos de la organización. Esta gestión

se simplifica si en la organización 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.

1.4.10 Estabilidad del equipo

El equipo debe ser estable durante el proyecto, sus miembros deben cambiar

lo mínimo posible, para poder aprovechar el esfuerzo que les ha costado

construir sus relaciones interpersonales, engranarse y establecer su

organización del trabajo.

1.5 Beneficios de Scrum

Los principales beneficios que proporciona Scrum son:

• Entrega mensual (o quincenal) de resultados (los requisitos más

prioritarios en ese momento, ya completados) lo cual proporciona las

siguientes ventajas:

o Gestión regular de las expectativas del cliente y basada en

resultados tangibles.

o Resultados anticipados (time to market).

o Flexibilidad y adaptación respecto a las necesidades del cliente,

cambios en el mercado, etc.

o Gestión sistemática del Retorno de Inversión (ROI).

o Mitigación sistemática de los riesgos del proyecto.

• Productividad y calidad.

• Alineamiento entre el cliente y el equipo de desarrollo.

• Equipo motivado.

A continuación se detalla de qué manera Scrum permite conseguir cada uno de

los beneficios anteriores:

Beneficios de Scrum Cómo se consiguenGestión regular de las

expectativas del cliente

El cliente establece sus

expectativas indicando el valor que

le aporta cada requisito del

proyecto y cuando espera que esté

completado.

Lista de requisitos priorizada

El cliente crea y gestiona la lista de

requisitos del producto o proyecto, donde

quedan reflejadas sus expectativas a nivel

de requisitos, valor, coste y entregas.

El cliente comprueba de manera

regular si se van cumpliendo sus

expectativas, da feedback, ya

desde el inicio del proyecto puede

tomar decisiones informadas a

partir de resultados objetivos y

dirige estos resultados del

proyecto, iteración a iteración,

Demostración de los resultados de

proyecto en cada iteración

Al final de cada iteración el equipo

demuestra al cliente los requisitos que ha

conseguido completar. Tras una

inspección del resultado real del proyecto

hasta ese momento, y considerando el

esfuerzo que ha sido necesario para

hacia su meta. Se ahorra esfuerzo

y tiempo al evitar hipótesis.

realizarlo, el cliente solicita los cambios

que necesita y replanifica el proyecto.

Resultados anticipados (“time to

market”)

El cliente puede empezar a utilizar

los resultados más importantes del

proyecto antes de que esté

finalizado por completo.

Siguiendo la ley de Pareto (el 20%

del esfuerzo proporciona el 80%

del valor), el cliente puede

empezar antes a recuperar su

inversión (y/o autofinanciarse)

comenzando a utilizar un producto

al que sólo le faltan características

poco relevantes, puede sacar al

mercado un producto antes que su

competidor, puede hacer frente a

urgencias o nuevas peticiones de

clientes, etc.

Priorización de requisitos por valor y

coste

Al inicio de cada iteración el cliente prioriza

la lista de requisitos del producto o

proyecto en función del valor que le

aportan, su coste de desarrollo y los

riesgos del proyecto, cambiando los

requisitos previstos para reaccionar a

cambios de contexto en el proyecto.

El progreso del proyecto se mide en

función de los requisitos que el equipo

completa en cada iteración.

Flexibilidad y adaptación

De manera regular el cliente

redirige el proyecto en función de

sus nuevas prioridades, de los

cambios en el mercado, de los

requisitos completados que le

permiten entender mejor el

producto, de la velocidad real de

desarrollo, etc.

Al final de cada iteración el cliente

puede aprovechar la parte de

producto completada hasta ese

momento para hacer pruebas de

Replanificación en el inicio de cada

iteración

Se asume que los cambios son parte

natural del proyecto. Toda iteración

comienza con una replanificación del

proyecto. Esta replanificación no es

traumática puesto que Scrum minimiza el

número de objetivos/requisitos en que el

equipo trabaja (WIP, Work In Progress) a

los que caben en una iteración. Todavía no

se ha hecho ningún esfuerzo en desarrollar

los requisitos de las siguientes iteraciones.

El hecho los requisitos se completen en

concepto con usuarios o

consumidores y tomar decisiones

en función del resultado obtenido.

función del valor que aportan al cliente

minimiza la probabilidad de que se

produzcan grandes cambios en el

transcurso del proyecto.Retorno de inversión (ROI)

De manera regular, el cliente

maximiza el ROI del proyecto.

Cuando el beneficio pendiente de

obtener es menor que el coste de

desarrollo, el cliente puede finalizar

el proyecto.

Priorización de requisitos por valor

Cada iteración el cliente dispone de unos

requisitos completados y replanifica el

proyecto en función del valor que le

aportan los requisitos pendientes respecto

del coste de desarrollo que tienen.

Mitigación de riesgos

Desde la primera iteración el

equipo tiene que gestionar los

problemas que pueden aparecer

en una entrega del proyecto. Al

hacer patentes estos riesgos, es

posible iniciar su mitigación de

manera anticipada. "Si hay que

equivocarse o fallar, mejor hacelo

lo antes posible". El feedback

temprano permite ahorrar esfuerzo

y tiempo en errores técnicos.

La cantidad de riesgo a que se

enfrenta el equipo está limitada a

los requisitos que se puede

desarrollar en una iteración. La

complejidad y riesgos del proyecto

se dividen de manera natural en

iteraciones.

Desarrollo iterativo e incremental

Un requisito se debe completar en una

iteración. El equipo debe realizar todas las

tareas necesarias para completarlo y que

esté preparado para ser entregado al

cliente con el esfuerzo mínimo necesario.

De esta manera no se deja para el final del

proyecto ninguna actividad arriesgada

relacionada con la entrega de requisitos.

Productividad y calidad

De manera regular el equipo va

mejorando y simplificando su forma

de trabajar.

Mejora continua

Cada iteración el equipo realiza una

retrospectiva para analizar su manera de

trabajar e identificar los obstáculos que le

impiden avanzar al mejor ritmo posible.Los miembros del equipo

sincronizan su trabajo diariamente

y se ayudan a resolver los

problemas que pueden impedir

conseguir el objetivo de la

iteración. La comunicación y la

adaptación a las diferentes

necesidades entre los miembros

del equipo son máximas (se van

ajustando iteración a iteración), de

manera que no se realizan tareas

innecesarias y se evitan

ineficiencias.

Comunicación diaria del equipo

Todo miembro del equipo conoce cómo el

trabajo de los otros miembros impacta en

el suyo y cuáles son las necesidades de

los otros.

Las personas trabajan más

enfocadas y de manera más

eficiente cuando hay una fecha

límite a corto plazo para entregar

un resultado al que se han

comprometido. La consciencia de

esta limitación temporal favorece la

priorización de las tareas y fuerza

la toma de decisiones.

Las iteraciones (Sprints) son

regulares y de un mes para facilitar

la sincronización sistemática con

otros equipos, con el resto de la

empresa y con el cliente.

TimeBoxing

Cada actividad de Scrum siempre tiene la

misma duración (1 mes, 4 horas, etc.), con

lo que las personas aprenden lo que

pueden conseguir en este tiempo, cómo

organizarse, priorizar tareas y tomar

decisiones.

El equipo minimiza su dependencia

de personas externas para poder

avanzar (depender de la

disponibilidad de otros puede parar

tareas).

Equipo multidisciplinar

El equipo está formado por todas las

personas con las especialidades

necesarias para llevar a cabo el proyecto.

La estimación de esfuerzo y la

optimización de tareas para

Estimación de esfuerzo conjunta

En el inicio de la iteración los miembros del

completar un requisito es mejor si

la realizan las personas que van a

desarrollar el requisito, dadas sus

diferentes especializaciones,

experiencias y puntos de vista.

Asímismo, con iteraciones cortas la

precisión de las estimaciones

aumenta.

equipo estiman de manera conjunta el

esfuerzo necesario para completar

requisitos y sus tareas.

Las personas trabajan de manera

más eficiente y con más calidad

cuando ellas mismas se han

comprometido a entregar un

resultado en un momento

determinado y deciden cómo

hacerlo, no cuando se les ha

asignado una tarea e indicado el

tiempo necesario para realizarla.

Compromiso del equipo

En el inicio de cada iteración el equipo

selecciona los requisitos que se

compromete a completar y entregar al final

de la iteración (responsabilidad). El propio

equipo se organiza (autoridad)

identificando las tareas necesarias, su

esfuerzo y autoasignándose cada miembro

las tareas que se compromete a realizar.El equipo se evita caminar mucho

tiempo por un camino equivocado

que le obligue a realizar un gran

esfuerzo para llegar al objetivo

esperado

Se asegura la calidad del producto

de manera sistemática y objetiva, a

nivel de satisfacción del cliente,

requisitos listos para ser utilizados

y calidad interna del producto.

Demostración de resultados preparados

para ser utilizados y velocidad

sostenida

Por un lado, al final de cada iteración el

equipo demuestra al cliente los requisitos

que ha conseguido completar, de manera

que están completamente operativos. Por

otro lado, para tener una velocidad de

desarrollo sostenida, el equipo necesita

desarrollar cada incremento de producto

sin tener que revisitar aspectos mal

resueltos en iteraciones anteriores. Alineamiento entre cliente y

equipo

Los resultados y esfuerzos del

proyecto se miden en forma de

objetivos y requisitos entregados al

Cliente y equipo trabajando “en equipo”

Cada iteración el equipo y el cliente

trabajan juntos en la creación de los

requisitos del proyecto (en la estimación de

la lista priorizada de requisitos del

negocio. Todos los participantes en

el proyecto conocen cuál es el

objetivo a conseguir. El producto

se enriquece con las aportaciones

de todos.

proyecto), en darles detalle (en la reunión

de planificación de la iteración) y en el

análisis del resultado obtenido (en la

demostración de los requisitos

completados).Equipo motivado

Las personas están más motivadas

cuando pueden usar su creatividad

para resolver problemas y cuando

pueden decidir organizar su

trabajo.

Equipo autogestionado

El equipo es quien se compromete a

completar unos requisitos determinados en

una iteración y quien mejor sabe cómo

desarrollarlos. Por ello es el equipo quien

se autoorganiza y quien planifica cómo

trabajará en la iteración.Las personas se sienten más

satisfechas cuando pueden

mostrar los logros que consiguen.

Demostración

Cada iteración el equipo muestra al cliente

los resultados que consigue. No está

meses trabajando sin poder exhibir su

obra.

1.6 Cómo funciona Scrum

1.6.1 Proceso

En Scrum un proyecto se ejecuta en bloques temporales cortos y fijos

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

Cada iteración tiene que proporcionar un resultado completo, un incremento de

producto final que sea susceptible de ser entregado con el mínimo esfuerzo al

cliente cuando lo solicite.

El proceso parte de la lista de objetivos/requisitos priorizada del producto, que

actúa como plan del proyecto. En esta lista el cliente prioriza los objetivos

balanceando el valor que le aportan respecto a su coste y quedan repartidos en

iteraciones y entregas.

De manera regular el cliente puede maximizar la utilidad de lo que se desarrolla

y el retorno de inversión mediante la replanificación de objetivos del producto,

que realiza durante la iteración con vista a las siguientes iteraciones.

Las actividades que se llevan a cabo en Scrum son las siguientes:

1.6.1.1Planificación de la iteración

El primer día de la iteración se realiza la reunión de planificación de la

iteración. Tiene dos partes:

1. Selección de requisitos (4 horas máximo). El cliente presenta al equipo

la lista de requisitos priorizada del producto o proyecto. El equipo

pregunta al cliente las dudas que surgen y selecciona los requisitos más

prioritarios que se compromete a completar en la iteración, de manera

que puedan ser entregados si el cliente lo solicita.

2. Planificación de la iteración (4 horas máximo). El equipo elabora la

lista de tareas de la iteración necesarias para desarrollar los requisitos a

que se ha comprometido. La estimación de esfuerzo se hace de manera

conjunta y los miembros del equipo se autoasignan las tareas.

1.6.1.2Ejecución de la iteración

Cada día el equipo realiza una reunión de sincronización (15 minutos máximo).

Cada miembro del equipo inspecciona el trabajo que el resto está realizando

(dependencias entre tareas, progreso hacia el objetivo de la iteración,

obstáculos que pueden impedir este objetivo) para poder hacer las

adaptaciones necesarias que permitan cumplir con el compromiso adquirido.

En la reunión cada miembro del equipo responde a tres preguntas:

• ¿Qué he hecho desde la última reunión de sincronización?

• ¿Qué voy a hacer a partir de este momento?

• ¿Qué impedimentos tengo o voy a tener?

Durante la iteración el Facilitador se encarga de que el equipo pueda cumplir

con su compromiso y de que no se merme su productividad.

• Elimina los obstáculos que el equipo no puede resolver por sí mismo.

• Protege al equipo de interrupciones externas que puedan afectar su

compromiso o su productividad.

1.6.1.3Inspección y adaptación

El último día de la iteración se realiza la reunión de revisión de la iteración.

Tiene dos partes:

1. Demostración (4 horas máximo). El equipo presenta al cliente los

requisitos completados en la iteración, en forma de incremento de

producto preparado para ser entregado con el mínimo esfuerzo. En

función de los resultados mostrados y de los cambios que haya habido

en el contexto del proyecto, el cliente realiza las adaptaciones

necesarias de manera objetiva, ya desde la primera iteración,

replanificando el proyecto.

2. Retrospectiva (4 horas máximo). El equipo analiza cómo ha sido su

manera de trabajar y cuáles son los problemas que podrían impedirle

progresar adecuadamente, mejorando de manera continua su

productividad. El Facilitador se encargará de ir eliminando los obstáculos

identificados.

1.6.2 Actividades

1.6.2.1Planificación de la iteración (Sprint Planning)

La planificación de las tareas a realizar en la iteración se divide en dos partes:

• Primera parte de la reunión. Se realiza en un timebox de cómo máximo 4

horas* :

o El cliente presenta al equipo la lista de requisitos priorizada del

producto o proyecto, pone nombre a la meta de la iteración (de

manera que ayude a tomar decisiones durante su ejecución) y

propone los requisitos más prioritarios a desarrollar en ella.

o El equipo examina la lista, pregunta al cliente las dudas que le

surgen, añade más condiciones de satisfacción y selecciona los

objetivos/requisitos más prioritarios que se compromete a

completar en la iteración, de manera que puedan ser entregados

si el cliente lo solicita.

• Segunda parte de la reunión. Se realiza en un timebox de cómo máximo

4 horas*. El equipo planifica la iteración, elabora la táctica que le

permitirá conseguir el mejor resultado posible con el mínimo esfuerzo.

Esta actividad la realiza el equipo dado que ha adquirido un

compromiso, es el responsable de organizar su trabajo y es quien mejor

conoce cómo realizarlo.

o Define las tareas necesarias para poder completar cada

objetivo/requisito, creando la lista de tareas de la iteración (Sprint

Backlog) basándose en la definición de completado.

o Realiza una estimación conjunta del esfuerzo necesario para

realizar cada tarea.

o Cada miembro del equipo se autoasigna a las tareas que puede

realizar.

* Estos son tiempos máximos en el caso de iteraciones mensuales. En

iteraciones de tamaño menor el tiempo es proporcionalmente inferior, y se

puede ir reduciendo conforme el equipo va ganando experiencia en este tipo de

reuniones, aunque también dependerá de la complejidad a desarrollar en la

iteración.

1.6.2.1.1 Beneficios

• Productividad mediante comunicación y creación de sinergias:

o Todos los miembros del equipo tienen una misma visión del

objetivo y se ha utilizado los conocimientos y las experiencias de

todos para elaborar la mejor solución entregable en el mínimo

tiempo y con el mínimo esfuerzo, eliminando tareas innecesarias,

detectando conflictos y dependencias entre tareas, etc.

• Potenciación del compromiso del equipo sobre el objetivo común de la

iteración:

o Es todo el equipo quien asume la responsabilidad de completar

en la iteración los requisitos que selecciona. Facilita la ayuda de

cualquier miembro si se detecta algún impedimento que bloquea

el progreso de la iteración, especialmente si cuando se está

llegando al final de la iteración es necesaria la participación de

todos para poder completar los objetivos comprometidos.

o Es cada una de las personas la que se responsabiliza de realizar

sus tareas (a las que se autoasignó) en los tiempos que

proporcionó. Si existe falta de compromiso con respecto al resto

de miembros del equipo se hará muy evidente en las reuniones

diarias de sincronización del equipo (Scrum daily meeting).

• Una estimación conjunta es más fiable, dado que tiene en cuenta los

diferentes conocimientos, experiencia y habilidades de los integrantes

del equipo.

1.6.2.2Ejecución de la iteración (Sprint)

En Scrum un proyecto se ejecuta en bloques temporales cortas y fijas

(iteraciones de un mes natural y hasta de dos semanas). Cada iteración tiene

que proporcionar un resultado completo, un incremento de producto que sea

potencialmente entregable, de manera que cuando el cliente (Product Owner)

lo solicite sólo sea necesario un esfuerzo mínimo para que el producto este

disponible para ser utilizado. Para ello, durante la iteración el equipo colabora

estrechamente y se llevan a cabo las siguientes dinámicas:

• Cada día el equipo realiza una reunión de sincronización, donde cada

miembro inspecciona el trabajo de los otros para poder hacer las

adaptaciones necesarias, comunica cuales son los impedimentos con

que se encuentra, actualiza el estado de la lista de tareas de la iteración

(Sprint Backlog) y los gráficos de trabajo pendiente (Burndown charts).

• El Facilitador (Scrum Master) se encarga de que el equipo pueda cumplir

con su compromiso y de que no se merme su productividad.

o Elimina los obstáculos que el equipo no puede resolver por sí

mismo.

o Protege al equipo de interrupciones externas que puedan afectar

su compromiso o su productividad.

1.6.2.2.1 Recomendaciones

• Para poder completar el máximo de requisitos en la iteración, se debe

minimizar el número de objetivos/requisitos en que el equipo trabaja

simultáneamente (WIP, Work In Progress), completando primero los que

den más valor al cliente. Esta forma de trabajar, que se ve facilitada por

la propia estructura de la lista de tareas de la iteración, permite tener

más capacidad de reacción frente a cambios o situaciones inesperadas.

1.6.2.2.2 Restricciones

• No se puede cambiar los objetivos/requisitos de la iteración en curso.

o En la reunión de planificación de la iteración el equipo adquirió el

compromiso de completar en la iteración unos requisitos

concretos, basó su plan y organización en ellos. Cambiar los

objetivos/requisitos de la iteración dificulta la concentración del

equipo, baja su moral y su compromiso.

o El hecho de no poder cambiar los objetivos/requisitos de la

iteración una vez iniciada facilita que el cliente cumpla con su

responsabilidad de conocer qué es lo más prioritario a desarrollar,

antes de iniciar la iteración.

o Notar que Scrum minimiza esta necesidad ya que, por un lado,

los objetivos/requisitos que se están desarrollando eran los más

prioritarios justo antes de iniciar la iteración y, por otro lado, las

iteraciones en Scrum son suficientemente cortas (2 o 4 semanas)

como para que la probabilidad de cambios una vez iniciada la

iteración sea mínima.

1.6.2.2.3 Terminación anormal de la iteración

Sólo en situaciones muy excepcionales el cliente o el equipo pueden solicitar

una terminación anormal de la iteración. Esto puede suceder si, por ejemplo, el

contexto del proyecto ha cambiado enormemente y no es posible esperar al

final de la iteración para aplicar cambios, o si el equipo encuentra que es

imposible cumplir con el compromiso adquirido. En ese caso, se dará por

finalizada la iteración y se dará inicio a otra mediante una reunión de

planificación de la iteración.

1.6.2.3Reunión diaria de sincronización del equipo (Scrum

Daily Meeting)

El objetivo de esta reunión es facilitar la transferencia de información y la

colaboración entre los miembros del equipo para aumentar su productividad, al

poner de manifiesto puntos en que se pueden ayudar unos a otros.

Cada miembro del equipo inspecciona el trabajo que el resto está realizando

(dependencias entre tareas, progreso hacia el objetivo de la iteración,

obstáculos que pueden impedir este objetivo) para al finalizar la reunión poder

hacer las adaptaciones necesarias que permitan cumplir con el compromiso

conjunto que el equipo adquirió para la iteración (en la reunión de planificación

de la iteración).

Cada miembro del equipo debe responder las siguientes preguntas en un

timebox de cómo máximo 15 minutos:

• ¿Qué he hecho desde la última reunión de sincronización? ¿Pude hacer

todo lo que tenía planeado? ¿Cuál fue el problema?

• ¿Qué voy a hacer a partir de este momento?

• ¿Qué impedimentos tengo o voy a tener para cumplir mis compromisos

en esta iteración y en el proyecto?

Como apoyo a la reunión, el equipo cuenta con la lista de tareas de la iteración,

donde se actualiza el estado y el esfuerzo pendiente para cada tarea, así como

con el gráfico de horas pendientes en la iteración.


• Aumentar la productividad en el proyecto y potencia el compromiso de

equipo, dado que cada miembro pone de manifiesto delante del resto:

o Las tareas que pueden afectar a otros miembros del equipo, por

que impactan en su trabajo o por que hay dependencias

(especialmente si existe un retraso).

o Los impedimentos con que se encuentra. La reunión de

sincronización permite identificar más problemas a tiempo. El

resto de miembros del equipo pueden ofrecer ayuda a otros en la

realización de tareas o para resolver problemas que ya tuvieron

anteriormente. El Facilitador (Scrum Master) se encargará de

solucionar los impedimentos que el equipo no puede solucionar

por sí solo o que le quitan tiempo para cumplir con su

compromiso fundamental de desarrollo de requisitos.

o Las tareas no planeadas que está realizando que el equipo no

conoce y puede que no estén alineadas con el compromiso del

equipo, aunque él crea que lo que está haciendo es lo mejor que

se puede hacer.

o Cuales son sus necesidades. Cada miembro entiende las

necesidades de los otros miembros del equipo respecto a su

trabajo, de manera que pueden colaborar y adaptar sus trabajos

para que den el máximo valor y no realizar tareas que no

proporcionan ningún beneficio al resto del equipo.

o Cual es su ritmo de trabajo. Se hace visible si de manera continua

un miembro del equipo está realizando tareas por debajo del

rendimiento esperado. Se evita que una persona señale con el

dedo a otra, dado que la reunión de sincronización pone a todos

los miembros del equipo en la misma situación de tener que

explicar en qué tareas están trabajando.

o Cuales son los criterios que está utilizando para realizar sus

tareas, de manera que estén alineados con los objetivos comunes

del equipo.

• Fomentar el aprendizaje de los miembros del equipo, ya que pueden ver

cómo trabajan los otros según sus especialidades y experiencias.

• Conocer el estado de la iteración, ver si es posible completar los

requisitos a que se comprometió el equipo, en vista de las desviaciones

y de las tareas pendientes.


• La reunión diaria de estado y sincronización del equipo no es para

resolver problemas, los problemas se resuelven después de la reunión.

o No a todos los miembros del equipo les interesan todos los

detalles de cada tema.

o En la reunión los miembros del equipo programan reuniones entre

ellos donde colaborar sincronizando tareas, ayudando a resolver

problemas, etc.

o No puede haber una persona explicando su estado mientras otras

"se han apartado" de la reunión para comentar un tema particular.

Si apareciese alguna conversación de interés común (que debe

ser rápida), debe poder ser escuchada por todo el equipo sin

distraer el principal objetivo de que todos conozcan en qué están

trabajando los demás. Si la mini conversación no es del interés de

todos, debe hacerse después de la reunión.

• El equipo debe contar con unos criterios consensuados sobre el proceso

de ejecución de las de tareas

o El proceso de ejecución de las tareas debe estar consensuado

para evitar que cada reunión sea una exposición de discrepancias

entre los miembros del equipo.

1.6.2.3.3 Recomendaciones

• Realizar la reunión diaria de sincronización de pie, para que los

miembros del equipo no se relajen ni se extiendan en más detalles de

los necesarios.

• Realizar las reuniones de colaboración entre miembros del equipo justo

después de la de sincronización.

1.6.2.4Demostración de los requisitos completados (Sprint

Review)

Reunión informal donde el equipo presenta al cliente los requisitos completados

en la iteración, en forma de incremento de producto preparado para ser

entregado con el mínimo esfuerzo, haciendo un recorrido por ellos lo más real y

cercano posible al objetivo que se pretende cubrir.

En función de los resultados mostrados y de los cambios que haya habido en el

contexto del proyecto, el cliente realiza las adaptaciones necesarias de manera

objetiva, ya desde la primera iteración, replanificando el proyecto.

Se realiza en un timebox de cómo máximo 4 horas.


• El cliente puede ver de manera objetiva cómo han sido desarrollados los

requisitos que proporcionó, ver si se cumplen sus expectativas, entender

más qué es lo que necesita y tomar mejores decisiones respecto al

proyecto.

• El equipo puede ver si realmente entendió cuáles eran los requisitos que

solicitó el cliente y ver en qué puntos hay que mejorar la comunicación

entre ambos.

• El equipo se siente más satisfecho cuando puede ir mostrando los

resultados que va obteniendo. No está meses trabajando sin poder

exhibir su obra.


• Sólo se pueden mostrar los requisitos completados, para que el cliente

no se haga falsas expectativas y pueda tomar decisiones correctas y

objetivas en función de la velocidad de desarrollo y el resultado

realmente completado. Un requisito no completado quedará como un

requisito más a replanificar.

1.6.2.5Retrospectiva (Sprint Retrospective)

Con el objetivo de mejorar de manera continua su productividad y la calidad del

producto que está desarrollando, el equipo analiza cómo ha sido su manera de

trabajar durante la iteración, por qué está consiguiendo o no los objetivos a que

se comprometió al inicio de la iteración y por qué el incremento de producto

que acaba de demostrar al cliente era lo que él esperaba o no:

• Qué cosas han funcionado bien.

• Cuales hay que mejorar.

• Qué cosas quiere probar hacer en la siguiente iteración.

• Qué ha aprendido.

• Cuales son los problemas que podrían impedirle progresar

adecuadamente. El Facilitador se encargará de ir eliminando los

obstáculos identificados que el propio equipo no pueda resolver por sí

mismo.

Notar que esta reunión se realiza después de la reunión de demostración al

cliente de los objetivos conseguidos en la iteración, para poder incorporar su

feedback y cumplimiento de expectativas como parte de los temas a tratar en la

reunión de retrospectiva

Se realiza en un timebox de cómo máximo 3 horas (si la iteración es mensual).


• Incrementa la productividad en el proyecto, la calidad del producto (cosa

que permite hacerlo crecer de manera sostenida) y potencia el

aprendizaje del equipo de manera sistemática, iteración a iteración, con

resultados a corto plazo.

• Aumenta la motivación del equipo dado que participa en la mejora de

proceso, se siente escuchado, toma decisiones consensuadas (y más

sostenibles) para ir eliminando lo que molesta e impide que sea más

productivo.


• En necesario que el Equipo y el Facilitador dispongan de autoridad,

mecanismos y recursos para ir mejorando su forma de trabajar y el

contexto del proyecto. Es frustrante encontrar sistemáticamente los

mismos obstáculos y no poder solucionarlos.

1.6.2.6Replanificación del proyecto

En las reuniones de planificación de entregas y durante el transcurso de una

iteración (en el Product Backlog Refinement o Grooming), el cliente va

trabajando en la lista de objetivos/requisitos priorizada del producto o proyecto,

añadiendo requisitos, modificándolos, eliminándolos, repriorizándolos,

cambiando el contenido de iteraciones y definiendo un calendario de entregas

que se ajuste mejor a sus nuevas necesidades [1].

Los cambios en la lista de requisitos pueden ser debidos a:

• Modificaciones que el cliente solicita tras la demostración que el equipo

realiza al final de cada iteración sobre los resultados obtenidos, ahora

que el cliente entiende mejor el producto o proyecto.

• Cambios en el contexto del proyecto (sacar al mercado un producto

antes que su competidor, hacer frente a urgencias o nuevas peticiones

de clientes, etc.).

• Nuevos requisitos o tareas como resultado de nuevos riesgos en el

proyecto.

• Etc.

Para realizar esta tarea, el cliente colabora con el equipo:

• Para cada nuevo objetivo/requisito, conjuntamente se hace una

identificación inicial de sus condiciones de satisfacción (que se

detallarán en la reunión de planificación de la iteración).

• El cliente obtiene del equipo la re-estimación de costes de desarrollo

para completar los objetivos/requisitos siguientes, según la definición de

completado. El equipo ajusta el factor de complejidad, el coste para

completar los requisitos y su velocidad de desarrollo en función de la

experiencia adquirida hasta ese momento en el proyecto.

• El cliente re-prioriza la lista de objetivos/requisitos en función de estas

nuevas estimaciones.

Hay que notar que el equipo sigue trabajando con los objetivos/requisitos de la

iteración en curso, (que de hecho eran los más prioritarios al iniciar la

iteración).No es posible cambiar los requisitos que se desarrollan durante la

iteración. En la reunión de planificación de la iteración el cliente presentará la

nueva lista de requisitos para que sea desarrollada.


De manera sistemática, iteración a iteración, se obtienen los siguientes

beneficios:

• El cliente puede tomar decisiones con tiempo respecto al progreso del

proyecto y posibles desviaciones:

o Replanificar el proyecto para obtener un nuevo calendario de

entregas que cumpla con sus necesidades actuales.

o Incorporar nuevos recursos.

o Cancelar el proyecto con los requisitos completados hasta el

momento plenamente operativos, si el beneficio pendiente de

obtener es menor que el coste de desarrollo [2].

• El plan de proyecto se actualiza con la velocidad de desarrollo del

equipo, se evitan sorpresas de última hora.

1.6.3 Responsabilidades (Roles)

1.6.3.1Cliente (Product Owner)

Las responsabilidades del Cliente (que puede ser interno o externo a la

organización) son:

• Ser el representante de todas las personas interesadas en los

resultados del proyecto (internas o externas a la organización,

promotores del proyecto y usuarios finales [idealmente también debería

ser un usuario clave] o consumidores finales del producto) y actuar como

interlocutor único ante el equipo, con autoridad para tomar decisiones.

• Definir los objetivos del producto o proyecto.

• Dirigir los resultados del proyecto y maximizar su ROI (Return Of

Investment).

o Es el propietario de la planificación del proyecto: crea y mantiene

la lista priorizada con los requisitos necesarios para cubrir los

objetivos del producto o proyecto, conoce el valor que aportará

cada requisito y calcula el ROI a partir del coste de cada requisito

que le proporciona el equipo.

o Reparte los objetivos/requisitos en iteraciones y establece un

calendario de entregas.

o Antes de iniciar cada iteración replanifica el proyecto en función

de los requisitos que aportan más valor en ese momento, de los

requisitos completados en la iteración anterior y del contexto del

proyecto en ese momento (demandas del mercado, movimientos

de la competencia, etc.).

• Colaborar con el equipo para planificar, revisar y dar detalle a los

objetivos de cada iteración:

o Participar en la reunión de planificación de iteración, proponiendo

los requisitos más prioritarios a desarrollar, respondiendo a las

dudas del equipo y detallando los requisitos que el equipo se

comprometer a hacer.

o Estar disponible durante el curso de la iteración para responder a

las preguntas que puedan aparecer.

o No cambiar los requisitos que se están desarrollando en una

iteración, una vez está iniciada.

o Participar en la reunión de demostración de la iteración, revisando

los requisitos completados.

1.6.3.2Facilitador (Scrum Master)

Lidera al equipo llevando a cabo las siguientes responsabilidades:

• Velar por que todos los participantes del proyecto sigan las reglas y

proceso de Scrum, encajándolas en la cultura de la organización, y guiar

la colaboración intraequipo y con el cliente de manera que las sinergias

sean máximas. Esto implica:

o Asegurar que la lista de requisitos priorizada esté preparad antes

de la siguiente iteración.

o Facilitar las reuniones de Scrum (planificación de la iteración,

reuniones diarias de sincronización del equipo, demostración,

retrospectiva), de manera que sean productivas y consigan sus

objetivos.

o Enseñar al equipo a autogestionarse. No da respuestas, si no que

guía al equipo con preguntas para que descubra por sí mismo

una solución.

• Quitar los impedimentos que el equipo tiene en su camino para

conseguir el objetivo de cada iteración (proporcionar un resultado útil al

cliente de la manera más efectiva) y poder finalizar el proyecto con éxito.

Estos obstáculos se identifican de manera sistemática en las reuniones

diarias de sincronización del equipo y en las reuniones de retrospectiva.

• Proteger y aislar al equipo de interrupciones externas durante la

ejecución de la iteración (introducción 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 completaría en la iteración [notar, sin embargo, que el

equipo debe reservar tiempo para colaborar con al cliente en la

preparación de la lista de requisitos para la próxima iteración].

1.6.3.2.1 El buen gestor de un equipo ágil

En un equipo ágil, el gestor es un elemento clave. No es sencillo conseguir que

el cliente obtenga el mejor resultado posible del proyecto, que el equipo sea

hiperproductivo y que a la vez disfrute de su trabajo. De hecho, ser jefe no

significa necesariamente ser líder, y el liderazgo estructural simplemente es

ejercicio del poder. El liderazgo es más que técnicas, es una forma de pensar,

un estilo de vida. Lo detenta aquella persona que consigue que se hagan las

cosas, que se cambien, que se mejoren y que se innove.

Si se entiende la cultura de una empresa como el resultado del modelo de

gestión que se practica en ella, se puede distinguir entre dos modelos

diferentes:

a. El modelo de gestión tradicional, basado en la autoridad, dirección y

control por parte de un superior que planifica/dicta las tareas a hacer y

las asigna. Este modelo se basa más en competencias individuales que

en trabajo en equipo: cada miembro del grupo de trabajo está

especializado en tareas concretas dentro de un proceso “en cascada”.

Tras realizar su parte, se “pasa la pelota” al experto en la siguiente fase,

de manera que es difícil que haya un sentimiento de responsabilidad

compartido entre los miembros del grupo de trabajo acerca del resultado

del proyecto, se producen esperas, pasos hacia atrás, correcciones por

no-cumplimiento y, peor, puede fomentar la competitividad entre las

personas del grupo de trabajo.

b. El modelo que fomenta el trabajo en equipo, especialmente en proyectos

complejos y de alto riesgo, donde el alcance se va precisando durante la

ejecución del proyecto (proyectos “emergentes”) y/o que necesitan de la

creatividad conjunta de los integrantes del equipo, que colaboran

estrechamente y comparten la responsabilidad del resultado del

proyecto.

Para este segundo modelo, se necesita que el gestor/líder de un equipo ágil

piense y se comporte como un facilitador, un líder al servicio del equipo que en

Scrum se conoce como Scrum Master, una persona que, además de entender

cual es la base por la que funcionan las cosas (el negocio del cliente, la

metodología de trabajo, la tecnología) debe tener dotes de trato interpersonal,

tanto con el cliente como con el equipo, ser capaz de:

• Observar, escuchar, preguntar mucho y reparafrasear para entender las

necesidades, motivaciones y sentimientos de los otros, ponerse en su

lugar antes de dar la propia opinión (si es realmente necesario que la

dé). Es decir, evitar juzgar inmediatamente al otro y tener empatía.

• Negociar, comunicar adecuadamente la información correcta en el

momento correcto, adaptándola a las necesidades de la audiencia.

• Enfocar al equipo, orientarlo para avanzar y cumplir con las expectativas

del cliente, a la vez que cuidar la calidad del producto, sin dictar cómo

hacerlo.

• Motivar al equipo.

Esta manera alternativa de concebir el trabajo en equipo lleva utilizándose

desde hace varios años en miles de proyectos. Actualmente hay más de

50.000 Scrum Masters certificados a nivel mundial (sin contar con los que no

están certificados) que trabajan en empresas donde la competitividad de

mercado, la innovación, la calidad y la productividad son fundamentales, desde

startups a grandes empresas como Nokia, Toyota, Google, etc.

A continuación se enumeran las cualidades que debe tener y los

comportamientos a evitar por parte de un buen gestor de equipo.

Confía en el equipo y lo potencia

• No actúa como un jefe de proyecto tradicional que dirige los resultados

del proyecto (esto es responsabilidad del cliente). No impone su

autoridad ni exige que el equipo le siga. No controla a su equipo

planificando sus tareas, decidiendo en qué tareas debe trabajar cada

persona y cómo deber de hacer su trabajo, no guía el proyecto con sus

decisiones ni hace microgestión, no hace que el equipo se sienta

cuestionado ni lo desautoriza. En cambio, asume que el equipo es el

experto y así se lo hace saber, ellos son quienes conocen la mejor

manera de realizar su trabajo y quienes tienen la responsabilidad de

llevar a buen término el proyecto.

• Ayuda al equipo a autoorganizarse para conseguir los objetivos del

proyecto; a comunicarse, a compartir ideas, a colaborar y a ir mejorando

su forma de trabajar para ser más productivo, flexible y adaptativo a

cambios en las necesidades del cliente. No da respuestas, si no que

guía al equipo con preguntas para que descubra por sí mismo una

solución y aprenda. Facilita que el equipo tome decisiones

consensuadas (sostenibles en el tiempo), que encuentre las mejores

soluciones posibles mediante la sinergia de enfoques, conocimientos y

experiencias, a partir de los cuales combinar diferentes opciones. Para

ello fomenta la colaboración entre los miembros del equipo en los

procesos de decisión y con el cliente, especialmente en las reuniones de

planificación de la iteración (Sprint), en las demostraciones de los

resultados de cada iteración y en las retrospectivas.

Actúa como un sirviente de su equipo, de manera que avance y no se quede

bloqueado

• Ayuda a que su equipo avance, no se quede bloqueado, se mantenga

focalizado en su trabajo, elimine ineficiencias y maximice su

productividad. Para ello quita de en medio los impedimentos que el

equipo no puede resolver por sí mismo (o que no son su principal

objetivo) y, lo que es mejor, es capaz de intuirlos y anticipar la necesidad

de mitigación de riesgos. Cuando es necesario, busca recursos para que

el equipo vaya aprendiendo cómo solucionar sus déficits (formación,

soporte experto, etc.).

• Protege a su equipo de interrupciones externas para que pueda cumplir

con el compromiso de objetivos que adquirió al inicio de la iteración.

Promueve la confianza y la comunicación entre los miembros del equipo

• Promueve las conversaciones sinceras, la compartición de información y

la comunicación frecuente entre los miembros del equipo. Aporta

seguridad y confianza para que tengan lugar.

• Mantiene un ambiente constructivo para converger en los conflictos e

impide actitudes recriminatorias, atacantes y/o acusadoras dentro y

desde fuera del equipo. Para ello ayuda a escuchar, a ponerse en el

lugar de los otros, a entender sus razones, a consensuar el problema, a

que se propongan soluciones alternativas, respetando las opiniones de

todos, a evaluarlas y a llegar a conclusiones y acuerdos, siempre bajo el

principio de ganar-ganar.

• Crea un sentido de comunidad e identidad del equipo en el proyecto.

Fomenta que unos aprendan de otros y que establezcan vínculos.

Promueve la confianza entre el cliente y el equipo

• Se asegura de que tanto el cliente como el equipo compartan el mismo

objetivo del proyecto, tengan una visión común a través de la lista de

objetivos priorizados (Product Backlog) y que colaboren para que el

proyecto proporcione el máximo valor. Para ello facilita las reuniones de

planificación de la iteración (Sprint) y las demostraciones.

• Reconoce el buen trabajo realizado por el equipo y hace que sea

protagonista delante del cliente, especialmente en las reuniones de

planificación de la iteración (Sprint) y en las demostraciones.

Tolera errores y no busca culpables, sino mejorar el proceso de trabajo

• Cuando se produce un error no busca personas culpables. No acusa ni

recrimina, para que el equipo no se desmotive y hasta acabe

paralizándose. Asume que es el contexto quien provoca los errores, por

lo que con visión constructiva ayuda al equipo a descubrir, mediante un

análisis causal, qué partes del proceso de trabajo, de interrelaciones y

de colaboración, tanto intraequipo como con terceros, deben ser

mejoradas para que el error no se repita.

• Es capaz de aceptar imperfecciones (desde su punto de vista) en el

trabajo de los miembros del equipo y hacer que el equipo encuentre el

camino para ir mejorando. Incluso puede dejar que el equipo se

equivoque para que pueda aprender a partir de la reflexión sobre la

equivocación.

• Cuando se produce un problema, lo primero que debe pensar el gestor

de un equipo ágil es que la responsabilidad es suya, no de otros, debe

preguntarse qué debería haber hecho o estar haciendo para que este

problema no esté sucediendo, cómo podría haberse anticipado.

• El gestor de un equipo ágil es humilde, tienen capacidad de autocrítica,

sabe que siempre hay cosas sobre las que aprender y se esfuerza en

ello, acepta las observaciones de los demás y asume sus errores como

oportunidades de mejora.

Practica con el ejemplo

• El gestor de un equipo ágil da ejemplo, especialmente en la forma de

interrelacionarse con los demás.

• No habla de "yo", sino de "nosotros". Por ejemplo, no dice "quiero esto",

sino "necesitaríamos esto".

• No eleva el tono de voz ni grita, sino que habla calmado, sin excitarse,

tiene buen humor y sonríe.

1.6.3.3Equipo (Team)

Grupo de personas que de manera conjunta desarrollan el producto del

proyecto. Tienen un objetivo común, comparten la responsabilidad del trabajo

que realizan (así como de su calidad) en cada iteración y en el proyecto.

El tamaño del equipo está entre 5 y 9 personas. Por debajo de 5 personas

cualquier imprevisto o interrupción 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 iteración. Por encima de 9 personas, la

comunicación y colaboración entre todos los miembros se hace más difícil 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

más de un equipo trabaje de manera ágil en un mismo proyecto, existen

diferentes técnicas que permiten esta colaboración, desde el Scrum de Scrums

hasta equipos de integración que dedican parte de su tiempo a trabajar con los

equipos de desarrollo, siempre completando incrementos de producto de

manera regular.

Es un equipo autoorganizado, que comparte información y cuyos miembros

confían entre ellos. Realiza de manera conjunta las siguientes actividades:

• Seleccionar los requisitos que se compromete a completar en una

iteración, de forma que estén preparados para ser entregados al cliente.

• Estimar la complejidad de cada requisito en la lista de requisitos

priorizada del producto o proyecto.

• En la reunión de planificación de la iteración decide cómo va a realizar

su trabajo:

o Seleccionar los requisitos que pueden completar en cada

iteración, realizando al cliente las preguntas necesarias.

o Identificar todas las tareas necesarias para completar cada

requisito.

o Estimar el esfuerzo necesario para realizar cada tarea.

o Cada miembro del equipo se autoasigna a las tareas.

• Durante la iteración, trabajar de manera conjunta para conseguir los

objetivos de la iteración. Cada especialista lidera el trabajo en su área y

el resto colaboran si es necesario para poder completar un requisito.

• Al finalizar la iteración:

o Demostrar al cliente los requisitos completados en cada iteración.

o Hacer una retrospectiva la final de cada iteración para mejorar de

forma continua su manera de trabajar.

El equipo es multidisciplinar:

• Los miembros del equipo tienen las habilidades necesarias para poder

identificar y ejecutar todas las tareas que permiten proporcionar al

cliente los requisitos comprometidos en la iteración.

• Tienen que depender lo mínimo de personas externas al equipo, de

manera que el compromiso que adquieren en cada iteración no se

ponga en peligro.

• Se crea una sinergia que permite que el resultado sea más rico al

nutrirse de las diferentes experiencias, conocimientos y habilidades de

todos. Colaboración creativa.

Los miembros del equipo dedicarse al proyecto a tiempo completo para evitar

dañar su productividad por cambios de tareas en diferentes proyectos, para

evitar interrupciones externas y así poder mantener el compromiso que

adquieren en cada iteración.

Todos los miembros del equipo trabajan en la misma localización física, para

poder maximizar la comunicación entre ellos mediante conversaciones cara a

cara, diagramas en pizarras blancas, etc. De esta manera se minimizan otros

canales de comunicación menos eficientes, que hacen que las tareas se

transformen en un “pasa pelota” o que hacen perder el tiempo en el

establecimiento de la comunicación (como cuando se llama repetidas veces por

teléfono cuando la persona no está en su puesto).

El equipo debe ser estable durante el proyecto, sus miembros deben cambiar lo

mínimo posible, para poder aprovechar el esfuerzo que les ha costado construir

sus relaciones interpersonales, engranarse y establecer su organización del

trabajo.

1.6.3.3.1 Skills en un equipo ágil

Los Skull se han agrupado según estén relacionados con la orientación a

producir valor para el receptor final del producto, con la capacidad de trabajar

en equipo o con la capacidad de mejorar.

Antes de ver en detalle estos Skills es necesario entender una de las

características principales que hace que un equipo ágil sea altamente

productivo: la “potenciación del equipo”. Los miembros de un equipo ágil tienen

más libertad para tomar decisiones pero también más responsabilidad,

conjunta y mutua, hacia el resultado del proyecto o producto.

Notar que no todas las personas tienen que tener desarrollados todos los Skills

al mismo nivel, pero es necesario que haya una compensación entre los

miembros del equipo para que no haya ningún déficit o exceso acusado que les

impida colaborar y proporcionar el mejor resultado posible. De manera similar,

estos Skills serán especialmente valorados en entornos y empresas en los que

se fomente una cultura de colaboración y mejora continua, mientras que

pueden producir fuertes disonancias en aquellas organizaciones donde el

modelo de gestión es más tradicional y jerárquico.

1.6.3.3.1.1 Características de un equipo ágil

• Los miembros de un equipo ágil tienen más AUTONOMÍA en la manera

de realizar el trabajo. Se potencia al equipo para que tome decisiones

dado que sus miembros son los especialistas, los que tienen los

conocimientos, habilidades y experiencias necesarios para llevar a cabo

el trabajo. Los planteamientos conjuntos hacen más sencillos los

proyectos, permiten mejores soluciones a partir de las sinergias de todos

los miembros del equipo, a diferencia de los modelos de gestión clásicos

en que las jerarquías establecen quiénes son las personas que deciden,

dirigen y controlan, con lo que las soluciones que aparecen están

limitadas a la capacidad de estas personas. En un entorno ágil las

jerarquías se diluyen.

o Los miembros de un equipo ágil establecen un objetivo común

cuando entre todos deciden cuántos requisitos/objetivos son

capaces de completar en una iteración. Adquieren un

COMPROMISO CONJUNTO al elaborar la táctica que van a

emplear para conseguir estos objetivos, identificando las tareas,

asignándoselas entre ellos y autoorganizándose.

o Entre todos identifican cuales son los impedimentos, mitigaciones

y acciones de mejora a realizar que les impiden proporcionar más

valor, más calidad, ser más productivos y disfrutar más del

trabajo. Sus tareas no son un pasa pelota en una cadena

productiva en la que diluir su responsabilidad sobre el producto

final (lo que sucede en los métodos de trabajo en cascada /

tradicionales), si no que todos los miembros del equipo ágil

comparten la visión global del estado del proyecto respecto a los

objetivos del cliente (ayudándose, por ejemplo, de la Lista de

objetivos priorizada (Product Backlog) y de radiadores de

información como el tablero de tareas de la iteración [Sprint

Backlog]),

• El equipo es multidisciplinar. Contiene todos los roles necesarios para

poder completar los objetivos de cada iteración. Cada uno realiza su

aportación desde su especialidad y experiencia y se pone a disposición

del resto cuando es necesario (por ejemplo en caso de que se esté

finalizando la iteración y sea necesario que las personas que quedan

libres colaboren en la realización de pruebas de los últimos objetivos,

siguiendo las indicaciones de la persona más experimentada).

Como se puede observar, cada iteración (un período tan corto como 2, 3 o 4

semanas) exige una fuerte colaboración entre los miembros del equipo, dado

que adquieren una RESPONSABILIDAD COMPARTIDA (respecto a los

objetivos con que se comprometen como equipo en la iteración y a las

decisiones que toman) Y MUTUA(de unos respecto a otros). Si uno falla,

pueden fallar todos.

Esto les obliga a CONVERGER, a que los conflictos y las tomas de decisiones

sean productivos. Es preciso llegar a consensos en los que nadie sienta que

algo se está haciendo mal (si alguien lo siente así, debe proponer alternativas)

[Notar que no es necesario que todos estén de acuerdo, basta con que haya

suficientes personas de acuerdo y que el resto sea capaz de “vivir con ello”].

Para conseguirlo se utilizan procesos de tomas de decisión participativas (con

propuesta y evaluación conjunta de alternativas, o bien entre todos convienen

delegar en miembros específicos) que permiten que los acuerdos sean más

duraderos, dado que todo el equipo los hace suyos y se compromete.

Los conflictos en un equipo que está trabajando con los mismos objetivos y con

responsabilidad mutua son naturales (sus miembros tienen distintas

experiencias, conocimientos) y necesarios (para obtener la mejor solución

posible fruto de sus sinergias y mejorar de manera continua). Bajo este

planteamiento, es muy importante que cuando una persona discrepe de alguna

decisión o sienta que la actitud de otra impide que el equipo sea productivo, se

sienta con suficiente libertad y confianza como para mostrar su punto de vista a

la(s) otra(s) tan pronto como sea posible, en lugar de hacer hipótesis erróneas

por falta de información, fomentar rumorología no constructiva o dejar los

problemas sin resolver hasta aceptarlos como endémicos.

Dicho esto, es muy importante que esta comunicación y feedback se realice

utilizando el mejor canal posible, cara a cara o por teléfono, en lugar de utilizar

el email (que si además expone a la otra persona al juicio de muchas otras en

copia, implica esfuerzos de autojustificación y autodefensa que restan al

avance del proyecto). La comunicación verbal, además de ser más ágil por

obtener información de manera más fluida, permite escuchar y entender mejor

las razones del otro, evita malas interpretaciones y facilita conocer las

emociones del otro. En este punto es importante no formular preguntas de

manera acusatoria y ni hacer juicios. El objetivo no es buscar culpables, sino

llegar a consensos que permitan aportar más valor al proyecto, ser más

productivos y mejorar el proceso de trabajo.

1.6.3.3.1.2 Skills de un miembro de equipo ágil

Los Skills de un miembro de un equipo ágil se pueden clasificar en varios

grupos, según se basen en aportar valor al producto que desarrolla (calidad),

en la capacidad de colaborar con el resto de miembros del equipo o en la

capacidad de mejorar, a nivel técnico y humano.

La productividad y la innovación son el resultado de:

1) Orientarse a proporcionar el máximo valor en el mínimo tiempo.

2) Favorecer la colaboración en el equipo para conseguir las mejores

sinergias posibles

3) Mejorar continuamente la manera de trabajar.

Veamos cuáles son estos grupos de Skills en más detalle:

Inteligencia de negocio - Orientación a producir valor

El miembro del equipo ágil tiene que estar orientado a producir con CALIDAD,

tiene que saber compaginar los siguientes aspectos:

• Interés por entender el producto o negocio para el que trabaja. Se

preocupa por proporcionar valor al usuario final o consumidor.

• Tener una visión a medio plazo de los objetivos a conseguir (facilitada,

por ejemplo, por la Lista de objetivos priorizada (Product Backlog), tener

proactividad (ser capaz de detectar oportunidades y anticipar riesgos) y

aún así (y dado que el foco está en proporcionar resultados tangibles

cada iteración):

o Buscar la simplicidad y la utilidad, conseguir la mejor solución

utilizando sólo el esfuerzo necesario y no trabajar en futuribles

que quizás no lleguen nunca o cambien.

o Seguir el principio de Pareto (20/80). En las tareas que realiza,

buscar el máximo retorno de inversión al esfuerzo dedicado en

cada momento, balanceando valor respecto a coste.

o En línea con el principio de fluir en el proyecto (en que el equipo

minimiza el número de objetivos en curso, WIP), el miembro de

un equipo ágil acaba tareas y no deja temas abiertos, de manera

que se minimizan los cambios de contexto, aumentando la

productividad y avanzando en el proyecto.

• Pasión y orgullo por el trabajo que se realiza, ser exigente con la calidad

técnica, disciplinado y metódico, para que el producto pueda crecer de

manera sostenida.

Inteligencia emocional – Capacidad de trabajar en equipo

El miembro del equipo ágil tiene que favorecer la COMUNICACIÓN y para ello

tener las siguientes aptitudes:

• Transparencia en las tareas que realiza y su estado, para que el resto

del equipo tenga la información necesaria (por ejemplo en las reuniones

diarias de sincronización (Scrum daily meetings) o en las retrospectivas),

que todos puedan colaborar y ayudarse a conseguir los objetivos de la

iteración, evitando también que se realicen esfuerzos innecesarios.

• Franqueza con el cliente sobre la situación del proyecto (especialmente

en las demostraciones (Sprint review)), para que pueda tomar

decisiones basadas en lo que realmente está hecho y en la velocidad del

equipo.

• No hacerse dueño de conocimiento, si no compartirlo y ser capaz para

enseñar.

• Escucha activa, entender lo que le están explicando

• Observar, escuchar, preguntar mucho y reparafrasear para entender las

necesidades, motivaciones y sentimientos de los otros, ponerse en su

lugar antes de dar la propia opinión (si realmente es necesario

ofrecerla). Es decir, evitar juzgar inmediatamente al otro y tener empatía.

El miembro del equipo ágil tiene que saber respetar las opiniones de los otros y

para ello tener las siguientes aptitudes:

• Confianza en los demás miembros del equipo, creer que serán capaces

de realizar sus tareas, sin necesidad de estar controlándolos, recordar

siempre que todos están actuando con la mejor voluntad posible, y tener

paciencia. Esta confianza se ve facilitada por la compartición de

conocimiento que se produce en las reuniones de alta productividad que

el equipo al completo realiza en las actividades de Scrum, las cuales

necesitan de la transparencia indicada anteriormente.

• Consensuar, ser capaz de negociar un ganar/ganar, no imponer su

criterio. Ser honesto y sincero, no engañar o aprovecharse de los otros

(sean clientes, gestores o miembros del equipo).

• Educación, buenas maneras, dando su opinión sin atacar ni acusar

(simplemente hablando de los hechos que le han sucedido), tranquilo,

no irascible, afable y consentido del humor, para no vivir en tensión

constante y, por contra, compartir momentos de relajación con el resto

del equipo.

Inteligencia vital – Capacidad de mejorar

El miembro del equipo ágil es capaz de conjugar el progreso técnico y el

humano, tiene afán por APRENDER nuevas formas de trabajar y de

relacionarse, y para ello tener las siguientes aptitudes:

• Humildad, evitar la prepotencia (que no es necesaria, la valía se

demuestra realizando un trabajo excelente, el reconocimiento es una

consecuencia que debe llegar por sí solo), tener una mente abierta a

escuchar ideas diferentes de otros y flexibilidad para probar nuevas

cosas.

• Capacidad de autocrítica, reconocer equivocaciones y tomarlas como

oportunidades de mejora. Similarmente, no buscar culpables cuando se

cometen errores, si no ver entre todos cómo mejorar el proceso de

trabajo.

• Capacidad de reflexión e inconformismo productivo, cuando algo no

funciona ser capaz de cuestionar cómo se están haciendo las cosas.

Tener valores, ética, integridad, coraje para tomar decisiones y hacer “lo

que se tiene que hacer” (o no hacer lo que no se tiene que hacer),

aunque sea más difícil (asumiendo riesgos controlados). Para ello

necesita ser asertivo en los mensajes, hablar de manera clara, objetiva,

ser franco (con compañeros, gestores y clientes) sobre los problemas

que hay y proponer alternativas mejores.

• Creatividad, intuición, capaz de desaprender e innovar aportando

nuevas ideas tanto en el producto como en la manera de trabajar.

• Como se ha mencionado anteriormente, tiene que ser capaz de disfrutar

en el camino, realizarse en su trabajo (son muchas horas a la semana

como para que no sea así), aprendiendo, creando, superando retos,

progresando y contagiando entusiasmo al resto del equipo.

• Evitar estar en sobreesfuerzo continuo, tener como objetivo no trabajar

más de 40 horas a la semana (en caso contrario, cuando sea necesario

un sobreesfuerzo, no va a haber de donde sacar, sin contar con que la

calidad del trabajo se degrada cuando se alarga demasiadas horas) y

dedicar el tiempo restante a actividades personales, familiares, ocio,

formarse, otros proyectos, … Es necesario disponer de tiempo para

crecer a nivel personal y profesional, para alcanzar un equilibrio y tener

estos pilares vitales afianzados.

Es más difícil, pero es mejor

Los Skills anteriores se pueden entender como un marco de referencia sobre el

que reflexionar, con el cual poder identificar nuestras carencias (y las carencias

que los demás ven en nosotros), para gradualmente ir madurando hacia un

enfoque ágil que haga más sencillo proporcionar más valor a nuestros clientes

así como disfrutar más de nuestro trabajo y de nuestra vida.

1.6.4 Herramientas (Artefactos)

1.6.4.1Lista de requisitos priorizada (Product Backlog)

La lista de objetivos/requisitos priorizada representa la visión y expectativas del

cliente respecto a los objetivos y entregas del producto o proyecto. El cliente es

el responsable de crear y gestionar la lista (con la ayuda del Facilitador y del

equipo, quien proporciona el coste estimado de completar cada requisito).

Dado que reflejar las expectativas del cliente, esta lista permite involucrarle en

la dirección de los resultados del producto o proyecto.

• Contiene los objetivos/requisitos de alto nivel del producto o proyecto,

que se suelen expresar en forma de historias de usuario. Para cada

objetivo/requisito se indica el valor que aporta al cliente y el coste

estimado de completarlo. La lista está priorizada balanceando el valor

que cada requisito aporta al negocio frente al coste estimado que tiene

su desarrollo, es decir, basándose en el Retorno de la Inversión (ROI).

• En la lista se indican las posibles iteraciones y las entregas (releases)

esperadas por el cliente (los puntos en los cuales desea que se le

entreguen los objetivos/requisitos completados hasta ese momento), en

función de la velocidad de desarrollo del (los) equipo(s) que trabajará(n)

en el proyecto. Es conveniente que el contenido de cada iteración tenga

una coherencia, de manera que se reduzca el esfuerzo de completar

todos sus objetivos.

• La lista también tiene que considerar los riesgos del proyecto e incluir los

requisitos o tareas necesarios para mitigarlos.

Antes de iniciar la primera iteración, el cliente debe tener definida la meta del

producto o proyecto y la lista de requisitos creada. No es necesario que la lista

sea completa ni que todos los requisitos estén detallados al mismo nivel. Basta

con que estén identificados y con suficiente detalle los requisitos más

prioritarios con los que el equipo empezará a trabajar. Los requisitos de

iteraciones futuras pueden ser mucho más amplios y generales. La

incertidumbre y complejidad propia de un proyecto hacen conveniente no

detallar todos los requisitos hasta que su desarrollo esté próximo. De esta

manera, el esfuerzo de recoger, detallar y desarrollar el resto de requisitos

(menos prioritarios) está repartido en el período de ejecución del proyecto. En

el caso del desarrollo de un producto, la lista va evolucionando durante toda la

vida del producto (los requisitos "emergen"). En el caso de un proyecto,

conforme éste avance irán apareciendo los requisitos menos prioritarios que

falten. Esto produce varias ventajas:

• Se evita caer en parálisis de análisis al inicio del proyecto, de manera

que se puede iniciar antes el desarrollo y el cliente puede empezar a

obtener resultados útiles.

• Se evita analizar en detalle requisitos no prioritarios que podrían cambiar

durante el transcurso del proyecto, dado que el cliente conocerá mejor

cuál ha de ser el resultado a conseguir, o bien por que podrían ser

reemplazados por otros.

• Puede llegar a un punto del proyecto en que no valga la pena analizar ni

desarrollar los requisitos restantes, dado el poco retorno de inversión

(ROI) que tienen.

1 Definición de completado (definition of done)

El cliente y el equipo tienen que acordar la "definición de completado” de los

objetivos / requisitos en el proyecto:

• Debe asegurar que el incremento de producto es potencialmente

entregable al cliente al finalizar cada iteración, que no hay tareas

pendientes que puedan impedir utilizar los resultados del proyecto lo

antes posible. De este modo, el cliente podrá tomar decisiones correctas

cuando al final de cada iteración el equipo le haga una demostración de

los requisitos completados: cambiar las prioridades en función de la

velocidad de desarrollo, solicitar una entrega del producto desarrollado

hasta ese momento, etc.

• Debe incluir lo necesario para considerar de manera clara que el cliente

obtendrá lo que necesita según sus criterios de entregables y de calidad

(producto construido, probado, documentado, refactorizado para

conseguir calidad interna/mantenibilidad, etc.).

o Además de esta definición de completado, a cada objetivo hay

que asociarle sus condiciones de satisfacción, preferiblemente en

forma de casos de prueba de aceptación, en el momento de crear

la lista de requisitos priorizada (Product Backlog).

o Notar que la definición de completado también sirve como base

para identificar las tareas necesarias para conseguir cada

objetivo/requisito, en la reunión de planificación de la iteración

(Sprint planning). Para cada objetivo se crearán más tareas que la

definición de completado (o menos) y con más significado. Por

ejemplo, respecto a que el objetivo tiene que estar “construido”,

pueden aparecer varias tareas, del estilo “construir el componente

X”, “modificar la pantalla Y”, “modificar la BBDD”, “preparar el

script de carga”, etc.

2 Iteración de entrega (release sprint)

Cuando el cliente solicita una entrega de los objetivos/requisitos completados

hasta ese momento, el equipo puede necesitar añadir una iteración de entrega,

más corta que las iteraciones habituales, donde realizar alguna tarea que no ha

sido necesaria o posible hasta el momento de la entrega final y acabar de

corregir defectos detectados en la última demostración.

3 Uso de la lista

• Para medir la velocidad de desarrollo del equipo, ver una progresión

constante y extrapolar la fecha de las entregas, es conveniente seguir

las siguientes recomendaciones:

o Los requisitos deben tener un esfuerzo semejante para ser

completados.

o La estimación de un requisito no debe ser superior a 10 días (si

las iteraciones son de 20 días laborables).

• Cada requisito tiene asociado un factor de complejidad, que permite

ajustar su coste estimado en función de la incertidumbre de la

complejidad de su desarrollo en el momento de introducirlo en la lista.

Este factor de coste se irá ajustando conforme las iteraciones avancen y

el equipo conozca mejor el producto o proyecto, su contexto y su

velocidad de desarrollo con las herramientas y tecnologías que utiliza.

• Si un requisito depende de otro, se coloca en algún punto por debajo del

que depende.

• Si un requisito no se finaliza en una iteración, se le vuelve a poner en

alguna de las siguientes iteraciones, indicando el coste pendiente de

desarrollo.

• El "origen" permite saber quién podría participar en la definición de un

objetivo/requisito y sería conveniente que estuviese presente en el

momento de su demostración.

El progreso del proyecto y su velocidad con respecto a requisitos completados

se muestra en un gráfico de trabajo pendiente (Burndown chart).

1.6.4.2Lista de tareas de la iteración (Sprint Backlog)

Lista de tareas que el equipo elabora en la reunión de planificación de la

iteración (Sprint planning) como plan para completar los objetivos/requisitos

seleccionados para la iteración y que se compromete a demostrar al cliente al

finalizar la iteración, 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 autoasignación que han hecho los miembros del

equipo.

El progreso de la iteración y su velocidad con respecto a tareas u horas

pendientes se muestra mediante un gráfico de trabajo pendiente (Burndown

chart).

Uso de la lista

• Los objetivos/requisitos están ordenados por orden de prioridad para el

cliente.

o Por ello, signos de falta de foco, problemas o impedimentos

serían que se estén completando objetivos que no son los

primeros de la lista, así como tener demasiados

objetivos/requisitos en progreso simultáneamente.

• Si una tarea depende de otra, se coloca en algún 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 tamaño

permitirá:

o Que las tareas sean suficientemente pequeñas como para poder

detectar progreso o estancamiento de manera diaria.

o Que las tareas no sean muy pequeñas, que sean suficientemente

relevantes, no generen ruido ni microgestión.

o Medir la velocidad de desarrollo del equipo y extrapolar si es

posible finalizarlas dentro de la iteración.

El tablero de tareas (Scrum Taskboard)

La lista de objetivos a completar en la iteración (Product Backlog Items) se

puede gestionar mediante un tablón 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 más pequeños 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 reunión de

planificación de la iteración. La lista va evolucionando (nuevas tareas, cambios,

estado, esfuerzo pendiente...) a medida que la iteración avanza, especialmente

durante la reunión diaria de sincronización.

Este tablón o cuadro de mandos actúa como radiador de información tanto para

el equipo como para cualquier otra persona relacionada con el proyecto.

1.6.4.3Gráficos de trabajo pendiente (Burndown Chart)

Un gráfico de trabajo pendiente a lo largo del tiempo muestra la velocidad a la

que se está completando los objetivos/requisitos. Permite extrapolar si el

Equipo podrá completar el trabajo en el tiempo estimado.

Se pueden utilizan los siguientes gráficos de esfuerzo pendiente:

• Días pendientes para completar los requisitos del producto o proyecto

(product burndown chart), realizado a partir de la lista de requisitos

priorizada (Product Backlog).

• Horas pendientes para completar las tareas de la iteración (sprint

burndown chart), realizado a partir de la lista de tareas de la iteración

(Iteration Backlog).

Este tipo de gráfico permite realizar diversas simulaciones: ver cómo se

aplazan las fechas de entrega si se le añaden requisitos, ver cómo se avanzan

si se le quitan requisitos o se añade otro equipo, etc.

1.7 Scrum vs. Metodologías Tradicionales

El uso regular de las buenas prácticas de Scrum (entregas frecuentes

priorizadas por valor, potenciación del equipo de trabajo, mejora continua de

producto y de proceso...) permite que los cambios dentro de un proyecto sean

aceptados de manera natural y proporciona al cliente margen para flexibilidad e

innovación así como productividad y calidad.

Las metodologías tradicionales ya mencionaban las prácticas y conceptos

utilizados en Scrum, llegando a utilizarlos en mayor o menor medida y

prometiendo también un mejor resultado en los proyectos. Sin embargo no

utilizan estas prácticas en el las etapas específicas del proceso de desarrollo,

sino que lo hacen de forma general a todo el proyecto.

El desarrollo iterativo e incremental ya existía antes. La diferencia es que en

Scrum la planificación del proyecto hace explícitos los objetivos del cliente y los

prioriza en función del ROI (Return of Investment), es decir, balanceando el

valor aportado al cliente respecto a su coste de desarrollo, y minimizando el

trabajo en curso (Work In Progress) necesario para obtener un resultado. Si en

las metodologías tradicionales el cliente tenía que esperar a tener todo el valor

de un proyecto el último día de la última fase, habiendo acumulando todos los

retardos de todas las fases, en cambio con Scrum el cliente puede dirigir de

manera sistemática y regular (cada iteración) los resultados que va obteniendo

del proyecto. De esta manera (y siguiendo la ley de Pareto en que el 20% del

esfuerzo proporciona el 80% del valor), el cliente puede empezar antes a

recuperar su inversión (y/o autofinanciarse) comenzando a utilizar un producto

al que sólo le faltan características poco relevantes, puede sacar al mercado un

producto antes que su competidor, puede ir adaptándolo mejor a las

necesidades de los clientes y hacer frente a urgencias o nuevas peticiones.

La orientación a personas ya se practicaba antes, sólo que se basaba en

aspectos relacionados con la ejecución de cada persona y condicionados a la

subjetividad del evaluador. En Scrum, en cambio, dado que el equipo es

multidisciplinar (incluye a todas las personas necesarias para llevar a cabo el

proyecto) el planteamiento es de potenciación del equipo (team empowerment),

de darle responsabilidad y autoridad para que decida cómo funcionar de la

manera más eficiente posible, mejore su entorno de trabajo y pueda mostrar

resultados de manera regular, así como permitirle aportar innovación al

producto que está desarrollando, cosa que facilita la motivación y realización

personal de cada uno de sus miembros.

La planificación con tareas, tiempo y personas ya se hacía antes, sólo que en

las metodologías tradicionales las tareas, las asignaciones y los tiempos las

decidía un jefe de proyecto. Sin embargo, en Scrum la planificación de proyecto

se hace orientada a objetivos del cliente (y no a tareas) y la realiza el equipo

utilizando técnicas muy rápidas de estimación (por ejemplo planning poker).

Asimismo, la planificación de iteración también la hace el equipo, quien

identifica y estima de manera conjunta las tareas a realizar y se las autoasigna.

De esta manera, las estimaciones son mucho más fiables por que se realizan

en base a las experiencias e información de todos los miembros del equipo y

dado que las han proporcionado ellos se convierten en compromiso.

El control del progreso del proyecto orientado a tareas ya se hacía antes, con el

jefe de proyecto preguntando a cada persona el estado en que se encuentran

sus tareas. Sin embargo, en Scrum el equipo se compromete y reporta

diariamente su avance y problemas respecto al resto de miembros del equipo,

con lo que la sinergia, la transferencia de información, de experiencias y de

soluciones es mucho más alta. En Scrum, en lugar de un responsable del

equipo/proyecto hay un facilitador que garantiza la colaboración entre todos los

participantes.

La gestión de cambios ya existía antes, era un control férreo para impedir que

el proyecto se moviese tanto en alcance, como en tiempo como recursos. En

cambio, el planteamiento que se hace en Scrum, es el de aceptar que los

cambios son naturales y permitirlos en el inicio de cada iteración (ya que

todavía no se ha desarrollado nada respecto a futuros objetivos), una vez se ha

demostrado al cliente los resultados obtenidos en la iteración anterior, para

darle más flexibilidad en la adaptación del producto a sus necesidades

(siguiendo unas reglas de alcance variable que permiten que tanto el cliente

como el proveedor ganen [2]).

Las retrospectivas y los análisis “post mortem” (para mejorar los proceso de

trabajo) ya se hacían antes, sólo que normalmente al final de un proyecto o de

una gran fase. Sin embargo, en Scrum las retrospectivas se hacen al final de

cada iteración, de manera que el equipo pueda aprender y sea más productivo

dentro del mismo proyecto.

El timeboxing era una herramienta conocida anteriormente. La diferencia ahora

es el uso de timeboxing para todas las actividades de Scrum, de manera que

facilite el enfoque en resultados y la toma de decisiones.

El enfoque de Scrum exige utilizar estas prácticas de manera regular y

frecuente para así proporcionar flexibilidad, productividad, innovación y calidad,

teniendo como base la colaboración entre las personas que participan. En el

pensamiento ágil prima la colaboración y transparencia con el cliente y entre el

equipo, para así reducir riesgos, cubrir al máximo posible las expectativas del

cliente, mejorar de manera continua los productos y procesos, ganar en

creatividad y disfrutar más en la realización del trabajo [3].

Aplicar estas prácticas de forma sistemática en el día a día de los proyectos

puede no ser fácil (e incluso puede no ser idóneo), bien por que la cultura de la

empresa no está alineada (no se trata de una cultura colaborativa [4]) o bien

por qué se desconocen las técnicas sobre cómo aplicarlos. Afortunadamente,

para iniciarse en el mundo ágil actualmente ya existe abundante material [5],

tanto gratuito como de pago, así como comunidades y eventos para el

intercambio de experiencias.

Metodología scrum

Documents

Transcript of Metodología scrum