¿Por qué fallan las implementaciones de Scrum?

Respuesta: porque desconocemos los valores y principios del Manifiesto Ágil punto

El Manifiesto por el Desarrollo Ágil de Software

La razón que expuse es apenas una de las muchas por las cuales podemos fracasar al intentar Scrum. Para hacerle frente, entonces es necesario conocer de qué se trata exactamente el Manifiesto Ágil. Este lo encontramos en http://www.agilemanifesto.org/iso/es/. Sin embargo, lo copiaremos aquí para explicar mejor el asunto que nos ocupa:

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.

Estos son los valores. Le siguen una docena de principios que pueden encontrar en la página que mencioné antes. Este texto parece inofensivo pero encierra una enorme carga emocional; sin embargo, lo más importante es que nos enseña justamente cómo debemos enfrentar los proyectos de construcción de software actuales. Y como leerlo es más fácil que entenderlo, en la sección de Referencia enumero algunos de los artículos de mi Gazafatonario IT que intentan explicar de una u otra forma la razón de ser de este manifiesto.

Algunas recomendaciones para tener éxito al implementar Scrum

• No piense en herramientas antes que en el proceso y no piense en el proceso antes que en las personas y sus interacciones. ¿Cómo va a lograr que las persones interactúen entre sí? “La gente tiene que trabajar cara a cara” dice el mismísimo Jeff Sutherland, y para todos Scrum debe ser una forma de hacer, una forma de ser, una forma de vida. Esto es, valorar el valor “Personas e interacciones sobre procesos y herramientas” del Manifiesto Ágil.
• Necesitamos herramientas, sí, pero no permitamos que estas nos dicten el proceso e indiquen el camino a seguir, lo último que queremos son productos de software costosos antes de lograr que Scrum funcione o antes de lograr los primeros resultados exitosos con el método. Además, necesitamos un proceso para gestionar toda una operación, desde la concepción de los productos hasta la puesta en funcionamiento de los mismos a cabal satisfacción de los usuarios/clientes; y el núcleo de ese proceso debe ser precisamente Scrum, tal y como dice la Guía, no es necesario “inventar” nada más.
• Tampoco es necesario eliminar o agregar nada más a Scrum como marco de gestión. Por ejemplo, decir que hacemos Scrum pero no tenemos Dueño de Producto o usar el patrón proxy del Dueño de Producto, es algo común en las implementaciones deslucidas de Scrum. Uno de los principios del Manifiesto Ágil lo dice claramente: “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto.” Esto apunta a resolver la mayor causa de fracaso en los proyectos tradicionales: “falta de involucramiento del usuario” [7]. 
• No piense que Scrum le va a solucionar todos sus problemas, incluidos los personales. Scrum no es una bala de plata [4], de hecho, Scrum por sí solo no es suficiente, debe acompañarse de un conjunto de prácticas y otros métodos preferiblemente ágiles. Eso sí, no intente implementarlos todos de una sola vez y mucho menos intente hacerlo solo, hágase acompañar de expertos, de personas que hayan recorrido el camino y que quizás hayan cometido uno o dos errores críticos; con seguridad, serán ellos quienes lo sacarán del aprieto en el que posiblemente se va a encontrar más de una vez.

• No piense en las certificaciones. Si cree que les hacen falta, estas llegarán a su debido tiempo. Cuando tenga la suficiente experiencia y madurez para darse cuenta que no las necesita. Sí, certificarse nos trae beneficios a nosotros como individuos y a las organizaciones para las que trabajamos o representamos. La certificación verifica que nuestro nivel de pericia y conocimiento es consistente con los estándares de la profesión en un área específica, pero, también a veces, las certificaciones atribuyen competencias donde usualmente no las hay, a quienes usualmente no las tienen.
• Uno de los aspectos que hacen “mágico” a Scrum es que podemos implementarlo usando Scrum. La gran ventaja es que no tenemos que definir un proceso porque ya está definido [8]. Podemos tener una Lista de elementos a implementar (el backlog) y los separamos en sprints de 2 semanas para ir implementando gradualmente en unos pocos meses. Esto permitirá que las personas se sientan cómodas y a gusto con el cambio y se logren mejores resultados más rápidamente.

En cada Sprint de implementación de Scrum realice las ceremonias orgánicas de Scrum:

1. Planee cada sprint de la implementación
2. Haga reuniones diarias
3. Al final de cada sprint revise los resultados
4. Antes del siguiente sprint, haga una retrospectiva de lo que fue bien y lo que fue mal durante el sprint actual de implementación 

Se me ocurre que podríamos usar, para empezar, este algoritmo general de la implementación de Scrum:

Figura 1: Algoritmo general de la implementación de Scrum usando Scrum

Esta es una primerísima versión del algoritmo a “mano alzada”, escucho opiniones al respecto.

Otras Recomendaciones a tener en cuenta para asegurar el éxito en una implementación de Scrum

• Todo el equipo debe tener un pensamiento Ágil.
• Debe haber un alto grado de cohesión en el equipo, incluyendo a los usuarios.
• Centrado en el usuario
• Transparente, es decir, todos deben conocer el estado del proyecto en cualquier momento
• Debe predominar la Cultura de la Calidad
• Debe haber retroalimentación continua de todos los participantes
• Manejo de riesgos conjunto
• Se requiere disciplina
• El equipo debe tener un experto en métodos ágiles en general y en Scrum en particular para hacer coaching y acompañamiento continuo.
• Participe o, al menos, manténgase en contacto con otras personas que estén usando Scrum: la Comunidad Ágiles Colombia [9] es un buen ejemplo de ello; la de Ágiles Latinoamérica [10] también.

Finalmente, cuando tenga la suficiente experiencia y cuente con equipos maduros, quizás antes, atrévase a adicionar sus propios valores al Manifiesto Ágil y póngalos en práctica. Ya en la comunidad Ágiles estamos discutiendo algunos de esos nuevos valores y principios:

Experiencia efectiva sobre certificaciones retóricas

Innovación continua sobre mantenimiento de productos

Satisfacción del Cliente sobre margen de utilidad

Felicidad de las personas sobre inapetencia profesional

¿Se animan con otros? Pueden dejarme sus comentarios o ir al foro de la comunidad Ágiles Colombia y participar de la discusión. Lo encuentran en:

https://groups.google.com/forum/#!topic/agiles-colombia/Cd3QJRnHYEo

Referencias

Scrum – Lo Fundamental

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

Scrum Orgánico para Iniciantes

http://www.gazafatonarioit.com/2013/05/scrum-organico-para-iniciantes.html

Vademescrum, Sección I: El Scrum Master 1

http://www.gazafatonarioit.com/2013/06/vademescrum-seccion-i-el-scrum-master-1.html

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

http://www.gazafatonarioit.com/2013/06/mitos-monstruos-leyendas-urbanas-y.html

Planificación del Sprint: el primer paso para producir el máximo efecto

http://www.gazafatonarioit.com/2013/09/planificacion-del-sprint-el-primer-paso.html

Gerentes de Proyectos de software, ¿una especie en vías de extinción?

http://www.gazafatonarioit.com/2013/09/gerentes-de-proyectos-de-software-una.html

Chaos Report. Standish Group. www.standishgroup.com/‎

La Guía de Scrum. http://www.scrum.org/scrum-guides‎

Ágiles Colombia. http://agilescolombia.org/

Ágiles Latinoamérica. http://www.agiles.org/‎

Historias de Usuario Altamente Efectivas 4

VademeScrum, Sección 2: Las Historias de Usuario 4

Cualidad :: Valiosa (y Valuada)

Las Historias de Usuario deben tener Valor para los usuarios

Veamos esta situación:

Historia de Poco Valor

Como: Lector del blog

Quiero: ver la lista de temas tratados en el blog

Para: buscar las entradas que más se acomoden a mis intereses personales

Es mejor escribir esta historia desde el punto de vista del Bloguero:

Historia de Mucho Valor

Como: Bloguero

Quiero: mostrar a los lectores los nuevos temas tratados en mi blog

Para: que ellos continúen más propensos a leer más entradas del blog

Con esta historia tenemos una perspectiva más clara del valor real de la historia. La implementación de esta podría llevar a más lectores a leer más entradas del blog con lo que se incrementaría el tráfico en el sitio Web y posicionarían al bloguero como experto en los temas de su dominio. Mientras que ambas historias son pequeñas, negociables, independientes, y pueden tener los demás atributos de las buenas historias de usuario, el valor de la segunda es mucho más alto para el negocio que el valor de la primera.

Al negociar la funcionalidad de una historia también tenemos en cuenta su valor para el negocio. Una visión que siempre debemos tener los equipos ágiles es encontrar ese 20% de la funcionalidad que se usa el 80% de las veces o ese 20% del producto que tiene el 80% del valor para el negocio, recordemos que la filosofía ágil se basa en entregar valor al usuario. Esto quiere decir que si tenemos una funcionalidad como la siguiente:

Como: Bloguero

Quiero: ingresar a mi blog con usuario y contraseña

Para: mantener la seguridad y confiabilidad de la información del blog

Criterios de Aceptación:

• Debo ser capaz de cambiar la contraseña cuando lo desee
• El sistema debe enviarme un correo electrónico para confirmar el cambio de contraseña
• El usuario puede ser un nombre seleccionado por mí o una dirección de correo electrónico
• El sistema debe bloquear la cuenta cuando haga tres intentos fallidos consecutivos
• El sistema debe permitir que ingrese automáticamente si uso el mismo computador o dispositivo
• Si olvidé la contraseña, el sistema debe preguntarme por la dirección de correo asociada a mi cuenta o por mi nombre de usuario y enviarme un enlace para establecer una nueva contraseña
• [Siguen…]

Esta es, a todas luces, una historia que se puede dividir en varias historias dado el alto número de criterios de confirmación que tiene. Con los usuarios buscamos lo que proporcione mayor valor para el negocio y lo que se vaya a usar más, por ejemplo: “el sistema debe permitir establecer una nueva contraseña cuando lo desee”, y salir en la primera iteración o entrega con esta funcionalidad. Las demás se van adicionando a medida que avanzan las iteraciones o las entregas. Y como antes, algunos de estos criterios quizás nunca lleguen a implementarse, por ejemplo, el de bloquear la cuenta después de varios intentos errados.

Finalmente, quien mejor conoce el valor de una historia de usuario es precisamente el usuario, personificado en alguien como el Dueño del Producto, que habla como una sola voz ante el equipo de desarrollo y que representa los intereses del negocio. Es a esta persona a quien debemos apoyar para que los esfuerzos de desarrollo sean conducidos efectiva y eficientemente.

A estas alturas solo hace falta recordar que el Valor es el atributo más importante en el modelo INVEST. Cada historia de usuario debe proporcionar algún valor, el mayor posible, al usuario, al cliente o a cualquier interesado en el producto. Con esto en mente, debemos entonces reorientar nuestras estructuras de descomposición funcional del software de un enfoque horizontal a uno vertical, esto es, para el usuario o interesado no tiene prácticamente ningún valor si cierta funcionalidad requiere de uno o varios procedimientos almacenados, o de uno o varios componentes en las capas intermedias de la solución.

El usuario necesita de la funcionalidad que le permite interactuar con el sistema, es lo que tiene valor para él/ella. Entonces debemos crear historias que atraviesen la arquitectura para poder presentar valor al usuario y obtener así la mejor retroalimentación en el menor tiempo posible. Esto es consistente con los modelos de gestión ágiles como Scrum, donde el Dueño de Producto es quien orienta los esfuerzos del equipo de desarrollo y prioriza las historias de usuario teniendo en cuenta su valor para el negocio. Y normalmente el Dueño de Producto no conoce de los aspectos puramente técnicos que subyacen a una historia de usuario (procedimientos almacenados, clases, componentes, Web services, etcétera).

En este punto llegamos al no menos peliagudo asunto de los requisitos técnicos o no funcionales, del software. Dos estrategias se usan habitualmente: la primera de ellas es que estas condiciones técnicas hagan parte de los criterios de aceptación de la historia, como en:

Como: Editor

Quiero: establecer el período de expiración de la contraseña

Para: que los blogueros se vean forzados a cambiar sus contraseñas periódicamente.

Criterios de Aceptación:

• La contraseña se debe poder cambiar antes de finalizar el período de expiración
• Ninguna persona distinta a su creador debe tener acceso a la contraseña

El segundo criterio, relacionado con el acceso a la contraseña, es una restricción típica de seguridad que bien puede ser establecida por un usuario, en este caso, por el Editor; también puede ser un Administrador de la Aplicación. Este enfoque de incluir las características no funcionales de una historia como parte de esta tiene la ventaja de permitir al mismo usuario reconocer su valor y al equipo completo de negociar su implementación.

La segunda táctica es crear historias independientes para cada propiedad o condición técnica, o para un grupo de estas, como en:

Como: Bloguero

Quiero: que mis entradas de blog soporten hasta 10 mil comentarios cada una

Para: mantenerme en contacto con el mayor número de personas posible

Criterios de Aceptación:

• Cada comentario debe contener hasta 500 palabras o 4000 caracteres

En este ejemplo, tanto la acción expuesta en la historia de usuario, como el criterio de confirmación son requisitos no funcionales que se pueden implementar. Este segundo enfoque ayuda a independizar las historias de usuario y a aplicar criterios a un grupo de funcionalidades (este no es el caso en el ejemplo); sin embargo, estas historias tienen la desventaja de que los usuarios o interesados (el Dueño del Producto) no le vean ningún valor y son difíciles de negociar con ellos/ellas.

En la práctica se usa una combinación de las dos estrategias. Ahora bien, hay que decir es que no existe tal cosa como la historia del desarrollador o la del arquitecto del software, ni mucho menos la del Dueño del Producto, como en:

Historias de Poco o Ningún Valor

Como: Desarrollador

Quiero: matricular mi aplicación en Jenkins

Para: tener integración continua automatizada

Como: Arquitecto

Quiero: que las transacciones de la aplicación se tarden menos de 1 segundo

Para: poner en producción una solución de alto desempeño

Como: Analista de Pruebas

Quiero: automatizar los casos de prueba de la aplicación

Para: hacer pruebas de regresión de manera eficiente y efectiva

Como: Desarrollador

Quiero: implementar el procedimiento almacenado spAdicionarComentario

Para: que la aplicación tenga la capacidad de añadir comentarios a las entradas de blogs

Simplemente estas historias no deberían existir, de hecho, no son historias de usuario del todo, ningún usuario final las usa. Para el usuario no es importante, por ejemplo, donde se registran los errores de una aplicación, quizás ni le interese si se registran en alguna herramienta; tampoco es de valor conocer el número de inconformidades que tiene el código fuente frente a las buenas prácticas de programación. El usuario da por hecho que el equipo de desarrollo sabe, precisamente, construir productos de software y que le va a entregar el mejor posible y el de mayor valor.

Conclusiones Finales

Es un hecho, sin importar que tanto trabajemos como equipo de desarrollo en poner a punto el ambiente de pruebas, en tener los mejores servidores de integración continua disponibles, en usar las mejores prácticas de escritura de código fuente, en crear componentes reutilizables de alta calidad o procedimientos almacenados optimizados, el Bloguero de nuestro sistema de publicaciones no puede crear una entrada de blog con el reporte que genera el analizador de código estático de nuestro entorno de desarrollo al compilar el código fuente, ni con las docenas o cientos de procedimientos almacenados implementados sobre el motor de la base de datos, ni con la implementación del algoritmo Blowfish para encriptar las contraseñas.

Simplemente necesita de una interfaz de usuario que pueda utilizar para realizar todas sus operaciones.

Artículos Relacionados

El artículo donde presento las Historias de Usuario, a manera de introducción: Historias de Usuario: un nuevo orden en los requisitos del software, lo encuentran en:

http://www.gazafatonarioit.com/2013/07/historias-de-usuario-un-nuevo-orden-en.html

La primera parte de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 1. Lo encuentran en:

http://www.gazafatonarioit.com/2013/07/escribiendo-historias-de-usuario.html

La parte 2 de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Independiente. Lo encuentran en:

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario.html

La parte 3 de esta serie de artículos sobre los atributos INVEST y las buenas historias de usuario: Historias de Usuario Altamente Efectivas, Parte 2 – Cualidad :: Negociable. Lo encuentran en:

http://www.gazafatonarioit.com/2013/08/escribiendo-historias-de-usuario_12.html

Referencias

• INVEST in Good Stories, and SMART Tasks:

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/

• A User Story Primer, by Dean Leffingwell with Pete Behrens
• User Stories Applied, by Mike Cohn

Vademescrum, Sección I: El Scrum Master 1

El Vademescrum

No se trata de un lapsus calami ni de ninguna charada. Simplemente usé un procedimiento morfológico para crear una nueva palabra cuyo significado se hará evidente en breve. Usando el formato de la Academia de la Lengua, podemos decir que Vademescrum proviene de Vademécum (obra de referencia que contiene las nociones más importantes de una materia, ya sea ciencia o arte) y de Scrum (marco de trabajo liviano y adaptativo para desarrollo iterativo e incremental de software). El Vademescrum es, por lo tanto, una especie de marco referencial de Scrum y de sus componentes.

Vademescrum, Sección I: El Scrum Master 1

Entrando en materia, el Scrum Master es quien inspira los valores y las prácticas de Scrum en todo el equipo Scrum y, junto con otros Scrum Masters, en la organización. Es quien debe llevar al equipo a jugar Scrum Extremo y que lo haga a su máxima capacidad. El SM es como el médico que prescribe una receta o régimen a su paciente (el equipo Scrum) y se asegura de su cumplimiento y, aunque el SM no tiene autoridad sobre el equipo, sí tiene autoridad sobre el proceso Scrum que se sigue, por ejemplo, puede tomar la decisión de cambiar la duración de los sprints.

El SM también busca en las entrañas del proyecto y del equipo para encontrar los motivos por los que algo salió mal, por ejemplo, si no se entregó software potencialmente distribuible, probado y funcionando, al final de un sprint, o si el equipo no logró la velocidad esperada, o simplemente el por qué no se alcanzó la definición de Hecho (Done), o que los miembros del equipo no estén “anclados” en roles específicos. El Scrum Master también sirve como un escudo insalvable del equipo de interferencias externas, por ejemplo, cuando un interesado quiere modificar el alcance o la duración de un sprint, o ambos.

La guía de Scrum dice además que:

“El Scrum Master es el responsable de asegurar que Scrum es entendido y llevado a cabo. Los Scrum Masters hacen esto asegurándose de que el Equipo Scrum trabaja ajustándose a la teoría, prácticas y reglas de Scrum. El Scrum Master es un líder servil, al servicio del Equipo Scrum. El Scrum Master ayuda a las personas externas al Equipo Scrum a entender qué interacciones con el Equipo Scrum pueden ser de ayuda y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones, para maximizar el valor creado por el Equipo Scrum.”

Ahora bien, cuando un Scrum Master se une a un equipo, debe recordar que está allí para servir a:

1. El Dueño de Producto
2. El Equipo de Desarrollo
3. La Organización

Para ello el SM debe tener en cuenta no solo el nivel de madurez en Scrum del equipo y de la organización, sino la capacidad de los miembros del equipo para obrar bajo el manto del espíritu Scrum. Esto quiere decir que el SM debe interactuar con cada persona en el equipo tanto como sea posible y promover la interacción entre ellos ya que, como recordarán, “valoramos individuos e interacciones sobre procesos y herramientas”.

En principio, no es buena idea que el SM haga cambios profundos en la Forma de Trabajo del equipo porque esto podría disminuir considerablemente su velocidad; en cambio, el SM debe considerar acompañar y guiar al equipo hacia el éxito constante. También debe lograr que haya confianza entre todos los miembros del equipo y que ellos tengan confianza en su SM, tal y como un paciente confía en su médico de cabecera.

Otras indicaciones que debe tener en cuenta el Scrum Master son:

