Esta es una muy válida pregunta.

La validez de esta pregunta radica en el énfasis de la palabra "valor". Precisamente cualquier interés que se tenga en Scrum debe estar basado en el valor que Scrum por sí mismo provea, así que primero me dirigiré tratar valor que provee Scrum como marco de trabajo para el desarrollo de software, luego abarcaré el valor de asistir a un Taller de Certificación de Scrum.

Padecimientos en el mundo del software

El desarrollo software tradicional alrededor del mundo tiene dos enfermedades:

1. Interrupción del flujo del “valor”. Me refiero al flujo que empieza desde que el cliente define el valor que quiere obtener y que termina cuando obtiene el producto que debiera reflejar ese “valor”.  Me refiero a la incapacidad de sintetizar las necesidades del cliente (customer value) y transmitirlas fielmente a equipo de desarrollo para ser implementadas. Esto se traduce en, en el mejor de los casos, completar un producto que cumple con el documento de requerimientos, pero no con las expectativas del cliente.
2. Desperdicio. Le reto a que dedique un momento para calcular cuánto tiempo (mejor aún, tradúzcalo a dólares) que es desperdiciado en:
   • Reuniones irrelevantes para la mayoría de los asistentes.
   • No llegar a tiempo a reuniones que sí son relevantes para todos los asistentes.
   • Yendo y viniendo entre el Departamento de Desarrollo y el Departamento de QA.
   • Discutir e implementar cosas que no son prioritarias.
   • Planear con detalle microscópico tareas que al final no terminan haciéndose tal y como se planearon.
   • Tener un equipo que tiene el rendimiento de un grupo disjunto individuos.
   • Encontrar problema muy tarde en el progreso del proyecto, tan tarde que corregirlo es muy costoso.
   • Etc… puedo seguir enumerando muchas más, pero no quiero aburrir.

Dándole valor al valor

La columna vertebral de Scrum es el Product Backlog. Este artefacto es una lista de requerimientos priorizada por “valor” desde el punto vista del cliente. El formato que tiene y el tratamiento que recibe durante todo el proceso de desarrollo de Software Scrum hace que constantemente esté validado contra las expectativas del cliente.

Scrum es iterativo basado en retroalimentación. Esto permite manejar de forma realista y exitosa la naturaleza incierta inherente a todo proyecto de software. Esa incertidumbre que es tan bien manejada por Scrum viene de dos frentes:

1. Desde el negocio. La mayoría de las veces, el cliente solo tiene una idea de lo que quiere. Lo único que tiene claro es que le duele algo y quiere algo que alivie ese dolor. Aún en el rarísimo caso que el cliente ya tenga una lista de requerimientos priorizada, la realidad es que conforme pase el tiempo se enterará de nuevas restricciones de mercado, o mejor aún se le ocurrirán mejores ideas. Y si tiene oportunidad de ver creciendo el producto implementado, va a querer cambiarlo para mejorarlo. Observe que asocio “cambio” con “mejoría”, por lo que adoptar una política de castigar el “cambio” no ayuda a entregar lo que el cliente realmente quiere.
2. Desde la plataforma tecnológica. Un producto de software es la suma de miles de decisiones de naturaleza tecnológica que son imposibles de conocer de antemano. Esto es cierto aún si el mismo equipo ha desarrollado proyectos anteriores usando la misma plataforma tecnológica.

Scrum logra el manejo de estas incertidumbres mediante el mantenimiento constante del Product Backlog, el manejo de Sprints cortos y la dedicación exclusiva de un Product Owner como ente enteramente responsable de mantener el Product Backlog, y por lo tanto, de entregar lo que el cliente quiere. La herramienta más poderosa que tiene el Product Owner para lograr este cometido son los Sprint Reviews.

En resumidas palabras, Scrum dedica su existencia a que el concepto de valor sea fidedignamente transmitido al equipo de desarrollo.

Desperdicio es el enemigo

El ScrumMaster es quien lidera la lucha contra el desperdicio. En su rol de facilitador del equipo y líder servil, es también un vigilante constante del timeboxing de las reuniones y en contra de divagaciones durante las mismas.  Constantemente revisa que haya fluidez de tareas en el Taskboard y asegurándose que el equipo trabaja según la prioridad establecida para los User Stories del Sprint.

No hay que olvidar el claro rol del ScrumMaster: Desaparecer impedimentos, recordar constantemente la visión, dar constate visibilidad al estado del proyecto.

En Scrum se busca detalle microscópico en el Sprint en el que se va a trabajar,  pero visión panorámica para el resto del Backlog, evitándose el sobre-planeamiento común en la administración tradicional de proyectos.

En lugar de tener un grupo de personas trabajando en un proyecto, Scrum promueve pasar de grupo a un equipo. Reflexione sobre diferencia: tendrá un equipo cuando el rendimiento combinado de las personas sea mucho mayor que la suma por separado del rendimiento de cada persona. La forma en que se facilita desde el Planning Meeting hasta el Daily StandUp ayudan sincronizar al equipo, a empoderarlo para ser auto organizado en lugar que micro-manejado.

Pero todo eso lo puedo leer en blogs y libros

De eso no hay la menor duda. ¿Cuán complejo es el fundamento teórico del fútbol, es más, del ajedrez? Nada complejo, tienen reglas sencillas. Aún así, no es lo mismo ver a unos niños de escuela jugando futbol que un partido de futbol mundialista, aunque en el fondo están usando el mismo conjunto de reglas para jugar. Por más que sepa todas las reglas de ajedrez, le es fácil reconocer que requiere de las enseñanzas alguien con mayor destreza para  desarrollar pensamiento analítico y estratégico.

¿Cuáles son los retos a los que se enfrentará al implementar Scrum en su empresa? ¿Cuáles son los principios detrás de Scrum que son los que al final vale la pena siempre recordar cuando se deba tomar una decisión? Una vez teniendo una panorama completo de Scrum, en cuáles aspectos debe profundizar, dadas sus circunstancias? ¿Cuáles advertencias (basadas en mucha experiencia en equipos de Scrum) sobre adopción de Scrum me pueden ser útiles?

Scrum delinea conceptos que al oírlos explicados suenan con tan sentido común. Sin embargo recuerde que el sentido común deja de ser “común” cuando se está inmerso en el diario manejo de problemas y vacas sagradas de los ambientes de trabajo. Además, no es lo mismo reconocer un concepto a interiorizarlo.

Finalmente, aquí dejo un brevísimo video que recoge las impresiones de dos profesionales cuando les pregunté sobre cuál era el valor de haber asistido al Taller de Certificación de Scrum impartido por Michael Vizdos en Costa Rica: