El imposible y desatinado caso de SCRUMStudy®

Imagen de Sophie Janotta en Pixabay

Una colega lanzó esta pregunta en una comunidad de Scrum Masters:

Que tal grupo, […],

Duda: (corríjanme si estoy mal, por favor)

Entre las diferentes compañías tales como SCRUMstudy^®, Scrum Alliance, Scrum.org, etc.

En cuestión a la teoría que imparten todas las diferentes compañías/empresas ¿existe alguna diferencia entre el contenido que imparten para enseñar a sus receptores Scrum? o ¿Todas las compañías en cuestión a teoría enseñan lo mismo pero te certifican según la compañía en la que tomaste la capacitación o curso?

[…]

Saludos.

[Texto copiado con permiso de su autora]

Recordé que hace ya algún tiempo estuve involucrado en otro foro sobre la muchas veces discutida pregunta “¿dónde me certifico?”. Mis ideas de entonces quedaron registradas en:

https://www.linkedin.com/pulse/donde-me-certifico-como-scrum-master-luis-antonio-salazar-caraballo/

Pero esta nueva pregunta iba más allá. Hablaba de la teoría. Y lo que más me llamó la atención fueron las respuestas iniciales de otros foristas quienes, de alguna manera, no diferenciaban en el tratamiento de Scrum que hace el así llamado SBOK^® y la guía oficial de Scrum, escrita por sus creadores.

Como es un tema escabroso, de esos que elevan las pasiones, lo pensé mucho antes de involucrarme. Finalmente, pudo más la responsabilidad que tengo con el “hacer bien las cosas”, el compromiso que tengo con el mejoramiento del uso de Scrum por parte de las personas, equipos y organizaciones a mi alrededor. Así que esta fue mi respuesta:

Imagen de David Mark en Pixabay

A ver si trato de explicar esto con una analogía:

Aunque la FIFA no inventó el Fútbol, es hoy el organismo que “rige” los estándares, que regula, que establece las “reglas” de ese deporte. A pesar de ello, es posible jugar al fútbol con variantes y no “pasa nada”: fútbol playa, fútbol 5, fútbol 7, fútbol sin porterías, etcétera. Cada una de estas otras versiones tiene distintas reglas, creadas o inventadas por nosotros mismos, las personas, o por algún organismo distinto a la FIFA. Hay menos jugadores en algunos, hay variaciones en las reglas, en fin. Pero en definitiva, el Fútbol como tal, el deporte del balón, el universal, es el de la FIFA.

Así ocurre con Scrum. Este marco de trabajo fue creado por Jeff Sutherland y Ken Schwaber y fueron ellos quienes escribieron originalmente lo que hoy se conoce como la guía de Scrum. El primer documento lo presentaron al mundo en 1995. Puedes encontrar más de los orígenes de Scrum en:

https://www.scruminc.com/origins-of-scrum/

Ahora bien, son Jeff Sutherland y Ken Schwaber quienes siguen actualizando y manteniendo la guía (la teoría) de Scrum de tanto en tanto. Ellos reciben la retroalimentación de la comunidad pero finalmente ellos son sus creadores y, por decirlo de alguna manera, sus guardianes. Aunque bien todos nosotros deberíamos ser custodios de esa guía oficial también.

Después de Scrum llegaron organizaciones como la Scrum Alliance, creada precisamente para fomentar el uso del framework. Ellos crearon algunas certificaciones asociadas: Scrum Master, Product Owner y Scrum Developer. Y basaron sus cursos y certificaciones en la guía de Scrum escrita por Sutherland y Schwaber.

Más tarde aparecieron empresas como Scrum.org de Ken Schwaber y Scrum Inc., de Jeff Sutherland.

Y luego otras empresas certificadoras. Incluyendo SCRUMStudy^®. Casi todas estas últimas empresas certificadoras de Scrum son independientes, de terceros, pero basan sus certificaciones en la guía de Scrum escrita por Sutherland y Schwaber, la guía oficial.

Casi todas, excepto SCRUMStudy^®, que basa sus entrenamientos (teoría) y exámenes de certificación en un libro que ellos llaman Scrum Body of Knowledge (SBOK^®). Un libro de más de 400 páginas la última vez que lo consulté. Mientras que la guía oficial solo tiene unas 18 páginas en español.

Imagen de LhcCoutinho en Pixabay

Este SBOK^® es como esas otras versiones de Fútbol de las que te hablé al comienzo. Tiene otras reglas, muy diferentes a las que tiene la guía de Sutherland y Schwaber, los creadores de Scrum.  Imagina las diferencias nada más en número de páginas. De 18 a más de 400. Pero quisiera poner tres ejemplos de las disparidades que presenta la una versus la otra:

1. Roles propuestos: en Scrum “oficial” (en la guía de Sutherland y Schwaber, la de 18 páginas), los tres roles propuestos son: Dueño de Producto, Scrum Master y Equipo de Desarrollo. Solo tres y nada más que tres. Estos tres roles forman lo que conocemos como Equipo Scrum. Mientras tanto en el SBOK^® se proponen 2 tipos de roles: Roles Core y Roles Non-core. A los primeros pertenecen los tres roles de la guía oficial aunque con una discrepancia: el equipo de desarrollo se llama Equipo Scrum. En la guía oficial, como dije antes, este Equipo está compuesto por los tres roles. Aquí no. Y los roles non-core son Stakeholders (dentro de los cuales cuentas Customer, Usuarios y Patrocinador), Vendedores y Cuerpo de asesoramiento de Scrum. En definitiva, son reglas distintas.
2. En la guía oficial de Scrum, el tamaño del equipo de desarrollo va de 3 a 9 personas. En la sección 3.6.2 (Tamaño del Equipo Scrum), el SBOK^® dice que “El tamaño óptimo de un Equipo Scrum es de seis a diez miembros”. Otra vez, una regla disímil.
3. En la guía oficial de Scrum, la duración máxima del Sprint es de un mes. Mientras que en la sección 2.7.1 (Scrum Time-boxes), el SBOK^® dice que “Un Sprint es una iteración Time-boxed de una a seis semanas de duración”. Otra disparidad.

Y así podemos encontrar muchas. De 18 a más de 400 páginas. Simplemente son reglas desiguales, algunas muy opuestas. El SBOK^® No es Scrum.

Con esto solo estoy tratando de señalar que la guía de Scrum, la cual puedes descargar de inmediato desde https://www.scrumguides.org/download.html o directamente la edición en español desde: https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf, es la guía oficial que te presenta la teoría y las reglas de Scrum. Es la única fuente fiel, escrita y mantenida por sus creadores.

¿Quién sabe? Seguramente, si vas a jugar Fútbol y tomas el balón con la mano o si en tu equipo hay trece jugadores en la cancha recibirás una infracción y quizás hasta no puedas jugar.

Espero que sea de utilidad.

Saludos,

Las primeras reacciones a mis ideas en el foro fueron bastante positivas. De hecho, mucho más de lo que merezco. Pero eso me motivó a trasladar la explicación hasta mi Gazafatonario, para que más personas tuvieran acceso a ella. Por favor, déjame saber qué piensas al respecto.

La lista de chequeo de Scrum Roosmalen

Clic para ampliar la imagen

Ralph van Roosmalen implementó hace ya algunos años esta herramienta en Microsoft Excel, basado en la ya archifamosa Lista de Chequeo de Henrik Kniberg, de la cual tuve la oportunidad de publicar la versión en español hace ya varios años. La pueden encontrar y descargar en:

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

Si ya la tienes, vuelve a releer el espíritu que inspiró esta lista de chequeo. No intentes encontrar todas las respuestas allí, es un buen comienzo. La he usado ampliamente de diversas formas en los últimos años y me ha funcionado bastante bien. En retrospectivas y revisiones de distintas implementaciones de Scrum y de prácticas ágiles. Como fuente de aprendizaje para futuros Scrum Master, Dueños de Producto y miembros de equipos Scrum en general. Como parte del crecimiento de las empresas hacia un pensamiento lean-ágil que soporte su cultura organizacional. En fin, las posibilidades son infinitas.

En esta ocasión contacté a Ralph y me autorizó a publicar la traducción al español de su herramienta. Muy útil para presentar información incluso a la alta gerencia, como guía del estado de una implementación Scrum típica. Está enriquecida con gráficos de los aspectos más relevantes del marco de trabajo que finalmente sirven como datos para tomar decisiones acerca de los pasos siguientes durante el cambio en la forma de hacer las cosas.

Clic para ampliar la imagen

Como siempre, el llamado es a experimentar, a cambiar la herramienta una vez que la dominemos, a sacarle el mejor provecho posible. Aquí se las presento. Al final, encuentran el enlace para descargarla. Veamos que dice Ralph en la página de Documentación.

¿Qué es esto? ¿Para quién es?

La lista de chequeo Scrum es una herramienta simple para ayudarte a empezar con Scrum o para evaluar tu actual implementación de Scrum. Está basada en la Lista de Chequeo de Scrum de Henrik Kniberg[1]. Le he adicionado una sección: Scrum Distribuido.

Nota que estas no nos reglas. Son guías. Un equipo de dos podría decidir saltar el Scrum diario, puesto que ellos están haciendo programación par todo el día y podrían no necesitar una reunión para sincronizarse. Bien. Luego, intencionalmente ellos se han saltado una práctica Scrum pero se aseguraron de que el propósito de la práctica Scrum ha sido cumplido de otra forma. ¡Esto es lo que cuenta!

Si estás haciendo Scrum, podría ser interesante hacer que tu equipo tenga esta lista en la retrospectiva. Como una herramienta de discusión, no como una herramienta de evaluación.

¿Es esta una lista de chequeo oficial?  No. La lista de chequeo refleja principalmente la opinión personal y subjetiva de Henrik acerca de lo que realmente importa en Scrum. Él ha pasado años ayudando a compañías a empezar con Scrum y ha conocido a cientos de otros practicantes, instructores y entrenadores; y ha encontrado que listas de chequeo como esta pueden ser útiles si se usan correctamente.

Clic para ampliar la imagen

Para usar la lista de chequeo correctamente, si es posible diligénciala con tu equipo o con otros Scrum Masters. Otra opción es llenar la lista individualmente y luego comparar el resultado con los miembros de tu equipo. Verás las diferencias y allí es donde se pone interesante. Empieza a hablar sobre las diferencias, ¿por qué aparecieron? Así, ¡esta lista de chequeo será el comienzo de una discusión! Como se describió en el segundo párrafo, no puedes juzgar una implementación de Scrum basado solo en esta lista de chequeo. Si acaso sea posible juzgar una implementación de Scrum    ;)

Para usar el instrumento, ve a la hoja Entrada de Datos y marca tu  "calificación". Cuando todo esté diligenciado correctamente, todas las cruces rojas serán verdes. Tan simple como eso, como en Scrum. Scrum es mortalmente simple... Sin embargo, implementarlo puede ser muy desafiante ;)

Clic para ampliar la imagen

¿Pensaste que encontraste un error porque la columna "Tu número de madurez de Scrum" siempre es 42 [2]? Correcto y esto no es un error. No puedes capturar una implementación de Scrum en un número, eso es imposible. El hecho de hacer algunos cálculos y mostrar gráficos ya es cuestionable.

¿Por qué no usamos degradados rojos y verdes en las barras de colores? Porque el rojo está relacionado con lo negativo y el verde con lo positivo y no podemos decir que algo es negativo o positivo en tu organización. Así que lo mantenemos neutral, solo azul.

Clic para ampliar la imagen

Si tienes preguntas o comentarios, contáctame en ralph@agilestrides.com.

Referencias

[1] https://www.crisp.se/gratis-material-och-guider/scrum-checklist

[2] https://es.wikipedia.org/wiki/El_sentido_de_la_vida,_el_universo_y_todo_lo_dem%C3%A1s

Puedes descargar la herramienta de Ralph aquí:

No dejes de contactarme o de contarme en el foro sobre el uso que le están dando a esta herramienta que seguramente te será de mucha utilidad.

Traducción de Lucho Salazar. lucho.salazar@gmail.com. http://www.gazafatonarioit.com.

Scrumdamentalismo: o de la dogmática ágil

Tengo que confesar que no voy a satanizar a Scrum ni mucho menos a quienes lo practicamos, ¡yo soy uno de ellos! Lo practico no solo en las organizaciones que acompaño, con ímpetu, con altivez cuando es necesario, lo enseño, acompaño a otros a enseñarlo, a practicarlo y he aprendido mucho en el camino. Lo practico con la suficiente apertura como para saber que nunca es suficiente y que debo seguir inspeccionando la realidad para hacer adaptaciones razonables y lograr un cambio sostenible. También lo práctico en mi vida personal, con la pasión y el coraje que se necesita para recargarme cada día y sentir el poder de enfocarme en lo que me emociona y me hace feliz al lado de mi familia.

No, no me malentiendas. Con Scrum en particular y con el pensamiento ágil en general he aprendido que el liderazgo no se trata de una credencial o una designación. Se trata de impacto, influencia e inspiración. Y también he experimentado que a donde sea que vayas, tienes que ir para ser el mejor sin tener que serlo, que no hay fórmulas con la solución para cualquier cosa que ocurra, y que se trata de entusiasmo, honor y trabajo duro. Pero ojo, no nos equivoquemos, es muy fácil confundir pasión, esa determinación con la que hacemos las cosas, sobre todo para promover el cambio, con este scrumdamentalismo que casi siempre, por no ser totalitario, es un sinsentido.

Lo que ocurre es que muchas personas, agilistas o no, siguen buscando la respuesta a todo en las prácticas ágiles, aun en los valores y principios ágiles; lo hacen de manera literal, cuando muchas veces la pregunta correcta es “¿qué te dice el sentido común?”. He trabajado en procesos de mejoramiento (de software) durante las últimas dos décadas y desde siempre he usado este lema: cuando se trata de procesos, marcos de trabajo o prácticas, no subestimes tu poder de pensar. ¡Funciona para mí!

La causa de este fenómeno es que entendimos mal Scrum, sus valores principales o la teoría que lo soporta y tratamos al marco de trabajo como una religión o un dogma, donde todas las respuestas a cada uno de los problemas y escenarios que enfrentamos diariamente vienen de Scrum (esto es precisamente scrumdamentalismo en toda la extensión del término). O bien, hemos entendido Scrum y, sin embargo, le seguimos dando tratamiento de doctrina porque nos gusta su estructura, ese conjunto riguroso y limitado de parámetros que nos hace fácil y llevadera la vida en este universo VUCA que muchas veces nos da temor enfrentar. Es el anhelado “paso a paso seguro” que nos lleva del punto A al punto B sin miedo a equivocarnos.

Es fácil convertirse en scrumdamentalista. Parece un estado inevitable por el que todos hemos pasado. De eso se trata el Shu de Shu-Ha-Ri en donde, si eres Scrum Master sigues con precisión la guía de Scrum, te concentras en cómo hacer las ceremonias con el equipo, que se tengan los artefactos y que cada miembro del equipo se desempeñe como lo plantea la guía o como te dijo el instructor en el curso que tomaste, sin preocuparte demasiado por la teoría subyacente, como por ejemplo: cómo planificar en un entorno empírico.

Lo que convierte a este síntoma en un estigma es querer quedarse allí para siempre. Algunas manifestaciones de los scrumdamentalistas incluyen:

1.     En la Reunión Diaria siempre se responden “las tres preguntas”.

2.     El sprint debe tardar 2 semanas, siempre.

3.     La planificación de un sprint de dos semanas debe tardar máximo cuatro horas.

4.     Solo podemos usar historias de usuario para representar lo que el usuario quiere.

5.     El Scrum Master es el único que puede conducir la retrospectiva.

6.     El Dueño de Producto es el único responsable de definir el incremento de producto para el sprint.

7.     Pensar que cualquier “otro” scrumdamentalista tiene que o debe cambiar, sobre todo después de leer este artículo.

8.     Las herramientas son las armas del demonio de la agilidad.

9.     La documentación tiene que reducirse, ojalá hasta llegar a nada, a cualquier costo.

10.  Tenemos que evitar, incluso alejarnos de, cualquier persona cuyo pensamiento no esté cubierto por el mantra ágil.

Los scrumdamentalistas ven a las organizaciones, comunidades ágiles y consultoras como alquimistas que se presentan ante ellos con sonrisas congruentes y manos extendidas para ofrecer soluciones, transformación cultural, reducción de desperdicios y aumento de felicidad, compitiendo como si se tratara de un mercado persa. Pero solo es porque tienen el recuerdo aciago de un pasado en el que otras organizaciones, comunidades y consultoras se comportaron de manera bárbara cuando eran fuertes y hacían ofertas que no podían rechazar.

Hoy tenemos que partir del precepto de que todos queremos, en efecto, soluciones, cambiar la cultura organizacional, reducir desperdicios, mejorar continuamente y ser más felices. Y que lo hacemos partiendo de la base de que tenemos buenas intenciones, con la información, las habilidades y los recursos que tenemos disponibles. Y reconociendo que la trayectoria pasada no es garantía del desempeño actual y mucho menos del futuro, porque los escenarios cambian.

El mismo Scrum nos muestra la solución a esta disfunción dogmática con sus valores: el empirismo en el que se basa la teoría de Scrum requiere de transparencia, de franqueza (léase apertura). Esto nos enseña a tener la disposición suficiente y necesaria para aceptar las ideas y propuestas de las personas en el equipo y en la organización, aun en procesos complejos de transformación cultural. Precisamos de una apertura tal que nos permita desaprender y aprender en todo momento; y también necesitamos un entorno donde experimentar, fallar y volver a intentarlo.

También debemos tener el coraje para admitir que no somos perfectos y que siempre podemos mejorar y cambiar el rumbo de nuestro pensamiento; coraje para dejar de lado las convicciones del pasado. En resumen, la guía de Scrum, breve y liviana como la han mantenido sus autores, es un compendio pletórico de riquezas, una serie efectiva de propuestas para ayudarnos a hacer las cosas bajo el manto de la mentalidad ágil, pero sin que hagamos a un lado nuestra habilidad, humana y humanizante, de sentir y de pensar.

Incluso yo puedo parecer un scrumdamentalista al escribir este artículo, ¿quién sabe? Quizás sea el más scrumdamentalista de todos, pero estoy trabajando en ello. Solo dame tiempo y ayúdame a sanar.

Lucho Salazar. Lima, 20 de enero de 2019.

Revisión a la Guía de Nexus 2018

Ken Schwaber y Scrum.org anunciaron hoy (enero 17 de 2018) que fue publicada una actualización a Nexus, el marco de trabajo para escalar Scrum. Acorde con los recientes cambios a su marco de trabajo subyacente, los cambios a Nexus aumentan la claridad, enfatizan la criticidad de “Terminado” a Escala y extienden el alcance mundial de Nexus, se anunció hoy en un comunicado oficial.

Las actualizaciones fueron determinadas en parte a través de los comentarios de la comunidad de Scrum a través del sitio web Scrum Guide User Voice, la comunidad de Scrum.org y sus entrenadores profesionales de Scrum (PST). Un énfasis en aumentar las aclaraciones sobre el Equipo de Integración de Nexus y el propósito de su rol, afirmando la importancia de la transparencia a escala para la integración y definiendo qué significa "Terminado" a Escala, son algunos de los principales cambios que los practicantes de Scrum encontrarán en la versión actualizada de la Guía Nexus.

Estos son los cambios más significativos:

1.    Actualizada la descripción de la Guía Nexus de “El exoesqueleto de desarrollo a escala con Scrum” a “La guía definitiva para escalar Scrum con Nexus: las Reglas del Juego”.

2.    Nexus se define ahora como “una relación o conexión entre personas o cosas”.

3.    En el Flujo del Proceso Nexus, la terminología se cambió para hacer foco en los equipos en vez de en los miembros individuales, “Un Nexus consiste de múltiples equipos Scrum multifuncionales que trabajan en conjunto para entregar al menos un Incremento Integrado potencialmente distribuible en cada Sprint”.  También se agregó que basados en las dependencias, los equipos se autoorganizan y seleccionan los miembros más apropiados para hacer un trabajo específico.

4.    Claridad alrededor del rol del Equipo de Integración Nexus:

a.    El Equipo de Integración Nexus está conformado a menudo de miembros de los Equipos Scrum individuales del Nexus. Esta composición soporta la necesidad de inteligencia hacia arriba de los Equipos Scrum individuales en el Nexus.

b.    El Equipo de Integración Nexus no es el encargado de hacer la integración. Los Equipos Scrum individuales realizan el trabajo de integración.

c.    Se eliminó la definición de que el Equipo de Integración Nexus es un Equipo Scrum puesto que esto ha causado confusión, permitiendo creer que sus miembros son un Equipo Scrum separado permanentemente de los demás en el Nexus.

5.    El Refinamiento se movió en los Eventos Nexus hasta la parte superior. Ahora aparece antes que la Planificación del Sprint Nexus.

a.    El Refinamiento ya no está prescrito como un evento de dos partes. La terminología se enfoca en la transparencia en vez de en la visualización.

b.    Se eliminó la referencia al Refinamiento como “reuniones”, en vez de eso solo “Refinamiento”.

c.    Se enfatiza en el Refinamiento como una actividad continua a lo largo del Sprint mientras sea necesario y apropiado.

6.    La Meta Nexus ya no se especifica como una entrada o salida de la Planificación del Sprint Nexus puesto que esto puede variar, en cambio se define como una meta que el Dueño de Producto discute durante la Planificación del Sprint Nexus. Se eliminó terminología sobre la necesidad de estar en el mismo espacio físico.

a.    La Meta Nexus es ahora la Meta del Sprint Nexus y ya no se encuentra en la lista de nuevos artefactos, para ser consistente con el Marco de Trabajo Scrum.

b.    Se eliminó de la Tabla de Contenido.

7.    El Scrum Diario Nexus es una oportunidad para que los equipos busquen impactos entre equipos así como dependencias entre ellos.

a.    El Scrum Diario Nexus no es la única vez que la Lista de Pendientes del Sprint Nexus debería ajustarse. Es al menos uno de los momentos en los cuales los equipos se juntan para ajustar la Lista de Pendientes del Sprint Nexus para reflejar su entendimiento del trabajo y las dependencias entre equipos.

b.    El Scrum Diario Nexus es el momento en el que los Equipos de Desarrollo en el Nexus inspeccionan el progreso hacia la Meta del Sprint Nexus.

8.    La Revisión del Sprint Nexus no es para mostrar algo a la audiencia y contarle sobre eso, como no lo es en Scrum – se agregó terminología que la clarifica como una oportunidad de adaptar La Lista de Elementos del Producto si es necesario. También se menciona la necesidad de retroalimentación en la descripción de la Revisión del Sprint Nexus en el “Flujo del Proceso Nexus” en la página 5.

9.    Se agregó que la Retrospectiva del Sprint Nexus es una oportunidad formal para que el Nexus se inspeccione y adapte y cree un plan de mejoramiento que se ejecute a partir del próximo Sprint.

a.    Similar a la actualización de la Guía de Scrum, la Retrospectiva del Sprint Nexus existe para asegurar el mejoramiento continuo para el Nexus.

10. El Incremento Integrado representa el estado actual del trabajo integrado.

11. La Definición de “Terminado” especifica que el Incremento Integrado debe estar integrado.

12. En “Transparencia de los Artefactos” se eliminó la definición “la prueba de deuda técnica inaceptable es cuando la integración ocurre y sigue sin estar claro que todas las dependencias están resueltas”. Se reemplazó con “El software debe ser desarrollado de tal forma que las dependencias sean detectadas y resueltas antes de que la deuda técnica sea inaceptable para el Nexus”.

13. Se eliminó el párrafo sobre las prácticas de software. Aunque importante y relevante, el tema requiere de mayor elaboración para que agregue valor.

14. Se adicionó la cláusula de Creative Commons, lo que permitirá a los equipos y organizaciones, a nivel mundial, reutilizar el contenido de la guía y ampliar su alcance.

Como siempre, con mis grandes amigos Jorge Abad (@jorge_abad) y LeonardoAgudelo (@sweepnoise), hicimos la traducción de los cambios y mejoramos también algunos aspectos de la terminología en español.

La guía actualizada puede descargarse ya en español (2018) desde el sitio Web:  https://www.scrum.org/resources/nexus-guide.

Para conocer más de Nexus, pueden leer mi artículo:

http://www.gazafatonarioit.com/2016/01/nexus-el-exoesqueleto-de-desarrollo.html

En el que también podrán ver y descargar una presentación al respecto.

¿Cómo les ha ido con el uso de Nexus? ¿Tienes alguna pregunta adicional al respecto? Por favor, déjanoslo saber en el foro.

Revisión a la Guía de Scrum 2017

Cambios entre las Guías Scrum de 2016 y 2017

1. Adicionada sección sobre los Usos de Scrum:

Scrum fue desarrollado inicialmente para gestionar y desarrollar productos. Desde principios de los años 90 Scrum se ha usado ampliamente en todo el mundo para:

1. Investigar e identificar mercados viables, tecnologías y capacidades de productos;
2. Desarrollar productos y mejoras;
3. Liberar productos y mejoras tantas veces como sea posible durante el día;
4. Desarrollar y mantener ambientes en la Nube (en línea, seguros, bajo demanda) y otros entornos operacionales para el uso de productos; y
5. Mantener y renovar productos.

