PDF de programación - Un mejor Scrum

Un
Mejor
Scrum

Un conjunto no oficial de consejos e
ideas sobre cómo implementar Scrum

Escrito por el Coach y Entrenador Certificado de Scrum Peter Hundermark

Traducción por Alan Cyment, Entrenador Certificado de Scrum

ScrumSense

Leaders in facilitating lasting Agile change

scrumsense.com

¿Por qué esta guía?
Jim York, Entrenador Certificado de Scrum, dijo una vez: Scrum es Simple. Hacer
Scrum es difícil. ℠
Una gran parte de aquellos con los que he trabajado en distintas organizaciones dicen
que les resulta muy difícil saber por dónde empezar a la hora de utilizar Scrum. Otras
organizaciones tienen equipos que ya están siguiendo varias prácticas ágiles y, sin
embargo, están muy lejos de convertirse en lo que Jeff Sutherland describió alguna
vez como hiper-productivos.
Espero de corazón que este pequeño libro sea una fuente de inspiración para
ayudarte a practicar un mejor Scrum. Por sobre todas las cosas aspiro a que te ayude
a recorrer el duro camino que va de las viejas formas de trabajar que, simplemente, no
funcionan hacia nuevas maneras de encarar la labor cotidiana, que te permitirán
obtener más calidad, entregar antes y, sobre todas las cosas, pasarla un poco mejor.
Por favor hazme saber si ha sido de tu agrado y cómo puedo hacer para mejorarla.
¡Y ahora, simplemente ve y hazlo!

Peter Hundermark
Ciudad del Cabo, noviembre de 2009
Segunda edición

Traducción: Alan Cyment
Buenos Aires, agosto de 2011



Un mejor Scrum ∙ 1

¿Qué es Scrum?
Orígenes
Scrum es un framework para el manejo de proyectos que tienen como fin el desarrollo
de productos complejos. Scrum tiene sus orígenes en los campos del manejo del
conocimiento, los sistemas adaptativos complejos y la teoría de control empírico de
procesos. Ha sido influenciado también de patrones observados durante el desarrollo
de software y la Teoría de las Limitaciones.

Scrum y Agilidad
Scrum es el más popular de los métodos Ágiles. Se utiliza frecuentemente en
conjunto con Extreme Programming (XP).

¿Cuál es el problema?

‣
‣
‣
‣
‣

Los releases toman demasiado tiempo
La estabilización toma demasiado tiempo
Los cambios son difíciles de llevar a cabo
La calidad decae
Las marchas mortuorias no dejan de herir la moral

Durante décadas los desarrolladores de software han intentado emplear métodos
definidos de trabajo y administración de proyectos. Los métodos definidos son
apropiados cuando las variables que ingresan al sistema se encuentran bien definidas
y el método por el cual se las transforma en resultados es predecible. El desarrollo de
software y otras formas de trabajo complejos no encajan con esa clase de métodos.
El alto grado de proyectos fallidos e insatisfacción de los cliente ilustra esto con
claridad.

¿Cómo ayuda Scrum a resolver esto?
Alistair Cockburn [Cockburn 2008] describe al desarrollo de software como un ‘juego
cooperativo de invención y comunicación’.
Las metodologías de trabajo tradicionales se basan en documentos para plasmar y
comunicar conocimiento de un especialista al siguiente. Los ciclos de
retroalimentación son demasiado largos o incluso no existen. Décadas de proyectos
con bajísima productividad demuestran que esta manera de trabajo lleva
indefectiblemente al fracaso.

2 ∙ Un mejor Scrum

‣ El equipo recibe objetivos claros
‣ El equipo se organiza en función del trabajo a realizar
‣ El equipo entrega con regularidad las funcionalidades más valiosas
‣ El equipo recibe retroalimentación de individuos que se encuentran fuera del
‣ El equipo reflexiona sobre su manera de trabajar, con el objetivo de mejorar
‣
‣ El equipo y la gerencia se comunican entre sí de manera honesta,

La organización completa posee visibilidad sobre el progreso del equipo

equipo

Scrum provee una plataforma para que la gente trabaje en conjunto de manera
efectiva, a la vez que permite exponer de manera implacable cualquier problema que
se ponga en su camino.
La esencia de Scrum
La esencia de Scrum es:

transparentando progreso y riesgos.

Esta forma de trabaja se basa los siguientes valores: respeto por uno mismo y por los
otros, confianza y coraje.

¿Por qué Scrum no hace mención de ninguna práctica
de desarrollo de software?
Scrum no tiene como objetivo dar instrucciones a los equipos sobre la forma en la
que deben llevar a cabo su trabajo. Scrum espera que los equipos hagan lo que sea
necesario para entregar el producto esperado, brindándoles la potestad para ello. Las
prácticas y herramientas de desarrollo cambian y mejoran de manera continua y los
buenos equipos trabajarán constantemente en pos de obtener el mejor uso de las
mismas.