• Soportar activamente el proceso de adopción, adaptación y mejoramiento de prácticas ágiles en la organización.
• Entender lo bueno y las mejoras que el equipo está buscando.
• Tratar de establecer una comunicación abierta con el Dueño del Producto.
• Interactuar con otros SM e identificar los desafíos que enfrentan.
• Constantemente inspeccionar, ser transparente y adaptar, es decir, promover los pilares de Scrum.
• Entrenar al equipo, entrenarlo y luego entrenarlo más. Cuando esté cansado de entrenar al equipo, entrenarlo en algo más. Ser el mentor que todos esperan que sea.
• Promover la comunicación abierta.
• Resaltar cuando el equipo alcance hitos de adaptación y mejoramiento.
• Preguntarle al Dueño del Producto por 2 o 3 cosas que él/ella piense que no están bien, dañadas o que no están funcionando o simplemente con las que no está feliz.
• Hacer lo anterior, pero con el Equipo de Desarrollo.
• Mostrar a todos como planea corregir estos aspectos con la mayor brevedad.
• Entender la cultura y el contexto del equipo.
• Identificar oportunidades de mejora y facilitar y fomentar el mejoramiento.
• Promover la retrospectiva al final del Sprint e, incluso, durante el Sprint.
• Finalmente, pero no menos importante, hacer que el equipo tenga acceso rápido a una buena máquina de bebidas de café, esto también resuelve muchos asuntos.

Contraindicaciones

Esta es la primera entrega de este Vademescrum, volveré con más. Mientras tanto es importante tener claro que un SM hace mucho más de lo que enumeré aquí. Una persona debe preguntarse, ¿cómo me llegó la idea de convertirme en Scrum Master? Y también, ¿dónde consigo la experiencia necesaria y suficiente para hacerlo bien? ¿Dónde y cómo puedo aprender más? Asimismo debe cuestionarse quién le enseña.

Es un hecho, en estos días parece que Scrum Masters con toda esa experiencia son concebidos en cursos de 2 días y un examen de selección múltiple. Al final, caen en el olvido sin que nadie en el equipo se haga cargo. Es toda una experiencia misteriosa que se puede dominar sin antes pasar por las etapas clásicas de aprendiz –> practicante –> practicante -> experto –> entrenador -> mentor y sin que se extienda el manto ágil de Scrum sobre el equipo y la organización.

Lecturas Adicionales

Scrum Fundamental lo encuentran en este mismo Gazafatonario, en:

http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html

La lista de verificación de Scrum la encuentran en:

http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html.

Mitos, Monstruos, Leyendas Urbanas y otros Desvaríos de Ágil y Scrum

http://www.gazafatonarioit.com/2013/06/mitos-monstruos-leyendas-urbanas-y.html

Scrum Orgánico para Iniciantes

http://www.gazafatonarioit.com/2013/05/scrum-organico-para-iniciantes.html

Scrum Orgánico para Iniciantes

Advertencia: al final de este artículo podrás empezar a usar Scrum en tus proyectos.

Marco de Trabajo Scrum

Presentación

Cuando publiqué la lista de chequeo de Scrum, asumí que mis lectores ya conocían este marco de trabajo (para software o productos y servicios de otro tipo) o que estarían familiarizados con el concepto de prácticas y técnicas ágiles y que conocían el suficientemente expuesto manifiesto ágil. Pensé que  no hacía falta abordar los aspectos más básicos del asunto. Me equivoqué. Acaso para algunos de nosotros esta sea la primera vez con Scrum, el primer contacto con un marco de trabajo ágil, la primera incursión en esta forma de construir productos de software. Así es que decidí volver a lo fundamental. Aquí vamos otra vez.

Scrum es un marco de trabajo liviano e iterativo de gestión de proyectos que ayuda a los equipos a ejecutar y a entregar exitosamente el valor de negocio más alto en el tiempo más corto posible. Este método es particularmente bien apropiado para entornos donde los requisitos están sujetos a cambios continuos o donde los requisitos no se entienden correctamente. “Scrum es un marco de trabajo con el cual podemos afrontar problemas complejos y adaptativos y con el cual podemos emplear distintos procesos y técnicas, así como también podemos optimizar nuestra predictibilidad y tener un mejor control de los riesgos”[i].

Métodos Ágiles

Pero Scrum no es el único método ágil que podemos encontrar. Algunos otros marcos de trabajo ágil son:

·         Adaptive Software Development (ASD)

·         Crystal Clear

·         Kanban
·         Extreme Programming (XP)
·         Dynamic System Development Method (DSDM)

·         Feature Driven Development (FDD)

·         Lean Software Development (LSD)

