Antipatrones de Scrum: Scrum but

Scrum

Scrum no funciona. He escuchado esta frase muchas más veces de las que me gustaría admitir, aunque la realidad es que, cuando profundizamos en cómo estos equipos llevan Scrum en su día a día, salen a flote diversas prácticas que desvirtúan Scrum, prácticas que se llevan a cabo de manera incorrecta (de manera intencional o no intencional), y por lo tanto un efecto aparente es que Scrum “no está funcionando”, cuando la causa raíz es, en realidad, una mala práctica, o lo que se conoce como un **antipatrón**. Scrum un marco de trabajo, pero más que eso, hoy siendo las 5:34 a.m. del 8 de julio de 2024, continúa siendo **el marco de trabajo más utilizado en el mundo**, no lo digo yo, lo muestran los diversos estudios anuales sobre Agilidad o Agilismo que se publican por diversas organizaciones. Scrum establece una forma de colaborar evaluando de manera continua cómo construir un producto (o servicio), obtener retroalimentación del cliente/usuario final, y adaptar creativamente en base a la información obtenida siempre centrados en entregar un incremento de producto que agregue valor al cliente/usuario final. En este artículo no abordaremos lo que Scrum es, no es un artículo introductorio (si quieres leer un poco sobre los principios de Scrum, (link: https://leonelzapien.com/blog/que-es-scrum text: te comparto aquí un artículo que escribí sobre este tema hace un par de años)), aquí abordaremos sobre eso que “no es Scrum”, esos antipatrones que desvirtúan el marco de trabajo y consecuentemente llevan a equipos a sufrir el proceso y concluir que “Scrum no funciona”. (image: scrum-logo.webp) # Anti… ¿qué? Aquí abro un breve paréntesis. Primero lo primero, no sé si conozcas el término **antipatrón**, pero vamos iniciando aquí. Un antipatrón es un enfoque que nos va a conducir a una mala solución a un problema, pueden ser en ocasiones enfoques “generalizados” o que se utilicen ampliamente, pero, aun así, no deja de ser una solución inadecuada y por lo mismo son ineficaces y/o improductivos para resolver determinada clase de problemas comunes. Una vez aclarado lo anterior, ya hemos calentado motores, entremos directo en tema sobre de antipatrones en Scrum, ¡Aquí vamos! Cierro paréntesis. # Scrum but Hoy vengo a platicarte sobre algo que se conoce como **Scrum but…**, que traducido sería algo como **Scrum pero…**, y se le conoce así precisamente porque, cuando a alguien le preguntan: - Y ustedes, ¿utilizan Scrum? - ¡Claro que sí! - ¿Y cómo les va con *[inserte-aquí-cualquier-tópico-relacionado-con-Scrum]* (por ejemplo, las retrospectivas / producto backlog / incrementos de producto / la definición de terminado, etc.)? - Ah, bueno. Es que sí utilizamos **Scrum, pero…** *[inserte-aquí-cualquier-“parche”-o-forma-de-hacer-algo-que-no-está-alineado-con-La-Guía-Scrum]* Y ahí es donde surge el “pero”, es ahí donde, como decimos acá en México, la puerca torció el rabo. Por esto, hoy hablaremos sobre **Scrum but,** ya que esta lista de “peros” puede ser virtualmente infinita, vamos a ver algunos de los principales ejemplos que he tenido oportunidad de ver de primera mano en diversos equipos, así como posibles soluciones. Un tiene la siguiente estructura: **Scrum + pero + Antipatrón + Forma alternativa de “solucionar” la situación** (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-estructura-antipatron-cursos-consultor-guadalajara-mexico.webp) ¿Estás listo? ¡Ponte cómoda o cómoda y relájate, no lo tomes personal si con algunos de estos antipatrones sientes que “le queda el saco a tu equipo”, cualquier parecido con la realidad es mera coincidencia! ## Antipatrón #01: El Daily eterno (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-01-guadalajara-mexico.webp) **Usamos Scrum + pero… + hay demasiados temas por conversar en nuestra Daily + así que, en vez de 15 minutos, este evento dura entre 45 minutos y 1 hora.** Este es por mucho el antipatrón que más comúnmente he visto, pero así mismo, es de los más sencillo de reenfocar. Primero lo primero, ¿Cuál es la esencia del Daily Scrum? De acuerdo con La Guía Scrum, el Daily Scrum es un evento de hasta 15 minutos para los Desarrolladores del Equipo Scrum. Para reducir la complejidad, se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint. ¿Cómo podemos ayudar al equipo a que se cumpla el bloque de tiempo (timebox) de 15 minutos?, aquí te comparto uno tip súper simple y no por eso menos poderoso: • Utilizar un** Estacionamiento de temas** o **Parking lot**, donde podemos “estacionar” los temas que surjan durante el Daily que necesiten conversarse, la idea es no resolver los problemas durante el Daily, sino identificarlos, y posteriormente conversarlos solo con las personas directamente implicadas, puede ser de manera inmediata al terminar el Daily (algunos le llaman a esto post-Daily), o en algún momento posterior. La esencia es no alargar el Daily, y que, cuando se vaya a conversar, solo se involucre a las personas necesarias y no a todo el equipo. ## Antipatrón #02: Saltarse la retrospectiva (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-02-guadalajara-mexico.webp) **Usamos Scrum + pero… + tenemos tanto trabajo al final del Sprint + que mejor aprovechamos el tiempo de la retrospectiva para trabajar en lo que tengamos pendiente.** Este antipatrón me recuerda el meme de un cavernícola que está empujando una montaña de piedras sobre una carreta con “ruedas cuadradas”, claro que va sudando a chorros y sufriendo tremendo, mientras un segundo cavernícola le muestra una “rueda redonda” diciéndole que su invento le va a hacer la vida más fácil, y el primer cavernícola solo puede responder con el poco aire que le queda: “No tengo tiempo, estoy muy ocupado jalando esta carreta”. Tristemente, es el segundo antipatrón más común que he visto, donde los equipos no se dan el tiempo de hacer una pausa para analizar el último periodo de trabajo o Sprint, y reflexionar sobre cómo pueden mejorar. La Guía Scrum menciona que “El Equipo Scrum inspecciona cómo fue el último Sprint con respecto a las personas, las interacciones, los procesos, las herramientas y su Definición de Terminado. El Equipo Scrum analiza qué salió bien durante el Sprint, qué problemas encontró y cómo se resolvieron (o no) esos problemas.” Sin estos espacios para identificar los principales problemas que afectaron el equipo, sin conversaciones que les puedan ayudar a mejorar su efectividad, no se puede llegar a la mejora continua. Cada evento en Scrum tiene un propósito específico, en este caso, la retrospectiva fomenta este espacio para detenernos a “Afilar la sierra”, por más ocupados que estemos es fundamental tener y fomentar estos espacios, así como escuchar todas las voces, priorizar los elementos que se identifiquen en base a su posible impacto, y darles seguimiento. ## Antipatrón #03: Un día sí, y al otro día quién sabe (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-03-guadalajara-mexico.webp) **Usamos Scrum + pero… + tener el Daily todos los días quita demasiado tiempo + así que tenemos el Daily Scrum un día a la semana.** El evento Daily Scrum debe de ser diariamente. Un antipatrón que tiene un impacto muy negativo en el potencial que marco Scrum puede ofrecer es el no tener los Daily ahora sí que dice la palabra, diariamente. He tenido oportunidad de coincidir con equipos que tienen los Daily en frecuencias distintas a lo definido en La Guía Scrum: 1 vez a la semana, o cada tercer día, por mencionar algunos ejemplos. Entre las principales razones para hacer esto (la verdad debo de confesar que se puede dedicar mucho esfuerzo y creatividad para justificarlo muy bien), he escuchado cosas como: • Es muy costoso detener a todo el equipo de trabajar, todos los días. • Nuestro proceso es muy estable, no necesitamos reunirnos a diario. • Es un desperdicio de tiempo. • Mejor nos reunimos cuando surja algo. • Entre otras cosas. ¿Te suena familiar? La Guía Scrum menciona que el Daily Scrum se lleva a cabo a la misma hora y en el mismo lugar todos los días hábiles del Sprint, el Daily es una oportunidad para inspeccionar y adaptar el plan para lograr el objetivo del Sprint, y este es precisamente el sustento por el cual debe de realizarse diariamente, ya que trabajamos en entornos con alta volatilidad e incertidumbre, así mismo los productos o servicios que construimos, y las personas que colaboramos para construirlos, somos complejos. Hay infinitas variables que pueden afectar a un equipo, algo puede afectarnos durante un sprint, solo para asentarlo y nombrar algunas a manera de ejemplo: • Una persona se ha enfermado y no tenemos capacidad para realizar lo que él o ella hacía. • Para realizar algo en particular, acabamos de darnos cuenta de que se requiere un recurso específico (una licencia de un determinado software, un servidor, un servicio o proveedor, etc.), y se necesita conseguir a la brevedad posible, o bien, ver alguna opción alterna. • Ha surgido un defecto que es urgente solucionar. • Determinada situación ha provocado escasez o tiempos de entrega más largos de algún insumo. • Acaba de surgir una nueva pandemia, situación social que ha afectado al entorno del equipo, un apocalipsis zombi, etcétera y etcétera. La inspección frecuente permite la adaptación temprana, este es uno de los propósitos del Daily, identificar de manera oportuna problemas, riesgos, bloqueos que puedan presentarse, por eso la importancia de que sea diariamente, para proporcionar un ritmo o cadencia al equipo, y termina formando parte de los hábitos del equipo, por eso debe de celebrarse todos los días a la misma hora y en el mismo lugar (o en utilizando el mismo link de reunión recurrente, en caso de ser de manera remota), para de esta manera reducir la complejidad que implica el estarla reprogramando o moviendo de lugar (físico o remoto). ## Antipatrón #04: Sin retroalimentación real (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-04-guadalajara-mexico.webp) Usamos Scrum + pero… + nuestro cliente/usuario final está muy ocupado y no tiene tiempo para atender las Revisiones del Sprint + así que le enviamos un correo para informarle de las funcionalidades que se liberarán. La revisión del Sprint es un evento que, de acuerdo con La Guía Scrum, tiene como propósito inspeccionar el resultado del trabajo realizado durante el Sprint, y en base a esto, determinar futura adaptaciones. Aquí el punto clave es que el Equipo Scrum presente los resultados de su trabajo a los interesados clave y se discuta el progreso hacia el Objetivo del Producto. Pero, ¿Quiénes pueden ser interesados clave? La verdad es que depende del contexto, de entrada, es imprescindible que esté ahí el cliente / usuario final, esa persona quien finalmente va a utilizar nuestro producto. Lo que queremos es que este cliente / usuario final pruebe el producto, lo vea funcionar, lo tenga entre sus manos, le haga clic y vea qué hace… y en base a su experiencia con este incremento de producto real, nos proporcione retroalimentación valiosa que nos permita determinar si vamos bien, hacemos algunos ajustes, o definitivo no es por este camino y debemos girar el timón. Esta figura de cliente / usuario final es fundamental, pero aunado a esto y dependiendo del contexto, un interesado clave puede ser un determinado gerente, director, el patrocinador del proyecto o producto, inclusive dependiendo del caso, alguna figura externa como un proveedor, o algún representante de un organismo o grupo. Debido a todo esto, una Revisión de Sprint sin los interesados relevantes y sin esta figura principal que es el cliente / usuario final que viva en primera persona la experiencia del incremento de producto que el Equipo Scrum ha construido durante el Sprint, sin ellos, una revisión de Sprint carece totalmente de sentido. La Guía Scrum menciona también que, durante la Revisión del Sprint, el Equipo Scrum y los interesados revisan lo que se logró en el Sprint, conversan sobre lo que ha cambiado (prioridades, alguna cuestión del entorno, etc.), con base en esta información y con la experiencia de probar el incremento de producto, los asistentes a este evento colaboran para determinar qué hacer a continuación. Esto es fomenta un ambiente donde se transpiran los pilares de Scrum: Transparencia, inspección y adaptación. ## Antipatrón #05: No necesitamos un Scrum Master (image: leonel-zapien-lopez-ideas-agilidad-agilismo-scrum-but-antipatron-antipatrones-05-guadalajara-mexico.webp) **Usamos Scrum + pero… + no necesitamos un Scrum Master, el equipo ya sabe Scrum + así que el resto del equipo cubre las actividades del Scrum Master.** La Guía Scrum define que el Scrum Master es responsable de establecer Scrum como se define en la Guía de Scrum. Lo hace ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Equipo Scrum como de la organización. Un tema algunas veces controversial es, ¿Y qué hace el Scrum Master todo el tiempo?, es normal que esta pregunta surja sobre todo cuando el equipo Scrum ya tiene cierto grado de madurez y se puede decir que el equipo “ya sabe” Scrum. Pero el Scrum Master hace (o debería de hacer) muuucho más que eso, apoya al equipo Scrum (Desarrolladores y Product Owner), así como a la organización. La Guía Scrum menciona que el Scrum Master es responsable de lograr la efectividad del Equipo Scrum, por lo tanto, es el responsable final de que el equipo mejore continuamente, y siendo completamente honestos, esto implica **ver más allá de Scrum**, complementar con otras herramientas, métodos, prácticas, metodologías, etc., probar, experimentar, ayudar al equipo a descubrir nuevas formas de reducir los despilfarros o desperdicios, avanzar hacia mejores formas de colaborar. Esto puede incluir, por citar algunos ejemplos, complementar Scrum con **Kanban**, Pensamiento** Lean**, utilizar **Estructuras Liberadoras** para facilitar las sesiones ayudar a descubrir problemas, así como fomentar conversaciones, agregar prácticas de **Management 3.0** para centrarnos en las personas, prácticas de **Extreme Programming**, **Agile / Lean Inception**, **Lean Startup**, y una lista infinita de etcéteras y etcéteras. Por lo tanto, el Scrum Master es esencial, y si esta responsabilidad o rol (o cualquiera de los otros dos) no está, realmente no estamos trabajando con Scrum. ¿Cómo sabemos qué tal está haciendo su trabajo el Scrum Master?, su trabajo se ve indirectamente, se refleja en la forma en que el Equipo Scrum se está desempeñando, por eso es imprescindible esta figura para, como dice (link: https://agilemanifesto.org/ text: El Manifiesto Ágil): Continuar descubriendo mejores formas de trabajar. # Conclusiones Creo que una lista de antipatrones conocidos o potenciales en Scrum es virtualmente infinita, los cinco que he mencionado aquí creo que son algunos de los que he tenido oportunidad de ver de manera más recurrente. Lo triste del asunto es que este tipo de prácticas llevan a personas y equipos a sentir frustración porque **“Scrum no funciona”**, cuando la causa raíz es que se está llevando a cabo de una manera que no permite que los verdaderos super poderes de Scrum se muestren con todo su esplendor. Scrum define cómo un equipo autogestionado podría estructurar mejor su trabajo para ofrecer incrementos de producto y crear el mayor valor posible para todas las partes interesadas, funciona muy bien donde se trabaja con alta complejidad, donde existe alta incertidumbre, donde los requisitos del producto no están claros. De verdad que Scrum puede aportar enorme apalancamiento en todo esto. Solo, hay una consideración, y no es una que me haya inventado, sino que viene mencionada en la página 13 de La Guía Scrum 2020 (es la guía más reciente y, por lo tanto, la que está vigente). Dice lo siguiente: “El marco de trabajo Scrum, como se describe aquí [en La Guía Scrum], es inmutable. Si bien es posible implementar solo partes de Scrum, **el resultado no es Scrum**. Scrum existe solo en su totalidad y funciona bien como un contenedor para otras técnicas, metodologías y prácticas.” Así que podemos complementar Scrum con otros métodos, prácticas, herramientas, metodologías… pero no podemos “quitarle” cosas a como Scrum viene definido. Requiere de sus 3 roles, 5 eventos y 3 artefactos, tal y como se definen en La Guía Scrum. Cuando lo lleves a tu equipo, es esencial que lo acotes a tu contexto, experimentando lo que mejor funciona, pero dentro de lo que es válido para este marco de trabajo. Nunca dejemos de experimentar hacia la mejora continua, los resultados, más temprano que tarde, siempre, siempre, siempre llegan. **¿Qué opinas de estos antipatrones?, ¿Qué otros antipatrones agregarías?**

8 de julio de 2024

Scrum

Quiero iniciarme en el mundo de Scrum y existen 12’457,925 certificaciones… ¿Por dónde comienzo?

En un océano rojo de certificaciones, últimamente una pregunta que he escuchado mucho es: Quiero iniciar en el mundo de Scrum, quiero certificarme, pero ¿Por dónde comienzo? Pffff, pues la respuesta en estos casos siempre es: “**Depende**”. Y precisamente por ese “Depende”, aquí te comparto una **comparativa sobre algunas de las diversas casas certificadoras**, poniendo como suelo común para todas las mismas variables de comparación. **Primeramente: **Tooodas las entidades certificadoras ofrecen más o menos lo mismo: **Un curso de entre 12 y 20 horas + 2 intentos de examen**. Así que, de entrada, esto no es diferenciador sobre una decisión de dónde certificarse. Hay muchas opciones de entidades certificadoras: **Scrum Alliance, Scrum.org, Scrum Inc., AIBES, CertiProf, SCRUMstudy, inclusive también el PMI **tiene relativamente poco que ofrece su certificación de Scrum Master! Hay muchas opciones de entidades certificadoras: Unas más caras, unas más baratas, unas con mayor “prestigio” debido a que son respaldadas por algunos rockstars del mundo de la Agilidad. Pero de entrada **siempre he dicho que llegar a la conclusión que alguien es un Scrum Master "mejor preparado" porque se certificó con una entidad o con otra, es como decir que alguien egresado de una universidad privada "es mejor profesional" que alguien de una universidad pública**, no demerito en absoluto los planes de estudio ni los controles ni los recursos, pero en última instancia **depende de la persona** qué tanto lo aprovecha, depende de qué tantas ganas le ponga el alumno, no de la institución. El segundo punto antes de comenzar (y no menos importante), es que **una certificación no es garantía de experiencia,** es una evidencia de una acreditación, he conocido excelentes profesionales que no contaban con ninguna certificación, así como profesionales que contaban con una o varias certificaciones, y su nivel de desempeño era independiente de todo lo que había gastado. **De nueva cuenta: depende de la persona.** Con los dos puntos anteriores en mente, ahora sí, aquí te comparto esta comparativa objetiva entre diversas casas certificadoras, poniendo como suelo común las siguientes variables: • Si es mandatorio tomar un curso con ellos para poder presentar su examen de certificación. • Ofrece la opción de presentar exámenes sin tomar curso con ellos (esta opción es realmente complementaria a la anterior, pero lo separo para efecto de asentar y quede más claro). • Vigencia de sus certificaciones, ya que algunas no expiran y algunas necesitas estar renovándolas (con su correspondiente fee o cuota, además de algunos requisitos, de renovación). • Si cuenta o no con un path avanzado en el camino del Scrum Master. • Agrego una opción que pudiera parece ser obvia, pero en realidad es un gran diferenciador: Si se basa en **La Guía Scrum** o no. Como contexto te menciono que **La Guía Scrum** es escrita por sus co-creadores Jeff Sutherland y Ken Schwaber, por lo tanto, es **la fuente original de Scrum**, de aquí la importancia de que sepas si una certificación está basada en esta guía o no. • Idioma de sus exámenes. • Y sin entrar en detalles del rango de cuántos billetes verdes cuesta cada una, mejor de manera sencilla menciono una escala de precios: Alta, media o baja, para simplicidad en la comparación. ¿Qué te parece la idea, estás listo? Comencemos entonces: . # Scrum Alliance (image: scrumalliance.webp) • **Curso para presentar exámenes: **Obligatorio • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos:** No • **Vigencia de sus certificaciones:** 3 años • **Cuenta con path avanzado: **Sí • **Basada en La Guía Scrum: **Sí • **Idiomas de sus exámenes: **Inglés, español, etc. • **Escala de precios: **Alta La puse primero porque es la organización que más tiempo lleva activa. Fue creada por Ken Schwaber (uno de los co-creadores de Scrum), aunque hace ya varios años que se salió para crear su propia casa certificadora. Así mismo, varios de los rockstars de la Agilidad y firmantes del Manifiesto Ágil han colaborado aquí. Cuenta con 3 niveles de especialización: 1. **Certified ScrumMaster (CSM): **Nivel I 2. **Advance Certified ScrumMaster (A-CSM): **Nivel II 3. **Certified Scrum Professional - ScrumMaster (CSP-SM):** Nivel III Cuando hice el examen con ellos (hace varios años ya), era un examen de 35 preguntas a responder, tengo entendido que ahora lo incrementaron a 50 preguntas en 1 hora. La única manera de obtener una certificación de Scrum Alliance es tomando un curso con uno de sus facilitadores certificados, y con eso obtienes derecho para presentar el examen. Sus certificaciones se renuevan cada 3 años, y para hacerlo debes de realizar una de dos cosas: 1. Pagar un fee o cuota de renovación + haber sumado una serie de puntos que Scrum Alliance llama SEUs (Scrum Education Units), que puedes obtener de diversas maneras: Estudiando o actualizándote en el tema, como tomando cursos o webinars, haciendo voluntariado, etc. Cada hora de un curso que tomes o cada hora de voluntariado que realices equivale a 1 SEU, y dependiendo de la certificación, puedes requerir acreditar entre 20 y 30 SEUs (ojo: Si acumulas más certificaciones con ellos, vas a necesitar más SEUs, pues a más certificaciones solicitan más SEUs para renovar). 2. La segunda opción es, si ya tienes una certificación y tomas otro curso con ellos y te certificas, automáticamente se renueva el periodo de tu primera certificación (en este caso la extensión se vigencia se hace solo por 2 años más). Como dato cultural, la certificación Certified ScrumMaster (CSM) fue la primera certificación de Scrum en el mundo en salir al mercado. Aunque de eso, como decimos acá en México, ya llovió. . # Scrum.org (image: scrumorg.webp) • **Curso para presentar exámenes: **Opcional • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos: **Sí • **Vigencia de sus certificaciones:** Sin expiración • **Cuenta con path avanzado:** Sí • **Basada en La Guía Scrum: **Sí • **Idiomas de sus exámenes:** Solo en inglés • **Escala de precios:** Alta Surgió algunos años después que Scrum Alliance, Ken Schwaber (co-fundador de Scrum) después de dejar Scrum Alliance respalda ahora esta casa certificadora, así que el material y contenido tiene ese aval de alineación a La Guía Scrum. Cuenta con 3 niveles de especialización: 1. **Professional Scrum Master I (PSM I):** Nivel I 2. **Professional Scrum Master II (PSM II): **Nivel II 3. **Professional Scrum Master III (PSM III):** Nivel III Aquí una observación: Scrum.org ofrece este path de especialización como Scrum Master, pero cuenta con otras opciones para avanzar en el camino de Scrum, como por ejemplo profundizar en Nexus, un marco para escalar Scrum. Cuando hice el examen con ellos, era un examen de 80 preguntas a responder en 1 hora. Otro punto: Sus exámenes los ofrece solo en idioma inglés (claro puedes utilizar un traductor, pero de entrada para que lo consideres). Sus certificaciones no expiran, eso es algo importante a poner en la balanza al momento de evaluar tus opciones, considerando que esta casa certificadora con precios altos. Una manera de obtener una certificación de Scrum.org es tomando un curso con uno de sus facilitadores certificados, y con eso obtienes derecho para presentar el examen. La segunda opción es de comprar únicamente un voucher para presentar el examen de certificación sin tener que haber tomado un curso con ellos. El costo de solo el examen es obviamente mucho más bajo que si tomas el curso, aquí ya depende de cuál sea tu objetivo: Tomar un workshop y aplicar el examen, o solo obtener el certificado. Ambas opciones son totalmente válidas. . # Scrum Inc. (image: scruminc.webp) • **Curso para presentar exámenes:** Obligatorio • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos:** No • **Vigencia de sus certificaciones: **Anual • **Cuenta con path avanzado: **Sí • **Basada en La Guía Scrum:** Sí • **Idiomas de sus exámenes:** Inglés, español, etc. •** Escala de precios: **Media-Alta Esta casa certificadora es de las más recientes en creación, pero no en experiencia ya que fue fundada por Jeff Sutherland (el otro co-creador de Scrum), así que el material y contenido tiene ese aval de alineación a La Guía Scrum. La única manera de obtener una certificación de Scrum Inc. es tomando un curso con uno de sus facilitadores certificados, y con eso obtienes derecho para presentar el examen. Su certificación es: • **Registered Scrum Master (RSM).** Aquí una observación: Scrum Inc. No ofrece un path de especialización como Scrum Alliance o Scrum.org directamente para el Scrum Master, pero cuenta con otras opciones para avanzar en el camino de Scrum, como por ejemplo profundizar en Scrum@Scale, un marco para escalar Scrum. En cuanto al tema de las renovaciones, sus certificaciones se deben de renovar cada año, y para hacerlo ofrecen 2 opciones: • Pagar un fee o cuota de renovación anual, y renovar tu certificación cada año. • Pagar un fee o cuota un tanto mayor que la opción anual, pero es un pago de una sola ocasión y con esto extiendes tu certificación a que ya no expire. . # AIBES (image: aibes.webp) • **Curso para presentar exámenes:** Opcional • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos: **Sí • **Vigencia de sus certificaciones: **Sin expiración • **Cuenta con path avanzado: **No • **Basada en La Guía Scrum: **Sí • **Idiomas de sus exámenes: **Solo en español •** Escala de precios: **Media Esta casa certificadora es la Asociación Iberoamericana de Scrum (AIBES), también es de relativa reciente en creación. Como su nombre lo indica, de entrada, su sitio web y recurso son en idioma español, algo que no sucede con otras entidades certificadoras. Su certificación es: • **Official Scrum Master Certification (OSMC).** Una manera de obtener una certificación de AIBES es tomando un curso con uno de sus facilitadores certificados, y con eso obtienes derecho para presentar el examen. La segunda opción es de comprar únicamente un voucher para presentar el examen de certificación sin tener que haber tomado un curso con ellos. El costo de solo el examen es obviamente mucho más bajo que si tomas el curso, aquí al igual que con otras casas certificadoras que ofrecen este esquema de vouchers para examen, ya depende de cuál sea tu objetivo: Tomar un workshop y aplicar el examen, o solo obtener el certificado. Ambas opciones son totalmente válidas. Como nota adicional, AIBES ofrece también una certificación de fundamentos en Scrum, no es prerrequisito para la de Scrum Master ni queda dentro de alcance de este artículo, pero para que lo tomes en cuenta, ¿Va que va? . # CertiProf (image: certiprof.webp) • **Curso para presentar exámenes:** Opcional • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos: **Sí • **Vigencia de sus certificaciones:** Sin expiración • **Cuenta con path avanzado: **Sí • **Basada en La Guía Scrum: **Sí • **Idiomas de sus exámenes:** Inglés, español, etc. •** Escala de precios:** Baja Esta casa certificadora también es de relativa reciente en creación, ofrece diversas certificaciones, entre las cuales están las de Scrum. Cuenta con 2 niveles de especialización: 1. **Scrum Master Professional Certificate (SMPC):** Nivel I 2. **Scrum Advanced Professional Certificate (SAPC): **Nivel II Aquí una observación: CertiProf ofrece este path de especialización, solo que no es un nivel exclusivo de Scrum Master, ya que puedes llegar a Scrum Advanced Professional Certificate (SAPC) por el camino de Scrum Master o de Product Owner, contar con una certificación de Scrum Master o Product Owner de cualquier otra entidad certificadora es el prerrequisito para aplicar para SAPC + presentar un examen y aprobar un examen. Una manera de obtener una certificación de CertiProf es tomando un curso con uno de sus facilitadores, y con eso obtienes derecho para presentar el examen. La segunda opción es de comprar únicamente un voucher para presentar el examen de certificación sin tener que haber tomado un curso con ellos. El costo de solo el examen es obviamente más bajo que si tomas el curso, aquí al igual que con otras casas certificadoras que ofrecen este esquema de vouchers para examen, ya depende de cuál sea tu objetivo: Tomar un workshop y aplicar el examen, o solo obtener el certificado. Ambas opciones son totalmente válidas. El examen de Scrum Master de CertiProf consta de 40 preguntas a realizarse en 60 minutos. Como nota adicional, CertiProf ofrece también una certificación de fundamentos en Scrum que es gratuita, no es prerrequisito para la de Scrum Master ni queda dentro de alcance de este artículo, pero para que lo tomes en cuenta, ¿Okidoki? . # SCRUMstudy (image: scrumstudy.webp) • **Curso para presentar exámenes:** Opcional • **Ofrece la opción para presentar exámenes sin haber tomado curso con ellos:** Sí • **Vigencia de sus certificaciones:** 3 años • **Cuenta con path avanzado:** Sí • **Basada en La Guía Scrum: **No • **Escala de precios: **Media Esta entidad certificadora es de relativa reciente creación, aunque tiene ya algunos años. Ofrece no solo certificaciones en Scrum, sino también en otras áreas. Cuenta con 3 niveles de especialización: 1. **Scrum Master Certificate (SMC):** Nivel I 2. **Scaled Scrum Master Certificate (SSMC):** Nivel II 3. **Expert Scrum Master Certificate (ESMC):** Nivel III Aquí una observación: SCRUMstudy ofrece este path de especialización, pero el nivel siguiente que mencionan en su sitio web, Scaled Scrum Master Certified, es para escalar Scrum, y para hablar de lo mismo, poniendo en contexto manzanas con manzanas, si hablamos de escalar Scrum, deberíamos compararlo con Nexus de Scrum.org o Scrum@Scale de Scrum Inc., pero este es el path que ofrecen. Así mismo, el nivel de Expert Scrum Master Certificate (ESMC) no es un nivel exclusivo de Scrum Master, ya que puedes llegar por el camino de Scrum Master o de Product Owner, dentro de sus certificaciones. El examen para Scrum Master Certificate consta de 100 preguntas a responder en 2 horas. Una manera de obtener una certificación de SCRUMstudy es tomando un curso con uno de sus facilitadores, y con eso obtienes derecho para presentar el examen. La segunda opción es de comprar únicamente un voucher para presentar el examen de certificación sin tener que haber tomado un curso con ellos. Aquí ya depende de cuál sea tu objetivo: Tomar un workshop y aplicar el examen, o solo obtener el certificado. Ambas opciones son totalmente válidas. Un punto para tu consideración: SCRUMstudy ha creado algo que se llaman SBOK (Scrum Body of Knowledge), la cual es su guía para la implementación de Scrum, en este sentido, es la única entidad certificadora que se basa en el SBOK y no en La Guía Scrum para su contenido y exámenes. No menciono que esté bien o mal (ni todo lo contrario 😉), solo menciono objetivamente que SCRUMStudy es la única que se basa en el SBOK y todos los demás en La Guía Scrum (además de que el SBOK tiene grandes diferencias de fondo contra La Guía Scrum), entonces revisa muy bien el contenido antes de tomar una decisión. Sus certificaciones se renuevan cada 3 años, y para hacerlo debes de: • Realizar un examen de recertificación (Consta de la mitad de preguntas que el examen de certificación inicial). Tomar de nueva cuenta un curso con ellos es opcional, acreditar el examen de recertificación es el objetivo, por lo cual puedes pagar directamente tu voucher para presentarlo, cualquiera de las dos opciones. Como nota adicional, SCRUMstudy ofrece también una certificación de fundamentos en Scrum que es gratuita, no es prerrequisito para la de Scrum Master ni queda dentro de alcance de este artículo, pero para que lo tomes en cuenta, ¿Va que va? . # Scrum Master del PMI y SAFe Aquí abro un paréntesis y menciono tanto al PMI (Project Management Institute), como SAFe (Scaled Agile Framework) porque también ofrecen certificaciones de Scrum Master, solo que los menciono como un adendum porque su certificación es particular para su contexto, ¿A qué me refiero con esto? Comencemos con SAFe, que sacó al mercado su certificación de Scrum Master primero que el PMI. . # SAFe (Scaled Agile Framework) (image: safe.webp) La certificación de SAFe se llama: • **SAFe Scrum Master** Es el rol de Scrum Master dentro del contexto de SAFe, es decir, profundizan en cuestiones que solo son aplicables a este modelo de escalado. Habla por lo tanto de incrementos de programa (PI), roles de SAFe, entre otras cuestiones. El examen para obtener la certificación SAFe Scrum Master consta de 45 preguntas a realizar en 90 minutos, y esta certificación tiene un año de vigencia, para renovarla es necesario un fee o cuota de renovación. . # PMI (Project Management Institute) (image: pmi.webp) La certificación del PMI se llama: • **Disciplined Agile Scrum Master (DASM)** Es el rol de Scrum Master dentro del contexto de Disciplined Agile del PMI. Discipline Agile incluye conceptos de Scrum, pero adicionalmente de Kanban, y hasta de SAFe, entre otros. Por lo tanto, el rol es más amplio, y toma los principios de Agile y Scrum, en conjunto con otras herramientas. Tiene un path de especialización: • **Disciplined Agile Scrum Master (DASM)** • **Disciplined Agile Senior Scrum Master (DASSM)** Después de las certificaciones anteriores, el path de especialización continúa, pero ya va enfocado en temas de Agile Coaching o Flujos de valor (Vale Stream). La certificación DASM tiene un año de vigencia, y para renovarla es un proceso similar a cualquier otra certificación del PMI: Reunir una cantidad determinada de PDUs (Professional Development Unit) que reúnes a través de horas de formación, cursos o webinars, voluntariado, etc. + un fee o cuota de renovación. Como nota adicional, el PMI cuenta además con la certificación PMI-ACP (Project Management Institute – Agile Certified Practitioner), lo menciono para que lo tengas presente, pero queda fuera del alcance de este artículo porque no es específica de Scrum. . ## Pfffff… toooodo eso!!! Este es (y por mucho) el artículo más largo que he escrito hasta el momento, pero creo que el tema lo valía y finalmente** la idea es que cuentes con la información necesaria para que puedas tomar una decisión informada. Al menos, esa es mi intención de todo corazón :)** Me gustaría cerrar reiterando lo que mencioné al inicio de este (sumamente largo) artículo, de que una certificación no es garantía de experiencia, sino algo que puede ser un complemento a la misma, y que un Scrum Master "mejor preparado" es indistinto de la entidad certificadora donde se haya certificado, es como decir que alguien egresado de una universidad privada "es mejor profesional" que alguien de una universidad pública, no demerito en absoluto los planes de estudio ni los controles ni los recursos, pero **en última instancia todo depende de la persona** qué tanto lo aprovecha, depende de qué tantas ganas le ponga el alumno, **no de la institución.** **Cuéntame, ¿Qué te pareció esta guía de certificaciones de Scrum Master?, ¿Te ayudó aclarar tus dudas o te han surgido algunas nuevas?** ** Cualquier duda o comentario, quedo a un clic de distancia.**

31 de octubre de 2023

Scrum

Scrum & Calidad: 5.1 tips para una poderosa Definición de Terminado

En Scrum, hablar de calidad del producto es hablar de la **Definición de Terminado**, la cuál es popularmente conocida como **DoD**, así a secas, DoD, un acrónimo debido a su nombre en inglés: **Definition of Done**. Esta Definición de Terminado es una descripción formal de lo que debe de cumplirse para que el producto que se está entregando cuente con las medidas de calidad requeridas. Es decir, lo que debe de cumplirse y validarse para asegurar que el producto que se está construyendo pueda ser puesto en producción, que lo pueda utilizar directamente usuario final, y que sea un producto de calidad (que no tenga fallas o bugs, que cumpla con los lineamientos de la organización, que el programa no “se rompa”, etcétera). No pretendo que este sea un artículo teórico, pero es necesario ver algo de teoría. Así que, partiendo de una “definición de libro”, veamos qué es la Definición de Terminado. De acuerdo con el Glosario de Scrum.org, la Definición de Terminado es: **“Un entendimiento compartido de las expectativas que el incremento debe cumplir para poder ser liberado a la producción.”** Aquí hay un par de ideas clave que es relevante enfatizar: • **“Entendimiento compartido”:** Esto significa que es co-creada por todo el equipo Scrum, que todos la comprenden y están de acuerdo con ella. Es decir, que no es algo que definen solo los desarrolladores como área técnica, sino que negocio, a través del Product Owner, debe de compartir este entendimiento. **• “Las expectativas que el incremento debe cumplir”:** En Scrum buscamos entregar un incremento de producto en cada sprint, esto es un incremento funcional que puede utilizar el usuario final a partir de ese momento en caso de ser requerido. Por eso, al definir en la DoD lo que el producto debe de cumplir, se crea una línea base en términos de calidad, ya que cualquier incremento de producto cumple siempre con la DoD, lo que quiere decir que hay un nivel de calidad “mínimo” establecido para todos los incrementos. **• “Para ser liberado a producción”:** Como mencionaba en el punto anterior, cada incremento de producto que se entrega debe de ser un incremento completamente funcional, que puede utilizar el usuario final, a partir de ese momento en caso de ser requerido. Al ser un entendimiento compartido, es claro y transparente para todo el equipo lo que “terminado” significa. No existe algo como “**casi-casi-terminado**”, está terminado o no lo está, por lo tanto, se puede entregar o no. Aquí me gustaría compartir 5.1 puntos muy chéveres para que puedas co-crear con tu equipo una poderosa Definición de Terminado. Estas son algunas ideas que han funcionado después de colaborar con diversos equipos. Veamos una por una: # 1. Co-creación: Ya que se trata de un entendimiento compartido por el equipo, es mucho más enriquecedor que sea co-creado por todo el equipo. Parecerá obvio este punto, pero una vez colaboré con un equipo en el cual el líder técnico definía la DoD porque era quien “tiene más experiencia”, y el resto del equipo, por ser juniors, solo se apegaba a lo definido. Nos tomó un tiempo el que pudiéramos avanzar todos juntos hacia la co-creación, pero ya llegando a ese nivel, el crecimiento del equipo y de la calidad del producto fue innegable. **La co-creación fomenta la diversidad de ideas y perspectivas, además de que ayuda s que las personas sientan que formaron parte en el proceso de crear algo nuevo, por lo que el sentido de pertenencia y compromiso aumenta.** # 2. Evolutiva: **La DoD debe de inspeccionarse y adaptarse regularmente**, no está escrita en piedra, y conforme el equipo va madurando, también la DoD debe de hacerlo. En un escenario real, ya que hablamos de responder al cambio, es necesario que la DoD se ajuste conforme el contexto técnico cambia, por ejemplo, ¿Se ha detectado un nuevo defecto o bug que no había ocurrido antes?, o ¿Qué tal cuando una actualización tecnológica hace necesaria una nueva validación? Si es el caso, agregar eso a la DoD. # 3. Visión del futuro: Ya que la DoD debe de ir madurando y evolucionado, es poderosísimo que el equipo tenga una visión compartida del estado futuro que pretende alcanzar, el nivel de calidad al cual el equipo aspira a llegar, quizá no este sprint ni el siguiente, pero sí como un estado hacia el cual el equipo va avanzando, paso a paso. Tal vez técnicamente el equipo aún no tiene los conocimientos y/o experiencia necesaria, pero está capacitándose, aprendiendo y eventualmente llegarán a ahí. # 4. No es una receta de cocina: La DoD no debe de ser prescriptiva. Indicar con puntos y comas lo que se debe de hacer como un procedimiento o receta, puede limitar la autogestión del equipo. Aquí no hay “mejores prácticas”, solo recordemos que no buscamos la documentación extensiva. Lo adecuado, como todo en la vida, es el balance. Documentar en la DoD lo justo y necesario para el equipo, no más, no menos. # 5. Transparencia real: La transparencia significa que la información debe de estar visible y disponible para las personas interesadas. En este caso, con transparencia “real” me refiero a que no solo visible y disponible es suficiente, sino que debe de ser entendible y comprensible para todos. Por ejemplo, ¿El Producto Owner sabe a qué se refiere que todo el código esté integrado?, la verdad es que no es necesario que sepa cómo hacerlo técnicamente, pero sí es importante que comprenda la esencia de lo que esto implica, y que comprenda su importancia, así como el impacto de no hacerlo. # 5.1 Y aquí un Bonus: ¡Diversión! Esto es fundamental. El cumplir con objetivos de calidad y código limpio no implica que debe de ser algo aburrido. Desde las dinámicas de facilitación para co-crear una DoD, inspeccionarla y adaptarla, hasta el aseguramiento de su cumplimiento, son oportunidades para que el equipo se divierta, se abra a lo lúdico, a nuevas ideas, fomentar las condiciones para que el equipo entre en estado de “Flow” y detone la creatividad. ¿Lo has experimentado con tu equipo? Que el equipo cuente con una DoD es esencial, si no cuenta con una,** el mejor momento para empezar a co-crearla fue el sprint pasado. El segundo mejor momento es hoy**. El hacer código limpio siempre evita problemas y dolores de cabeza, ayuda a no dejar trabajo pendiente para el final o “**escondido debajo de la alfombra**” que regresará al equipo después como problemas debido a mala calidad. El retrabajo es un tipo de desperdicio e impacta en la productividad. (image: icono-iceberg-05-large-to-web-site.webp) Para cerrar, me gustaría reforzar que el objetivo de Scrum es entregar cada sprint un incremento de producto que sea funcional, que cumpla con el objetivo del sprint y que, en última instancia, sea un paso adelante hacia el objetivo del producto… y la Definición de Terminado, es piedra angular en esto. Recordemos que** en el momento en que un elemento del Product Backlog cumple con la Definición de Terminado, nace un Incremento de producto.** Cuéntanos, ¿Qué te parecieron estos 5.1 puntos para una poderosa DoD? ¿Qué otro punto agregarías? Me encatará leerte y que conversemos :)

2 de junio de 2023

Scrum

El primer libro de Scrum del mundo

**“El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum”**. Así es como introducen Ken Schwaber y Mike Beedle por primera vez el evento Daily Scrum en el libro **“Agile Software Development with Scrum”**, el cual fue el primer libro escrito en la historia de la humanidad sobre el marco de trabajo Scrum, por allá del año 2001. Hace unos días estuve releyendo el libro “Agile Software Development with Scrum” (Desarrollo de Software con Scrum), el cual es conocido en el mundo de la Agilidad como **“El libro negro de Scrum” **por su característica portada. Es una joya histórica por ser el primero de miles y miles y miles de libros que se han escrito sobre Scrum a lo largo y ancho del mundo. ¿Te ha pasado alguna vez que una película o canción que “te gustaba mil” cuando eras adolescente, cuando la ves o escuchas 10-15 años después… como que ya no “conecta” contigo? De igual manera, cada que leemos de nueva cuenta un libro lo vemos con una perspectiva distinta, puesto que somos una persona “diferente” de cuando lo leímos por primera vez (nuevas experiencias de vida nos han llevado a nuevos modelos mentales, nuevos paradigmas, nueva ideología, nuevas prioridades, etcétera). En este caso, después de releer “El libro negro de Scrum” no puede ser más cierto que lo veo desde una perspectiva distinta, no solo porque yo he evolucionado como persona… sino que **Scrum, como marco de trabajo, también ha evolucionado** (a verdaderos pasos agigantados) desde que lo presentaron al mundo oficialmente en 1995 sus co-creadores Jeff Sutherland y Ken Schwaber (quien es, por cierto, uno de los co-autores de este libro). Aquí te comparto varias ideas sobre Scrum tal como fueron concebidas originalmente, así como una comparativa con el enfoque actual. Lo interesante es que, si lo vemos con las gafas o lentes de hoy,** a 21 años de la publicación de este libro, muchas de sus ideas pueden considerarse como disfuncionales o incluso antipatrones**… Entonces, ¿está mal el libro? ¡Nada de eso!, solo recordemos que estamos en la “tierra del empirismo”, debemos de crear para enseguida inspeccionar y adaptar. Así que el hecho de que Scrum haya evolucionado de la manera que lo ha hecho (y lo seguirá haciendo), es una muestra clara del empirismo aplicado a su máximo potencial. ¡Poderosísimo! Sin más rollos, aquí van algunas de estas comparativa de ideas acerca del “Scrum del primer libro” y el enfoque actual: ## 1. El Daily Scrum es una junta de estatus… que solo debe de llevar ¡el Scrum Master! **1.1 **“El equipo Scrum se reúne diariamente para una breve junta de estatus llamada el Daily Scrum” **1.2 **“El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum. El Scrum Master mantiene el Daily Scrum breve, hace cumplir las reglas asegurándose de que las personas hablen brevemente.” Si un Scrum Master llegara este 2023 al evento internacional Scrum Day y dijera que el evento Daily Scrum es una junta de estatus, una muchedumbre con antorchas y trinchetes lo acusaría de anti-Agilista. (image: muchedumbre-con-fuego-y-trinchetes.webp) Imagen de WikiSimpsons (https://simpsons.fandom.com/es/wiki/Turba_furiosa) Me sorprendió ver que al Daily Scrum se le concibió inicialmente como una junta de estatus. Todo esto ha evolucionado, actualmente el Daily (así se le conoce en el medio, Daily “a secas”) no es para entregar estatus, tiene como propósito generar transparencia, que en equipo se inspeccione el progreso hacia el Objetivo del Sprint y adaptar según sea necesario. Respecto a la segunda idea del libro,** “El Scrum Master es responsable de conducir satisfactoriamente el Daily Scrum”**, la evolución nos ha llevado a buscar el enfoque en la autogestión del equipo, es decir, que sean capaces de gestionarse sin necesidad de que un Scrum Master lo haga por ellos, por esto actualmente el Daily es un evento de los Desarrolladores para los Desarrolladores, ellos mismos inspeccionan su progreso hacia el ya mencionado Objetivo del Sprint, el Scrum Master no dirige la sesión, y, de hecho, puede no asistir y el evento no se detiene. ## 2. No es un Marco de Trabajo o Framework… es un ¿Método? En la introducción del libro, Mike Beedle (co-autor) menciona: “Tuve la buena fortuna de leer un mensaje de Jeff Sutherland y reconocer que era de hecho información muy importante. Él anunció que junto con Ken Schwaber estuvieron trabajando en **un método llamado Scrum**” Este punto me llamó mucho la atención, pues es añejo el debate sobre Scrum sobre si es un Framework y por qué no es una Metodología, pero antes de este libro nunca había visto que lo llamaran método. Para aquellos que ya conocen Scrum, disculpen que lo vuelva a mencionar, pero siempre partimos de aclarar que Scrum es un Marco de Trabajo o Framework, pues proporciona una serie de eventos y artefactos con los que se debe de trabajar, indicando 3 roles (Scrum Master, Product Owner y Desarrolladores), con esto se identifican los resultados que se desean obtener, pero no entra en ningún tipo de detalle sobre la manera en que esto debe de hacerse, es decir, deja “espacio abierto” a los propios equipos para sean ellos quienes decidan la mejor manera de hacer esto, el “cómo” hacerlo, en su contexto particular. Eso es un Framework, en tanto que un Método es un modo ordenado y sistemático de actuar o proceder para llegar a un resultado o fin determinado. Siendo muy simplistas podemos decir que es un procedimiento que se sigue para conseguir un objetivo. Un Framework deja más espacio a que las personas definan la manera de hacer las cosas, fomenta la experimentación y el empirismo, pues solo es una base para resolver un tipo de situaciones. ## 3. Enfoque en Proyectos y más Proyectos **3.1 **“Cada proyecto es diferente […] Diversas tácticas ayudan, pero sin Scrum esos proyectos fueron eventualmente abrumados por la complejidad inherente en proyectos de desarrollo de sistemas” **3.2 **“La gerencia debe de negociar de las cuatro variables [costo, fecha, funcionalidad y calidad] con los clientes “ Es oficial: **Scrum inició como un enfoque para gestionar proyectos de manera ágil**. Esto ha evolucionado en el último par de décadas y el enfoque actual no es hacer proyectos, sino productos. Esto quizá pueda sonar contradictorio, pues un producto puede ser el entregable que se genera al finalizar un proyecto, un resultado único. Esto es cierto, vivimos en un mundo de proyectos, pero la enorme diferencia es el enfoque… un proyecto se centra en entregar “algo” dentro del tiempo, costo y alcance definido, en tanto que, desde la perspectiva de producto, nos centramos en el impacto que este “algo” que entregamos produce para el usuario final. Buscamos construir productos que resuelvan algún problema del usuario/cliente, que hagan su vida más fácil. Un producto define su éxito en base al **V-A-L-O-R **que proporciona. ** P.D. #1** Personalmente siempre he creído que debemos de ir un paso más allá… un producto que resuelva un problema lo puede hacer cualquiera, **debemos enfocarnos en ¡crear productos que enamoren!** Estas son solo algunas de las ideas del “Scrum del primer libro” que plantean Schwaber y Beedle, la verdad es que hay mucha tela de la cual cortar. Es de esos temas profundos que dan para largas conversaciones acompañadas de un buen café, té, mate o la bebida de tu predilección (en mi caso, me inclino por el té verde). Por esto, y para no hacer un artículo tan extenso, en una próxima entrada de Blog continuaré con la segunda parte de “El primer libro de Scrum del mundo”. ¡Nos vemos en el capítulo 2! **P.D. #2** Mike Beedle (1962-2018), co-autor de este libro y firmante original del Manifiesto Ágil, fue mi primer maestro de Scrum. Con él tuve el enorme gusto de tomar mi primer curso de Scrum por allá del año 2014, una experiencia súper chévere! **Pero, por favor cuéntanos: ¿Conocías la esencia original de Scrum? ¿Qué opinas sobre la forma en que Scrum ha evolucionado? ¿Qué te pareció?**

26 de abril de 2023

Scrum

¿Qué es Scrum?

¿Has escuchado hablar sobre el término Scrum?, la verdad es que está en auge pero esta forma de trabajar existe desde hace poco más de un par de décadas. En este post hablaremos sobre lo que es (y lo que no es) Scrum, cabe aclarar que es una breve introducción, ahondaremos más en futuras entradas a este blog. Comenzamos! ###La guía de Scrum De acuerdo con la guía de Scrum: “Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos.” Sus creadores, Ken Schwaber & Jeff Sutherland desarrollaron este marco a principios de la década de 1990, y oficialmente vio la luz bajo el nombre de “Scrum Development Process” en una conferencia que se celebra anualmente en Estados Unidos llamada OOPSLA (Object-Oriented Programming, Systems, Languages & Applications), celebrada en Austin, Texas en 1995. Esta es la primera vez que se utiliza el término Scrum. ###No es ninguna metodología Ojalá tuviera una galleta de chispas de chocolate (keto, sin gluten, sin conservadores y sin azúcar) por cada ocasión que he escuchado que Scrum es una metodología :D Scrum no es ninguna metodología. De acuerdo con el diccionario Merriam-Webster, una metodología es un conjunto de métodos, reglas y postulados empleados por una disciplina o conjunto de procedimientos, y Scrum definitivamente no es eso, es un marco de trabajo que proporciona unos límites dentro de los cuales podemos desenvolvernos, habilita la auto-organización y prioriza la entrega de valor. Complementando lo anterior, de acuerdo con Schwaber & Sutherland (2020), Scrum no es un proceso, técnica o método, es un marco de trabajo (framework) bajo el cual se pueden abordar problemas complejos de manera adaptativa. En las propias palabras de Jeff Sutherland (2016) cuando se le pregunta por qué Scrum, él mismo dice: “Creé Scrum, con Ken Schwaber, hace veinte años, como una manera rápida, confiable y eficaz de crear software en la industria de la tecnología. Hasta ese momento –y aún en 2005-, la mayoría de los proyectos de desarrollo de software se ejecutaban usando el método en cascada, donde un proyecto se completaba en etapas separadas y avanzaba paso a paso hacia el lanzamiento último a los consumidores o usuarios de software.” El proceso tradicional era lento e impredecible (con retrasos de meses o inclusive años), y a menudo no resultaba en un producto que la gente necesitara. Sutherland continúa, “Scrum se asemeja en cambio a los sistemas evolutivos, adaptativos y capaces de autocorregirse.” ###Viene del Rugby El término Scrum no es ningún acrónimo, ni siquiera un término tecnológico. El término procede del rugby y se refiere al modo en que un equipo se desempeña en común para mover el balón por la cancha con acoplamiento, unidad de propósito y claridad de metas. La metáfora del balón que es movido por todo el equipo en conjunto fue lo que les encantó, fue la manera en que visualizaron a un equipo trabajando todos en conjunto para crear un producto. ###Inspeccionar y Ajustar Scrum se basa en una idea simple: ¿Por qué no revisar con regularidad lo que el equipo está construyendo para que el cliente o usuario final nos de retroalimentación directa y saber ver si lo que se está haciendo va en la dirección correcta? ¿Por qué no revisar frecuentemente si se puede hacer mejor? Esto es en lo que se basa Scrum, cada determinado tiempo el equipo hace una pausa, revisa lo que hizo y determina si debe de seguir haciéndolo (así como la manera en que podría hacerlo mejor). Este tiempo es una iteración o Sprint, y tiene un duración como máximo de 4 semanas, es decir, cada 4 semanas (máximo) el cliente o usuario tendrá un incremento del producto que espera, lo podrá ver y utilizar, y nos proporcionará retroalimentación valiosa. ###Una forma de ser ágil Scrum es un marco de trabajo para ser Ágil o Agile, pero no es la única manera de serlo. Actualmente existen diversos marcos y métodos para habilitar la agilidad, entre los cuales Scrum es precisamente el más utilizado alrededor de todo el mundo. De acuerdo con el estudio Agile Adoption Reporte 2020 de CertiProf realizado a más de 80,000 profesionales ubicados en América del Sur y del Norte, España, África y Asia sobre la agilidad, el 66% de los encuestados están familiarizados o trabajan con Scrum, después le siguen Kanban con el 15%, y el resto está distribuido en porcentajes mejores 4%, por lo que la popularidad de Scrum es, con mucho, predominante, tal como se puede observar en la siguiente imagen. (image: scrum2.webp) (Imagen: Agile Adoption Reporte 2020 de CertiProf) Este marco de referencia consiste en un equipo Scrum formado de 3 roles (Scrum Master, Product Owner y Desarrolladores), 4 eventos + 1 contenedor (Sprint, Planeación del Sprint, Scrum Diario, Revisión del Sprint y Retrospectiva del Sprint), y 3 artefactos (Product Backlog, Sprint Backlog e Incremento de Producto). Cada componente dentro del marco sirve a un propósito específico y es esencial para su uso, cada uno de los cuales revisaremos a detalle más adelante en futuras entradas de este blog. ###Empirismo Cuando trabajamos con problemas complejos no hay una "mejor práctica" para abordarlos, ya que hay demasiada incertidumbre, variables e información que no se conoce. Aquí es donde Scrum proporciona un enfoque adecuado, ya que está fundado en el empirismo o teoría de control empírico de procesos, lo que significa que el conocimiento procede de la experiencia y toma de decisiones basadas en lo que es conocido. Scrum utiliza una aproximación iterativa e incremental para generar incrementos de producto y obtener retroalimentación lo más rápido posible. Esto apenas ha sido la primera aproximación a lo que es Scrum, en futuras entradas a este blog hablaremos mucho más sobre este marco de trabajo. ###Conclusiones Scrum no es ninguna metodología, es un marco de trabajo ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos. Scrum y agilidad no son lo mismo, Scrum es, de hecho, una forma de ser Ágil o Agile, pero existen distintos marcos o métodos que permiten habilitar la agilidad dentro de un equipo u organización. Finalmente, Scrum consiste en roles, eventos y artefactos. Se basa en el control empírico de procesos, y permite construir incrementos de producto de manera iterativa para obtener retroalimentación del cliente y usuario final lo más rápido posible.

19 de septiembre de 2021

El bloc de notas de un Agilista Jedi