Aplicabilidad
Si bien es cierto que Scrum fue utilizado por primera vez para desarrollar productos
de software, está diseñado para cualquier tipo de trabajo complejo. Hoy en día se
utiliza para gerenciar desarrollo de software y hardware, publicidad, marketing, iglesias
y organizaciones enteras.

¿Cómo se mapea Scrum con los métodos
tradicionales?
La respuesta rápida es que no existe tal mapeo. La agilidad y Scrum en están basado
en un paradigma distinto. Los fundadores Jeff Sutherland y Ken Schwaber han



Un mejor Scrum ∙ 3

repetido en numerosas ocasiones que es inútil intentar mapear métodos definidos con
un método empírico.

¿Tendrá éxito Scrum en mi organización?
¡Eso depende de ti! La implementación en tu organización puede llegar a fallar debido
a la falta de voluntad de sus integrantes para resolver los problemas que Scrum
expondrá. Sin embargo miles de equipos en todos los continentes y en decenas e
industrias están convirtiendo día a día su mundo laboral en uno mejor que el que era
ayer.

4 ∙ Un mejor Scrum

El manifiesto ágil

En febrero de 2001 diecisiete expertos en metodologías “livianas” se encontrar para
discutir y tratar de llegar a una definición en común de las maneras de trabajo que
estaban utilizando. Entre ellos se encontraban Jeff Sutherland y Ken Schwaber,
fundadores de Scrum, junto a Mike Beedle ,quien trabajó en desarrollar los patrones
iniciales y en la redacción del primer libro sobre Scrum. Este grupo se autodenominó
“The Agile Alliance” (la Alianza Ágil) y definió de común acuerdo el Manifiesto para el
Desarrollo Ágil de Software. Definió también un conjunto de doce principios que
respaldan el manifiesto. Ambos se encuentran reproducidos en la página siguiente

Comentario
El Manifiesto Ágil y sus doce principios han permanecido incólumes durante ya diez
años. Continúan siendo hoy en día la mejor manera de juzgar si un método de trabajo
es o no realmente ágil. La mayor crítica que ha recibido se debe al sesgo que
presenta hacia el desarrollo de sotware, dado que los métodos ágiles pueden
aplicarse en muchos más campos.

Nota
Scrum es una manera particular de desarrollo ágil. Seguir el Manifiesto Ágil y sus
principios no implica necesariamente que una organización o equipo esté utilizando
Scrum. ¡Sin embargo, el incumplimiento de CUALQUIERA de estos principio implica
que no se está utilizando Scrum!

Manifiesto por el Desarrollo Ágil de Software
Estamos descubriendo formas mejores de desarrollar software tanto por nuestra
propia experiencia como ayudando a terceros. A través de este trabajo hemos
aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas
Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan

Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la
izquierda.



Un mejor Scrum ∙ 5

Principios del Manifiesto Ágil
1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y

continua de software con valor.

2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo.
Los procesos Ágiles aprovechan el cambio para proporcionar ventaja competitiva
al cliente.

3. Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto.

4. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el

entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.

5. El método más eficiente y efectivo de comunicar información al equipo de

desarrollo y entre sus miembros es la conversación cara a cara.

6. El software funcionando es la medida principal de progreso.
7. Los procesos Ágiles promueven el desarrollo sostenible. Los promotores,

desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante
de forma indefinida.

8. La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
9. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es

esencial.

10. Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-

organizados.

11. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a

continuación ajustar y perfeccionar su comportamiento en consecuencia.

Highsmith (2001)

Los roles en Scrum
Introducción
No existe el rol de gerente de proyecto en Scrum. Las responsabilidades del clásico
gerente de proyecto se encuentran divididas en los tres roles que conforman el
Equipo Scrum:

‣ El Product Owner gestiona el producto (y el retorno de la inversión)

6 ∙ Un mejor Scrum

‣ El ScrumMaster gestiona el proceso
‣ El equipo se gestiona a si mismo

Esto resulta desafiante para aquellos que hoy en día desempeñan ese rol y para los
gerentes de las organizaciones en las que trabajan. Michele Sliger y Stacia Broderick
han escrito una útil guía de transición de gerente de proyecto a coach ágil [Sliger y
Broderick 2008].
No existen líderes designados en el Equipo Scrum más allá del Product Owner y el
ScrumMaster; no es necesario. La necesidad de gerentes de línea se reduce dado
que los equipos se administran a si mismos en un gran abanico de responsabilidades.
No es extraño encontrar 50 miembros de equipos que reportan directamente a un
único gerente de línea