Scrum se ha usado para desarrollar software, hardware, software embebido, redes de funciones interactivas, vehículos autónomos, escuelas, gobiernos, mercadeo, también para gestionar la operación de organizaciones y casi todo lo que usamos en nuestra vida diaria, como individuo y como sociedad.

Dado que la complejidad de la tecnología, el mercado y del entorno y sus interacciones aumentan rápidamente, la utilidad de Scrum para tratar con la complejidad está a prueba diariamente.

Scrum demostró ser especialmente efectivo en la transferencia iterativa e incremental de conocimiento. Scrum se usa ahora ampliamente para productos, servicios y gestión de la organización matriz.

La esencia de Scrum es un pequeño equipo de personas. El equipo individual es altamente flexible y adaptativo. Estas fortalezas continúan operando en un equipo, en varios, en muchos y en redes de equipos que desarrollan, liberan, operan y mantienen el trabajo y los productos de trabajo de miles de personas. Ellos colaboran e interoperan a través de arquitecturas de desarrollo sofisticadas y ambientes finales de liberación.

Cuando las palabras “desarrollar” y “desarrollo” se usan en la Guía de Scrum, se refieren a trabajo complejo, tales como estos identificados anteriormente.

2. Modificada la redacción en la sección El Scrum Master para proporcionar una mayor claridad al rol. El texto ahora dice:

El Scrum Master es responsable de promover y apoyar Scrum como se define en la Guía de Scrum. Los Scrum Masters hacen esto ayudando a todos a entender la teoría, prácticas, reglas y valores de Scrum.

El Scrum Master es un líder que está 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 útiles y cuáles no. El Scrum Master ayuda a todos a modificar estas interacciones para maximizar el valor creado por el Equipo Scrum.

3. Adicionado a la sección El Scrum Master al Servicio del Dueño de Producto

Asegurar que los objetivos, el alcance y el dominio del producto sean entendidos por todos en el equipo Scrum de la mejor manera posible

4. Actualizado el primer párrafo de la sección Scrum Diario para que se lea:

El Scrum Diario es una reunión con un bloque de tiempo de 15 minutos para el Equipo de Desarrollo. El Scrum Diario se lleva a cabo cada día del sprint. En él, el Equipo de Desarrollo planea el trabajo para las siguientes 24 horas. Esto optimiza la colaboración y el desempeño del equipo inspeccionando el trabajo avanzado desde el último Scrum Diario y haciendo una proyección del trabajo del Sprint a realizar a continuación. El Scrum Diario se realiza a la misma hora y en el mismo lugar todos los días para reducir la complejidad.

5. Actualizada la sección Scrum Diario para proporcionar claridad sobre los objetivos del Scrum Diario incluyendo este texto:

El Equipo de Desarrollo es el encargado de establecer la estructura de la reunión y esta se puede conducir de diferentes maneras si se enfoca en el progreso hacia la Meta de Sprint. Algunos Equipos de Desarrollo usarán preguntas, algunos se basarán más en discusiones. Aquí hay un ejemplo de lo que podría usarse:

• ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint?
• ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint?
• ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint?

6. Adicionada claridad sobre los bloques de tiempo (time-boxes)

Usando las palabras “a lo sumo” para eliminar cualquier pregunta relacionada con que los Eventos tengan que ser de cierta duración y, en cambio, esos son los tiempos máximos asignados.

7. Adicionado a la sección Lista de Pendientes del Sprint (Sprint Backlog):

Para asegurar el mejoramiento continuo, la Lista de Pendientes del Sprint incluye al menos una mejora de procesos de alta prioridad identificada en la Retrospectiva inmediatamente anterior.

Adicionada claridad a la sección Incremento:

Un incremento es un cuerpo de trabajo inspeccionable y terminado que respalda el empirismo al final del Sprint. El incremento es un paso hacia una visión o meta.

Descarga la nueva versión de la guía en español:

Puedes hacerlo directamente haciendo clic aquí:

O también en:

http://www.scrumguides.org/download.html

Buscas la línea:

Spanish South American (November 2017) Lucho Salazar

Más de la guía en:

Un vistazo a la guía de Scrum

También puedes ver y descargar la guía aquí.