·         Open Unified Process (OpenUP)

·         Essential unified process (ESSUP)

·         Agile Unified Process (AUP)

·         Use Case 2.0

La Filosofía Ágil

Todos estos métodos tienen sus cimientos en lo que se conoce como Filosofía Ágil:

·         Usted no puede predecir o planear con absoluta certeza lo que va a entregar, cuándo lo entregará y cuánto será su costo.

·         Empiece con planes iniciales alrededor de las estimaciones, fechas y alcance, pero enfóquese en la revisión continua de estas restricciones a medida que avanza.

·         La meta es entregar el mejor software posible, dadas estas restricciones, pero ningún método con el enfoque de receta de cocina mejorará lo que es “mejor”.

Scrum

Scrum define explícitamente tres roles, cuatro ceremonias y cuatro artefactos principales. El Dueño del Producto, el Equipo de Desarrollo y el Scrum Master son quienes tienen bajo su responsabilidad entregar software probado y funcionando cada cuatro semanas o menos. Todos ellos forman el Equipo Scrum que, además de las actividades regulares de desarrollo de software, realiza cuatro ritos durante cada iteración que en Scrum se llama Sprint: Planificación del Sprint, Reunión Diaria, Revisión del Sprint y Retrospectiva. Durante estas ceremonias, el equipo actualiza la Lista (Backlog) del Producto, la Lista de Pendientes (Backlog) del Sprint y la Lista de Impedimentos; y al final entrega un incremento del producto potencialmente distribuible.

Actores en Scrum

El Dueño del Producto es la persona encargada de maximizar el valor del producto elaborado por el equipo de desarrollo. Es quien define y prioriza los ítems de la bitácora de producto y quien proporciona al equipo todo el conocimiento del negocio necesario para que este sea transformado en software. Entre tanto, el Equipo de Desarrollo es el responsable de construir el producto, teniendo en cuenta las necesidades y prioridades del dueño del producto. En Scrum no existen roles especializados, es simplemente el equipo, comprometido todo con el éxito del proyecto.

Finalmente, el Scrum Master es un servidor, es quien vela porque se ejecute el proceso como está definido y que se lleven a cabo cada una de las ceremonias Scrum como está consignado en la Guía de Scrum. También es el encargado de introducir nuevas prácticas al proceso y al proyecto, acompañando de cerca su implantación y monitoreando los resultados. Es importante aclarar que el Scrum Master no es un gerente, aunque bien podríamos decir que hace parte de y reporta al área de manejo de la organización, por ejemplo, a la oficina de proyectos. Contando el SM, el equipo Scrum no debe superar las 9 personas.

Ceremonias y Artefactos Scrum

En un proyecto gestionado bajo el manto de Scrum, todo ocurre en el marco de un Sprint: este es una iteración de un tiempo máximo de 4 semanas. La industria del software está gritando a cielo abierto que este tiempo sea de solo 2 semanas o de menor duración. Al principio del Sprint se realiza la Planificación del Sprint. En esta reunión, el dueño del producto asiste con la Lista del Producto actualizada y priorizada, de acuerdo con las necesidades del negocio. Junto con el equipo de trabajo, se seleccionan algunos de los elementos de la lista, usualmente los de mayor valor para el negocio, para ser desarrollados durante la iteración.

Con estos elementos seleccionados se conforma lo que se llama la Lista de Pendientes del Sprint, el trabajo del sprint. A continuación, el equipo de desarrollo define cómo hará el desarrollo y estima el esfuerzo necesario para cada uno de los elementos seleccionados, teniendo en cuenta que el esfuerzo máximo es el definido para el sprint, ni un minuto más. Con estas premisas, el Equipo en pleno elabora la Definición de Terminado y se asegura que todo el mundo la entienda y la comparta. Esta “definición de Terminado” se convierte en una especie de “contrato” del sprint, define las cláusulas sine qua non el incremento del producto no satisface a su dueño ni a la organización.

Con la definición de Terminado en la mente de los miembros del equipo Scrum, este inicia el ciclo de vida del software. Todos los días, a la misma hora y en el mismo lugar, de pie y durante 15 minutos máximo, el equipo se congrega en la Reunión Diaria. En esta sesión, cada integrante del equipo responde tres preguntas: ¿qué hice ayer? ¿Qué haré hoy? Y ¿Qué problemas tengo? Solo tres y nada más que tres. Esta reunión no es para saludarse ni para hablar de asuntos que no estén relacionados con el proyecto o con las personas que lo ejecutan. Tampoco es para resolver los problemas expuestos.

De la reunión diaria sale actualizada la Lista de Impedimentos, la cual es tratada fuera de la reunión, por cada uno de los responsables de solucionarlos. En Scrum, el equipo es autogestionado, multidisciplinario y debería tener la capacidad de resolver sus propios problemas sin la ayuda de alguien externo. Hacia el final de la iteración, se realiza la Revisión del Sprint. En esta sesión, el equipo Scrum y los interesados realizan un escrutinio de lo que se hizo en el sprint y ajustan la lista del producto si fuese necesario. En definitiva, el dueño del Producto verifica que se haya cumplido la Definición de Terminado.

Justo a continuación de la revisión, se hace una Retrospectiva del Sprint: ¿Qué hicimos mal que no repetiremos? ¿Por qué no se alcanzó la Definición de Terminado? ¿Qué hicimos bien que podemos mejorar? ¿Qué hicimos bien que seguiremos haciendo tal cual? Estas son algunas de las cuestiones que, con ayuda del Scrum Master, se responden en esta reunión. En esta sesión también deberíamos separar unos instantes para realizar una introspectiva: ¿Cómo está nuestro estado de ánimo? ¿Seguimos? ¿Paramos? Si seguimos, ¿qué acciones de mejoramiento podemos introducir a partir del siguiente Sprint?

Conclusión

Estos son, grosso modo, los elementos que subyacen el método Scrum. Todas las ceremonias tardan un tiempo fijo definido en el libro de reglas de Scrum o Guía de Scrum. No hay que saber nada más para comenzar a usar el marco de trabajo. Y para usarlo hay que ser ágil, porque Ágil es algo que eres, no algo que haces. Una vez que puedes diferenciar esto, entonces convertirse en ágil será algo fácil. Extrapolando, una organización no puede forzar la filosofía ágil en su cultura, sino que debe permitir que su cultura evolucione hacia un estado ágil. Ágil es un estado de la mente, es una forma de pensar y de ver las cosas.

Se me olvidaba decirles, la retrospectiva siempre debe hacerse al final de cada sprint, a menos que el equipo esté bien ocupado. En cuyo caso, se deberían hacer dos.

Lecturas Adicionales

Mi artículo de Scrum Fundamental lo encuentran en este mismo Gazafatonario, en: http://www.gazafatonarioit.com/2013/05/scrum-lo-fundamental.html.

El libro de reglas de Scrum, la guía de Scrum, lo encuentran en:

http://www.scrum.org/Portals/0/Documents/Scrum%20Guides/Scrum_Guide%202011%20-%20ES.pdf#zoom=100.

La lista de verificación de Scrum que desató esta serie de artículos  la encuentran en: http://www.gazafatonarioit.com/2013/05/lista-de-chequeo-scrum.html.

Otros sitios que pueden visitar para aprender más de Scrum y libros que pueden leer son:

http://www.scrum.org/scrumguides

http://www.scrumalliance.org

http://www.mountaingoatsoftware.com/

http://scrum.jeffsutherland.com/

http://www.controlchaos.com/

http://americalatina.pmi.org/latam/CertificationsAndCredentials/PMI-ACP/PMI-ACPExamPreparation/MaterialsAndResourcesInAgile.aspx

Essential Scrum: A Practical Guide to the Most Popular Agile Process. Mike Cohn.

Succeeding with Agile: Software Development Using Scrum. Mike Cohn.

Agile Project Management with Scrum (Microsoft Professional). Ken Schwaber.

Agile Product Management with Scrum: Creating Products that Customers Love. Roman Pichler.

Professional Scrum Development with Microsoft® Visual Studio® 2012. Richard Hundhausen.

User Stories Applied: For Agile Software Development. Mike Cohn.

---

[i] La Guía de Scrum. © 1991-2011 Ken Schwaber y Jeff Sutherland, Todos los Derechos Reservados.