---

Certificación Scrum Master económica: plan paso a paso

Nos enorgullece anunciar que este artículo apareció destacado...
AQUÍ, en LinkedIn >>>

Desde que el marco Scrum se convirtió en una de las mejores formas de desarrollar y entregar software, todo el mundo parece tener el mismo objetivo.

Despertarse por la mañana, abrir el portátil y sentir la ilusionante tranquilidad de contar con algo así:

Una certificación Scrum Master.

Ese es el sueño, ¿verdad?

Entregar un excelente software a tus empleadores y clientes.

Disfrutar de una carrera fantástica gracias a tus habilidades y conocimientos del proceso Scrum y a tu certificación Scrum Master.

Para la mayoría de las personas, la certificación Scrum Master es su punto de partida con el marco Scrum.

En este artículo quiero compartir por primera vez contigo una guía avanzada y detallada, paso a paso, para ayudarte a obtener tu certificación Scrum Master.

¡De forma económica, rápida, en línea y sin complicaciones!

En solo cuatro sencillos pasos puedes convertirte en un profesional destacado de Scrum con tu certificación Scrum Master.

Mi objetivo con este artículo es mostrarte cómo Scrum puede impulsar tu carrera y mejorar tu eficacia profesional. También quiero explicarte por qué te conviene seguir desarrollando cuanto antes las habilidades y capacidades de un Scrum Master.

Definición: ¿qué es la certificación Scrum Master?

Puedes encontrar la mejor definición de lo que certificación Scrum Master es en International Scrum Institute™, en su Scrum Master Accredited Certification™.

La certificación Scrum Master es la acreditación de tu competencia en el proceso Scrum de desarrollo y entrega de software. La certificación Scrum Master reconoce los conocimientos que has demostrado y tu destacada experiencia en el marco Scrum tras una evaluación formal mediante un examen de opción múltiple.

El proceso Scrum de desarrollo de software ha aportado enormes beneficios a millones de profesionales hasta hoy. Por eso, no hay razón para que no te unas a esas personas que han mejorado sus carreras y habilidades con ayuda del marco Scrum.

Si todavía tienes dudas, quiero asegurarte que ya no puedes imaginar una carrera en crecimiento sin una certificación Scrum Master, independientemente de tu función, cargo y experiencia en el ecosistema de tecnologías de la información (TI) .

Ni siquiera necesitas ser profesional de TI para comprender qué es Scrum, cómo funciona y obtener una certificación Scrum Master.

Sea cual sea tu profesión y formes parte o no de un departamento de TI, hay un hecho esencial e indiscutible: tus tareas y el valor profesional que aportas a tu organización dependen de las TI, del software y del proceso y los principios ágiles de Scrum.

Además, gracias a la transformación de los modelos de negocio tradicionales en negocios basados en software como servicio (SaaS) o al llamado movimiento de digitalización, obtener una certificación Scrum Master ya no es una decisión opcional para ningún profesional, dentro o fuera del departamento de TI. Hoy, contar con una certificación Scrum Master es una necesidad.

Puede que estés empezando tu carrera o que seas un profesional de TI con mucha experiencia. Da igual: necesitas obtener tu certificación Scrum Master.

Tu función puede incluir o no actividades de gestión de personas y áreas funcionales. Tampoco importa: sigues necesitando una certificación Scrum Master.

Puede que tengas un cargo como:

• analista de negocio,
• arquitecto de software,
• arquitecto empresarial,
• diseñador de software,
• diseñador de experiencia de usuario (UX),
• diseñador de interfaces de usuario (UI),
• desarrollador de software,
• responsable de desarrollo de software,
• ingeniero de pruebas,
• especialista en automatización de pruebas,
• responsable de pruebas,
• especialista en operaciones de sistemas de TI,
• administrador de Unix/Linux,
• ingeniero de seguridad de la información (InfoSec),
• ingeniero de redes de TI,
• administrador de bases de datos (DBA),
• director de proyectos,
• director de programas,
• responsable de producto,
• líder de equipo, gerente, director o ejecutivo,
• o cualquier otro cargo que no haya mencionado aquí.

Te conviene aprender el marco de desarrollo de software Scrum y convertirte hoy en Scrum Master obteniendo tu certificación Scrum Master.

3 elementos de caos y frustración antes del proceso ágil Scrum y las certificaciones Scrum Master

Para comprender mejor el impacto del marco Scrum en nuestras prácticas de ingeniería de software y nuestros negocios, conviene observar un día de trabajo habitual, o un proyecto de software real.

Por eso, me gustaría hablar brevemente de un proyecto de software del pasado, anterior a la adopción del marco Scrum de desarrollo y entrega de software en nuestras organizaciones.

Unos días antes de escribir estas líneas, almorcé con un antiguo compañero con quien trabajé hace casi 20 años. Marcus obtuvo sus certificaciones Scrum Master y Scrum Product Owner en International Scrum Institute™.

Actualmente trabaja como Scrum Master en una de las principales empresas de software del ámbito de la gestión ágil de proyectos.

Como Scrum Master, Marcus apoya ahora a un equipo ágil Scrum cuyos miembros están repartidos por distintas ubicaciones geográficas del mundo.

Durante el almuerzo, Marcus reconoció que los equipos ágiles Scrum distribuidos afrontan muchos retos habituales. Entre los problemas concretos que mencionó sobre la configuración de su proyecto de software estaban:

• Diferencias en los estilos de trabajo de los miembros del equipo Scrum,
• Diferencias horarias,
• Desajustes culturales y
• Limitaciones lingüísticas.

Pese a estas dificultades, Marcus añadió que gestionar un proyecto de software con el proceso ágil Scrum resulta más divertido, productivo y enriquecedor que nuestra forma de trabajar hace 20 años. Comparado con los días en que trabajábamos sin los procesos Scrum de desarrollo y entrega de software.

La afirmación de Marcus era, sin duda, un gran testimonio a favor del marco Scrum, procedente de un gerente, Scrum Master y Product Owner de amplia experiencia y trayectoria.

¡Gracias, Marcus!

Entonces le expliqué uno de mis antiguos proyectos de software, anterior a mi primer contacto con el marco Scrum. Estoy segura de que muchos Scrum Masters reconocerán esta experiencia en sus propios proyectos anteriores a la obtención de sus certificaciones Scrum Master.

A finales de la década de 1990, formaba parte de un grupo de ingeniería de software que desarrollaba un sistema basado en tarjetas inteligentes de infraestructura de clave públicabasada en tarjetas inteligentes. Estas protegían de forma segura las claves privadas de los miembros de la infraestructura; las claves públicas asociadas y los certificados que las contenían se distribuían abiertamente, como indica su nombre.

En aquella época, era de por sí un proyecto de TI relativamente complejo que requería varios equipos interdependientes de ingeniería de hardware y software. Tuvimos que realizar grandes esfuerzos de investigación y desarrollo (I+D) para construir un sistema de hardware y software plenamente funcional.

Recuerda que esto ocurrió antes de que contáramos con el producto mínimo viable (MVP) para experimentar, crear, aprender y volver a experimentar.

Si te interesa saber más sobre cómo crear un MVP con una metodología ágil, puedes consultar este artículo de Cleevio, que te dará una visión más completa de este complejo proceso.

Crear sin Scrum una infraestructura tan sofisticada, formada por numerosos componentes de hardware y software, era todo un reto.

Estos son tres grandes contratiempos que sufríamos al no contar en nuestros equipos con Scrum Masters ni con nadie que tuviera una certificación Scrum Master.

1.er elemento de caos y frustración sin certificación Scrum Master: teníamos que planificar todo el proyecto antes de comprender de qué trataba

Sin Scrum, nuestros equipos habían desarrollado y entregado productos de software y hardware completamente equivocados que no respondían a las necesidades del cliente.

En algunos momentos de nuestra vida profesional, empresas externas nos impusieron cómo debíamos desarrollar nuestros productos o servicios de software.

Modelo de madurez de capacidades (CMM), ISO 9001:2008 y otras variantes intentaban ayudar a nuestras empresas a garantizar que desarrolláramos el software adecuado de la manera adecuada.

Su grado de éxito queda fuera del alcance de este artículo. Este artículo pretende centrarse en el proceso Scrum y los méritos de una certificación Scrum Master, sin presentar las normas de gestión de calidad y mejora de procesos como alternativas extinguidas a Scrum.

No obstante, debo añadir que estos marcos de mejora de procesos, anteriores al marco Scrum de ingeniería de software, se implantaban en nuestros proyectos por fases. Utilizábamos un enfoque de ingeniería de software por fases que llamábamos el modelo de ingeniería de software en cascada.

Con el modelo en cascada, cada proyecto de software debía comenzar con el análisis de requisitos, en el que intentábamos comprender lo que el cliente necesitaba y deseaba.

Después diseñábamos esos requisitos, los implementábamos, los probábamos o verificábamos y los manteníamos en nuestros entornos de producción de software. Finalmente llegábamos al final del ciclo de vida de la ingeniería de software.

¡Sin embargo, la realidad era muy distinta!

Los efectos negativos de los retrasos imprevistos en una fase concreta del modelo en cascada afectaban inevitablemente a las fases posteriores de ingeniería de software.

Así era la vida antes del marco Scrum.

Enviar el software de un equipo a otro, sin la orientación de profesionales con certificaciones Scrum Master, volvía nuestro trabajo burocrático, complejo e improductivo.

Al final no solo sufría el producto: la motivación de los empleados y su compromiso con la misión de la organización quedaban completamente dañados.

2.º elemento de caos y frustración sin certificación Scrum Master: falta de compromiso, gestión del cambio y disciplina de colaboración entre equipos

La mayor debilidad de los marcos de mejora de procesos utilizados antes de Scrum era que: Se centraban principalmente en las exigencias organizativas de una dirección que velaba por sus propios intereses.

Entre estas exigencias estaban la supervisión, el cumplimiento y la previsibilidad. No se prestaba ninguna atención a atender bien a los clientes ni a mejorar la motivación de los empleados.

Así, los equipos directivos de software y otras partes interesadas internas y externas intentaban fijar plazos inamovibles para los proyectos y supervisar fácilmente el progreso de las fases de ingeniería de software.

Penalizaban a las personas cuando algo se desviaba del plan y esperaban resolver los problemas emergentes antes de la fecha prevista de finalización.

Además, silos independientes realizaban fases de ingeniería de software totalmente separadas. Por ejemplo, el equipo de desarrollo era completamente independiente del equipo de pruebas o verificación. La mayoría de las personas que supuestamente trabajaban por la misma misión empresarial ni siquiera se conocían por su nombre.

¿Imaginas por qué nuestras organizaciones tenían esta mentalidad de silos en vez de centrarse en la misión empresarial y la madurez profesional de los empleados?

La razón es simplemente la gestión matricial. La gestión matricial es una estructura de organización y gestión de empleados presente en las empresas desde la década de 1970. A primera vista, la idea que distingue a una organización matricial parece inteligente.

La dirección creaba una estructura organizativa agrupando a los empleados con habilidades funcionales y técnicas similares en el mismo silo o, en el mejor de los casos, en silos vecinos.

En aquella época era muy habitual encontrar los llamados «centros de competencias» en nuestras empresas, cada uno de los cuales constituía un silo independiente y autónomo.

Un silo para desarrolladores de C++, otro para administradores de bases de datos, otro totalmente separado para aseguramiento de la calidad en otro país, y así sucesivamente. ¡Imagínatelo!

El mayor reto de la estructura organizativa matricial era el siguiente: para entregar un proyecto de software sin el marco Scrum ni Scrum Masters, los directores de proyecto tenían que tomar prestados temporalmente empleados de los silos.

Estos empleados ni siquiera se ubicaban físicamente con sus equipos de proyecto, sino que permanecían en las salas de sus respectivos centros de competencias.

Al terminar los proyectos, esos equipos temporales se disolvían y sus participantes pasaban a sus siguientes tareas en otros proyectos.

Por tanto, el valor empresarial que buscaban esos proyectos de software nunca era la máxima prioridad de los silos independientes.

Solían ver su trabajo como casillas que marcaban en un proyecto y en otro.

La dirección y el modelo matricial no les enseñaban cómo comprometer su trabajo profesional con la mejora de los resultados del negocio, incluidas las ventas, los ingresos y los beneficios.

Un artículo de McKinsey Quarterly, escrito por McKinsey & Company, también ilustró claramente esta ilusión de optimización de costes más allá de la organización matricial.

El artículo original cita una estimación de Gartner sobre el volumen anual mundial de gastando anualmente 600 mil millones de USD en recuperar sus sistemas de TI tras trabajos de mantenimiento no programados y defectos.

Ahora dediquemos un momento a imaginar cómo se desarrollaban la gestión del cambio y la resolución de impedimentos en los proyectos de software. Cómo se desarrollaban en un proyecto con el modelo en cascada, con una organización matricial y sin el proceso Scrum.

Sí. Tienes razón. La dirección y los empleados trataban la gestión del cambio, los impedimentos y la resolución de errores como excepciones indeseables que nunca deberían haberse producido.

Por tanto, los cambios en un proyecto de software se habían convertido en sinónimo de retrasos. Solían crear un efecto dominó de retrasos en cadena. Los equipos necesitaban a alguien a quien culpar y señalar por los defectos y los impedimentos.

Por último, como los silos carecían de un mecanismo para procesar, corregir y aprender de sus errores, seguían repitiéndolos.

Además, seguían aumentando la cantidad de deuda técnica mientras intentaban afrontar pasivamente sus problemas.

3.er elemento de caos y frustración sin certificación Scrum Master: las decisiones autocráticas anulaban las decisiones democráticas

Steve Jobs dijo una vez:

«No tiene sentido contratar a personas inteligentes y decirles lo que tienen que hacer. Las contratamos para que ellas nos digan lo que tenemos que hacer».

Sin embargo, esto es justo lo contrario de cómo solía tomar decisiones la mayor parte de la dirección antes de la era Scrum.

Antes de incorporar el proceso Scrum a nuestras organizaciones, las decisiones autocráticas de los líderes prevalecían sobre la inteligencia colectiva de sus equipos.

Anulaban la capacidad de tomar decisiones democráticas de los grupos responsables de realizar el trabajo real que abarcaba todo el ciclo de vida de la ingeniería de software, desde la concepción hasta la operación.

Cuanto más se alejaba una decisión de los centros de trabajo o equipos afectados, más difícil resultaba tomar una decisión correcta y crucial para la misión.

Las decisiones de los líderes solían ser impulsivas, poco meditadas, mayoritariamente tardías y provisionales, aunque a veces incluso demasiado tempranas.

Estas decisiones autocráticas impuestas desde arriba hacían que los empleados se sintieran infravalorados. Obstaculizaban por completo la capacidad de la organización para crear soluciones innovadoras ante los retos competitivos del negocio y del software.

Además, desalentaban a los equipos de ingeniería de software a dar su opinión cuando se les pedía contribuir a las decisiones.

Este ha sido un breve repaso de cómo desarrollábamos y entregábamos nuestros servicios y productos de software antes de adoptar el marco Scrum en nuestras organizaciones. Veamos ahora cómo resolvimos esos elementos de caos y frustración con ayuda del proceso Scrum.

¿Qué es Scrum?

En primer lugar, quiero destacar que no pretendía convertir esta sección del artículo en una referencia que respondiera a todas las preguntas sobre el marco Scrum. Aun así, el contenido que estamos tratando ofrecerá una base sólida a la mayoría de los profesionales de Scrum de nivel inicial e intermedio.

Para quienes buscan una guía más avanzada, pero igualmente práctica, con la que aprender rápidamente el marco Scrum, también tenemos algo. Te sugiero que vayas y descargues nuestra guía del marco Scrum desde este enlace.

¿Qué es Scrum? Sin complicarlo demasiado, el marco Scrum puede definirse así:

Scrum es un marco ligero para generar valor mediante soluciones adaptativas a problemas complejos. El desarrollo iterativo e incremental de software es una de sus aplicaciones importantes.

Aunque el software es uno de los principales ámbitos de aplicación del marco Scrum, el proceso iterativo y ágil de Scrum puede aplicarse, y ya se aplica, fuera del sector del software.

Muchas personas del sector de TI creen que el término «Scrum» se acuñó a principios de la década de 2000, en paralelo al surgimiento de las tendencias ágiles de desarrollo y entrega de software. ¡Esa información es incorrecta!

El artículo publicado en enero de 1986 en Harvard Business Review describía un enfoque de desarrollo de productos anterior al posterior marco Scrum. Hirotaka Takeuchi e Ikujiro Nonaka escribieron el artículo The New New Product Development Game. (Sí, con dos «New»)

Te recomiendo consultar «The New New Product Development Game» para descubrir cómo empezó todo lo relacionado con Scrum.

Cuando en el sector de TI hablamos del marco Scrum, también oímos a menudo el término «Agile Scrum» junto a «Scrum». Esto llevó a algunos profesionales a pensar que existían diferencias entre «Agile Scrum» y «Scrum» y a buscarlas.

Tengo buenas noticias para ti: «Agile Scrum» y «Scrum» se refieren a lo mismo. Ambos aluden al proceso Scrum de ingeniería de software. Entonces, ¿por qué a veces utilizamos «Agile» delante de «Scrum»?

Porque el marco Scrum adoptó e incorporó plenamente el Manifiesto Ágil (Manifiesto por el Desarrollo Ágil de Software) en su proceso central, sus principios y su filosofía. Por eso conviene comprender mejor el Manifiesto Ágil y los valores del proceso Scrum antes de profundizar en sus aspectos técnicos.

El Manifiesto Ágil (Manifiesto por el Desarrollo Ágil de Software)

Valores del Manifiesto Ágil:

• Individuos e interacciones sobre procesos y herramientas,
• Software funcionando sobre documentación exhaustiva,
• Colaboración con el cliente sobre negociación contractual,
• Respuesta ante el cambio sobre el seguimiento de un plan.

Aunque los elementos de la derecha siguen teniendo un valor importante, el Manifiesto Ágil aprecia y prioriza más los de la izquierda.

Los elementos que favorece el Manifiesto Ágil se han elegido y probado cuidadosamente con el tiempo para:

• Atender mejor a los clientes y a las partes interesadas, y crear valor para ellos mediante el software,
• Mejorar la profesión de ingeniería de software, sea cual sea tu función, cargo o nivel profesional.

Valores del marco Scrum

Ya he mencionado que el marco Scrum no es solo un proceso de ingeniería de software. También cuenta con un sólido conjunto de principios subyacentes.

De hecho, la mayoría de los ámbitos profesionales pueden aplicarlos y utilizarlos.

Obtener una certificación Scrum Master no basta para alcanzar un gran éxito con Scrum. Para conseguirlo, necesitas comprender bien sus valores.

para realizar un gran trabajo y entregar software fantástico que encante a tus clientes y empleadores. Permíteme explicarte ahora estos principios del proceso Scrum.

Valentía

Hay momentos en que hacer lo correcto para aportar el máximo valor y beneficio a nuestros clientes no es lo más sencillo. En esos momentos, el Scrum Master, la Product Owner y los miembros del equipo Scrum deben recordar su deber y su responsabilidad.

Consiste en desarrollar los mejores productos y servicios posibles en su ámbito empresarial y tecnológico. Para superar la mediocridad, un equipo Scrum tarde o temprano afrontará decisiones difíciles que no harán felices a todas las personas de su entorno de partes interesadas.

Para afrontarlo, todos los miembros del equipo Scrum deben recordar lo que aprendieron durante su formación para la certificación Scrum Master.

Deben recordar la importancia de la valentía y aprender a decidir y actuar con ella.

Enfoque

En el marco Scrum, cuando oigas hablar del valor del enfoque, piensa en dos cosas:

• Identificar el trabajo adecuado: ¿Qué tareas son necesarias para alcanzar los objetivos de mi Sprint? ¿Cuáles son esenciales para desarrollar los mejores productos y servicios de software para mis clientes, de modo que estén satisfechos con mi trabajo?
• Priorizar: ¿En qué tareas debo trabajar a continuación?

En todo momento hay una pregunta crucial que debe responder todo el equipo Scrum, incluidos el Scrum Master y la Product Owner. La pregunta es: «¿Qué es lo más importante que debemos hacer ahora para cumplir los motivos por los que nuestro empleador nos contrató?»

El marco Scrum incorpora varios eventos para facilitar una priorización razonable de las historias de usuario y las tareas. Según el proceso Scrum, priorizar las historias de usuario y sus tareas asociadas debe ser una prioridad continua.

Así nos aseguramos de que el equipo Scrum trabaje en lo adecuado y en el orden correcto. Los eventos formales de Scrum y las prácticas de refinamiento relacionadas nos ayudan a inspeccionar nuestro enfoque y adaptar el trabajo:

• Reunión de refinamiento de Scrum: El refinamiento aclara, divide y dimensiona los próximos elementos del Product Backlog, además de aportar información para ordenarlos. Una reunión es una opción para realizar esta actividad continua.
• Sprint Planning: Estas reuniones muestran las dependencias y el orden correcto para entregar las historias.
• Daily Scrum: La Daily Scrum o reunión diaria de pie nos ayuda a orientar la siguiente jornada de trabajo. Debemos dirigir nuestra atención hacia donde más se necesita.
• Sprint Review: La Sprint Review nos muestra indirectamente hacia dónde debe dirigir sus esfuerzos el equipo Scrum para que las siguientes revisiones sean más satisfactorias.
• Sprint Retrospective: Estas reuniones ayudan al equipo Scrum a priorizar qué aspectos de su proceso de ingeniería conviene mejorar primero.

En esta sección he tratado los eventos de Scrum únicamente desde la perspectiva del enfoque. Encontrarás una explicación más detallada de las ceremonias de Scrum más adelante en este artículo.

Después de leer todo esto, ya debe estar claro lo esenciales que son la priorización y el enfoque para el marco Scrum.

Compromiso

Sin el compromiso del Scrum Master, la Product Owner y el equipo Scrum, no es posible entregar resultados extraordinarios con el software.

En el mundo del proceso Scrum de desarrollo de software, muchas personas interpretan el valor del compromiso como el acuerdo y la delimitación de los objetivos de las entregas previstas para un Sprint.

Aunque tiene sentido, esa comprensión no es perfecta. Cuando oigas la palabra «compromiso» en el contexto de los valores de Scrum, ten en cuenta que la autora utiliza «obsesión» para enfatizar la dedicación. En la definición de Scrum, el compromiso se refiere a los objetivos del equipo y al apoyo mutuo; no exige trabajar en exceso ni tener certeza sobre cada elemento previsto.

Para tener éxito en la ingeniería de software, en la vida y en los negocios, debes dedicarte intensamente a tus objetivos. Por eso, en el contexto del proceso Scrum, debes dedicarte intensamente a crear software extraordinario que resuelva los problemas de tus clientes.

¿Por qué son tan importantes el compromiso y esa intensa dedicación a los objetivos de Scrum? Porque, sin la dedicación a la misión de desarrollar y entregar un software extraordinario, cada impedimento de cierta importancia que encuentre el equipo Scrum ralentizará y detendrá su trabajo.

Entonces, el Scrum Master y el equipo Scrum comenzarán a elaborar explicaciones para justificar ante la Product Owner por qué no pueden alcanzar los objetivos del Sprint. Las excusas no deben tener cabida en tu equipo si aspiras a superar el nivel de un equipo Scrum promedio.

Solo con un nivel de dedicación extraordinariamente alto resulta relativamente más fácil y satisfactorio resolver los problemas de nuestros clientes, ayudarlos y crear valor para ellos mediante el software.

Respeto

Independientemente de la edad, el género, la raza, las creencias, la experiencia, la competencia, las opiniones y el rendimiento laboral, todos los miembros de un equipo Scrum deben respetarse y confiar entre sí.

Ese respeto no se limita al equipo Scrum. Además, el equipo respeta plenamente y recibe con agrado a cualquier parte interesada interna o externa, de TI o del negocio, con la que interactúe.

Los miembros con más experiencia deben procurar no anular la disposición a contribuir de quienes tienen menos experiencia.

Es especialmente importante acoger y responder adecuadamente a las opiniones contrarias con las que no está de acuerdo la mayoría del grupo.

Apertura

El valor de la apertura suele ser una de las principales diferencias entre un equipo Scrum promedio y uno de alto rendimiento. Puedes comparar la apertura de un equipo Scrum con la gran capacidad de un grupo de personas de mente abierta.

Son creativas, innovadoras, intelectualmente inquietas, honestas, directas y humildes. En el proceso Scrum de ingeniería y entrega de software, las personas deben poder hablar abiertamente de los retos y de sus diferentes puntos de vista. La apertura no convierte en adecuada cualquier decisión o acción: el respeto, la calidad y los objetivos del equipo siguen siendo importantes.

La única condición es actuar con transparencia y tratar de contribuir a la misión común del equipo Scrum.

Esto no significa que cada decisión y acción deba acelerar necesariamente la producción del equipo Scrum y dar lugar a grandes casos de éxito.

Gracias a los valores de apertura y valentía, el grupo Scrum de desarrollo de software no teme cometer errores. Considera los errores y los resultados mejorables oportunidades esenciales para aumentar significativamente la productividad y calidad.

Componentes principales del marco Scrum

El equipo Scrum está formado por una Product Owner, un Scrum Master y Developers, con tres responsabilidades diferenciadas. La expresión anterior del artículo «miembro del equipo Scrum» se refiere al grupo de desarrollo, no a una cuarta responsabilidad ni a otro equipo Scrum completo.

Además de otros programas que ofrece a estudiantes de todo el mundo, International Scrum Institute™ ofrece tres programas principales de formación y certificación para estas tres responsabilidades.

Estos programas son Scrum Master Accredited Certification™ (SMAC™), Scrum Product Owner Accredited Certification™ (SPOAC™), y Scrum Team Member Accredited Certification™ (STMAC™).

Una organización Scrum adecuada debe contar con personas con estos tres conjuntos de habilidades. Esto es especialmente importante para tener éxito con el marco Scrum de desarrollo de software.

Deben cumplirse todas las responsabilidades de Scrum. Sus funciones siguen siendo distintas; una Product Owner o un Scrum Master también pueden contribuir como Developers al trabajar en elementos del Sprint Backlog, sin perder las responsabilidades de su otro cometido.

Varios equipos Scrum que trabajan en un mismo producto comparten una Product Owner, un Product Goal y un Product Backlog. Cada equipo cuenta con la responsabilidad de Scrum Master y necesita apoyo eficaz; Scrum no establece que una persona solo pueda apoyar a un equipo.

No subestimes la importancia de comprender el propósito y la función de estas responsabilidades y de asignarlas a personas con las capacidades adecuadas. Hemos observado muchas veces que las dificultades de un equipo Scrum se deben a que estas funciones no se comprenden o no las desempeñan las personas adecuadas.

Hablemos ahora de estas tres responsabilidades.

Tres responsabilidades de Scrum: la Product Owner

La Product Owner de Scrum ordena el Product Backlog para maximizar el valor del producto y colabora con las partes interesadas en las decisiones sobre el producto y sus lanzamientos. Los Developers seleccionan el trabajo que prevén completar en un Sprint; los acuerdos de lanzamiento dependen del contexto del producto. Representa las necesidades funcionales y no funcionales de los usuarios finales.

Su función es mucho más amplia que las funciones tradicionales de dirección de proyectos, dirección de programas o gestión de productos.

Esta función combina tareas de gestión de productos y proyectos y se integra estrechamente con el desarrollo y la entrega de software.

Las tareas esenciales de una Product Owner de Scrum son:

• Gestionar y aclarar los requisitos del proyecto,
• Orientar los lanzamientos y garantizar el retorno de la inversión (ROI),
• Colaborar estrechamente con el equipo Scrum,
• Gestionar las relaciones con las partes interesadas.

Tres responsabilidades de Scrum: los miembros del equipo de desarrollo

El equipo Scrum implementa el software. Los Developers seleccionan cuánto trabajo prevén poder completar durante un Sprint. El Sprint es un evento de duración fija; el resultado de producto utilizable que se crea durante él es un incremento que cumple la Definition of Done.

Un equipo Scrum de alto rendimiento suele reunir la mayoría de las habilidades de ingeniería de software. Desarrolladores, arquitectos, especialistas en pruebas, administradores de bases de datos y miembros con otras funciones trabajan juntos.

Juntos construyen y entregan el excelente software por el que paga su cliente.

Los miembros del equipo Scrum ya no pertenecen al silo funcional de una organización matricial. Los desarrolladores ya no pertenecen a centros de competencias de desarrollo de software, los especialistas en pruebas ya no pertenecen al centro de competencias de pruebas, y así sucesivamente.

Independientemente de su posición anterior en la organización, los miembros del equipo Scrum pertenecen a su proyecto Scrum concreto. Su trabajo consiste ahora en desarrollar el mejor software posible para satisfacer los requisitos de su Product Owner.

Los equipos Scrum se caracterizan por ser:

• Facultados para decidir,
• Autónomos,
• Multifuncionales,
• Autoorganizados,
• Pequeños,
• Formados por participantes con disponibilidad suficiente (la dedicación a tiempo completo es una opción organizativa habitual),
• Capaces de colaborar estrechamente, tanto si comparten ubicación como si están distribuidos,
• Uno para todos y todos para uno.

Tres responsabilidades de Scrum: el Scrum Master

El Scrum Master ayuda a todos los participantes de un proyecto Scrum y a las partes interesadas externas a comprender y aplicar correctamente el marco Scrum. Apoya al equipo Scrum para que ejecute el proceso con éxito y contribuya a mejorar continuamente su productividad y rendimiento.

La función del Scrum Master es establecer el proceso Scrum y una nueva forma de pensar y actuar.

Además, el Scrum Master actúa como agente de cambio. Acompaña al equipo para desarrollar nuevas normas y criterios de trabajo. Se mantiene accesible para el equipo; la proximidad física puede ayudar, pero no es un requisito de Scrum.

Entre las responsabilidades esenciales del Scrum Master están:

• Establecer Scrum en su entorno empresarial y de TI,
• Acompañar al equipo para que comprenda y viva los valores de Scrum,
• Facilitar una colaboración estrecha entre la Product Owner y el equipo Scrum,
• Eliminar impedimentos,
• Liderar mediante el servicio,
• Apoyar la eficacia de los eventos de Scrum y facilitarlos cuando sea necesario, manteniendo la responsabilidad de los Developers sobre la Daily Scrum.

Product Backlog de Scrum

El Product Backlog de Scrum es el elemento central para gestionar todos los requisitos conocidos de un proyecto Scrum.

Contiene todos los requisitos del cliente y elementos de trabajo necesarios para ejecutar y completar un proyecto con éxito. Los requisitos incluyen tanto los funcionales como los no funcionales y otras características relacionadas con la experiencia de usuario y interfaz de usuario y el diseño.

El Product Backlog contiene solicitudes de funcionalidades y sus historias de usuariode alto nivel. También puede incluir requisitos previos o complementarios del proyecto, como crear entornos de pruebas y desarrollo. Asimismo, el Product Backlog recoge otras historias de usuario necesarias para resolver errores conocidos, reducir la deuda técnica o mejorar determinadas funcionalidades del software.

Cada producto tiene su Product Backlog. La Product Owner de Scrum es responsable de crearlo, mantenerlo y ajustarlo. El Product Backlog no responde ni debe responder a cómo se desarrollarán y entregarán esos requisitos.

Eso corresponde al equipo Scrum. El equipo decide y documenta en los Sprint Backlogs las tareas necesarias para abordar esos requisitos. Ten en cuenta que el Product Backlog y el Sprint Backlog son artefactos distintos, pero no necesariamente documentos o herramientas físicamente separados, aunque los elementos del Product Backlog determinan el contenido del Sprint Backlog.

El Product Backlog es un documento vivo. Del mismo modo que el software mejora de forma incremental, el Product Backlog cambia a medida que el equipo aprende: se añaden, eliminan y reordenan elementos. El marco Scrum no exige en sí mismo un proceso independiente de gestión del cambio. La Product Owner crea las primeras versiones del Product Backlog a partir de su mejor comprensión inicial del producto.

Mientras observa de cerca cómo evoluciona el producto de un Sprint a otro y amplía sus conocimientos sobre los requisitos del cliente, añade, elimina y ajusta requisitos en el Product Backlog.

La Product Owner de Scrum prioriza los requisitos del Product Backlog. Cuanta más prioridad tiene un elemento del Product Backlog, más detalles debe contener. Así, el equipo Scrum puede comprender fácilmente esos requisitos prioritarios y crear las tareas necesarias para desarrollarlos.

Además, mediante un enfoque de estimación como los puntos de historia, el equipo Scrum estima periódicamente los requisitos del Product Backlog. Estas estimaciones deben ajustarse y mejorarse en las historias de usuario prioritarias para prepararlas para la Sprint Planning.

Los Sprints

En el marco Scrum, todas las actividades para implementar los requisitos se realizan durante los Sprints. Los Sprints son ciclos de trabajo para desarrollar incrementos entregables de productos o servicios de software. Los Sprints también se denominan a veces iteraciones.

Puedes considerar los Sprints como microproyectos. Como sugiere el término «Sprint», su duración no es larga: un mes o menos. Los Sprints de cuatro semanas son un ejemplo habitual, no el máximo exacto de duración en el calendario que establece el marco.

A diferencia de una carrera, al terminar un Sprint el equipo Scrum no debe estar sin aliento ni energía. Debe mantenerse fresco y comenzar el siguiente Sprint con energía.

El marco Scrum de desarrollo y entrega de software no busca generar presión ni estrés entre los miembros del equipo. Es bien sabido que las personas rinden mejor cuando pueden trabajar concentradas, tranquilas y sin distracciones. Bien aplicados, los Sprints nos ayudan a conseguirlo.

Cada Sprint comienza con una Reunión de planificación del Sprint. Durante la Sprint Planning, el equipo Scrum decide cuáles y cuántos requisitos implementará en ese Sprint. A continuación, comienza a ejecutar las actividades necesarias para entregar esos requisitos.

Daily Scrum o reunión diaria de Scrum se celebra todos los días laborables del Sprint, a la misma hora y en el mismo lugar. Los Developers la utilizan para inspeccionar el progreso hacia el Sprint Goal y adaptar su plan para el día siguiente. Los miembros del equipo Scrum también pueden pedir ayuda al Scrum Master para eliminar impedimentos que puedan ralentizar o bloquear el progreso del Sprint.

El equipo Scrum termina el Sprint con las reuniones de Sprint Review y Sprint Retrospective. La reunión de Sprint Review permite al equipo Scrum y a las principales partes interesadas inspeccionar el resultado del Sprint y el progreso hacia el Product Goal, y debatir después posibles adaptaciones. Es una sesión de trabajo, no un punto de aprobación de la Product Owner.

Durante la Reunión de Retrospectiva del Sprint, el equipo Scrum reflexiona sobre su forma de colaborar, cómo utiliza el marco Scrum y cómo puede mejorar.

Así, el equipo Scrum tiene en cuenta conjuntamente estas posibilidades de mejora y los comentarios recibidos durante la siguiente Sprint Planning. Los Sprints permiten crear estos ciclos de respuesta en periodos cortos y con pequeños lotes de trabajo. Esta es una de las razones importantes por las que Scrum ayuda a los equipos y organizaciones a mejorar continuamente.

Inspeccionar y adaptar en Scrum

Inspeccionar y adaptar en Scrum es un concepto fácil de comprender, pero muy difícil de aplicar correctamente y dominar.

Las empresas acabaron constatando que ninguno de sus directores de proyecto podía prever por completo la situación global de los sistemas complejos. No lograban planificar de forma fiable de principio a fin. Era evidente que necesitaban probar algo distinto.

Junto con la producción ajustada (también conocida como movimiento lean), las empresas necesitaban desarrollar un proceso que las fortaleciera estratégicamente. Necesitaban un procedimiento operativo estándar que les ayudara a aprender y corregir su rumbo mientras ejecutaban sus proyectos e incluso sus operaciones.

Así nació el kata de mejora de Toyota, que permite establecer una comparación útil con la inspección y la adaptación en Scrum. Estos enfoques de mejora comparten propósitos, pero el kata de mejora de Toyota no es simplemente otro nombre para los pilares empíricos de Scrum. Según «Inspeccionar y adaptar en Scrum»:

• Paso 1. Inspeccionar: Nos esforzamos por comprender el estado actual del proyecto a partir de los conocimientos y la comprensión que tenemos en ese momento.
• Paso 2. Adaptar: Definimos una dirección y una visión de los próximos pasos del proyecto y, después, planificamos y ejecutamos esa visión.
• Paso 3. Aprender: Observamos con atención, aprendemos y nos enseñamos mutuamente mientras avanzamos. Registramos continuamente lo que funciona y lo que no durante el trabajo.
• Paso 4. Reiniciar: Volver a comenzar desde el paso 1.

Ten en cuenta que los cuatro pasos siguientes son una analogía didáctica, no una definición que se corresponda exactamente con los eventos de Scrum. La inspección, la adaptación y el aprendizaje se producen a lo largo de todo el Sprint.

• Paso 1. Inspeccionar es comparable a las reuniones de Sprint Review y Sprint Retrospective.
• Paso 2. Adaptar es comparable a la Sprint Planning.
• Paso 3. Aprender es comparable a la Daily Scrum.
• Paso 4. Reiniciar es comparable al cierre de un Sprint y al comienzo de uno nuevo.

Autoorganización

El equipo Scrum se organiza por sí mismo. Sus miembros deciden por consenso las tareas necesarias para alcanzar los objetivos del Sprint. Un equipo autoorganizado no necesita un gerente ni un jefe de equipo.

La autoorganización en el marco Scrum requiere mucha disciplina.

Sprint Backlog y Reuniones Daily Scrum apoyan la autogestión. Un gráfico de trabajo pendiente del Sprint es una forma opcional de hacer visible el progreso.

Para la mayoría de los equipos, organizar su propio trabajo requiere una fase de aprendizaje. Los Scrum Masters competentes y certificados ayudan a sus equipos Scrum a dominar rápidamente la autoorganización.

La autoorganización también incluye la capacidad de colaborar pese a las opiniones distintas y los posibles conflictos entre los miembros del equipo Scrum. Exige respetar los procesos conjuntos de toma de decisiones y confiar en ellos.

Estos procesos de toma de decisiones del marco Scrum incluyen, entre otros, planificar, estimar, implementar, informar y revisar el trabajo del que el equipo Scrum es responsable conjuntamente.

Eventos de Scrum y refinamiento continuo del Product Backlog

Evento de Scrum 1. Sprint Planning: por qué, qué y cómo

Durante la Reunión de planificación del Sprint, el equipo Scrum elabora un Sprint Backlog viable que determina los requisitos que implementará durante el Sprint.

Las responsabilidades de las distintas funciones de Scrum durante la Sprint Planning son las siguientes:

• La Product Owner propone por qué el Sprint podría aportar valor. Todo el equipo Scrum colabora en un Sprint Goal y los Developers seleccionan los elementos del Product Backlog que prevén poder completar.
• El equipo Scrum identifica las tareas necesarias y sus estimaciones. Los Developers deciden cuáles y cuántos elementos prevén completar en el Sprint, teniendo en cuenta el rendimiento anterior, la capacidad y la Definition of Done.
• La Scrum Master modera la reunión. Se asegura de que el equipo Scrum mantenga su autoorganización y su capacidad para tomar decisiones autónomas.

Durante la Sprint Planning, la presencia de la Product Owner de Scrum es obligatoria. Así puede responder a las preguntas del equipo Scrum y aclarar los requisitos y sus criterios de aceptación.

El equipo Scrum puede invitar a otras personas, como usuarios finales o responsables, para que aporten asesoramiento durante la Sprint Planning. Las personas invitadas asesoran sin asumir las decisiones de los Developers sobre cómo realizar el trabajo.

Evento de Scrum 2. Daily Scrum o reunión diaria de pie

El Daily Scrum es una reunión de 15 minutos como máximo. Se celebra todos los días laborables, a la misma hora y en el mismo lugar. Conviene realizarla con acceso directo al Sprint Backlog y al gráfico de trabajo pendiente del Sprint. Así, el equipo Scrum puede orientar la Daily Scrum a partir de hechos y avances visibles para todos sus miembros.

La Daily Scrum busca apoyar la autoorganización del equipo Scrum e identificar los impedimentos de forma sistemática.

La Daily Scrum es para los Developers. Una Product Owner o Scrum Master que trabaje en elementos del Sprint Backlog participa como Developer. Cualquier otra modalidad de participación debe mantener la concentración y la autogestión de los Developers; Scrum no exige que asistan todas las funciones ni todas las partes interesadas.

Los Developers eligen una estructura útil, centrada en el Sprint Goal y en un plan de acción. Las tres preguntas siguientes son un formato opcional conocido, no preguntas prescritas por la versión actual de Scrum.

• Daily Scrum: pregunta n.º 1. ¿Qué actividades he realizado desde la última Daily Scrum?
• Daily Scrum: pregunta n.º 2. ¿Qué actividades tengo previsto realizar hasta la próxima Daily Scrum? ¿Cuál es mi plan de acción?
• Daily Scrum: pregunta n.º 3. ¿He encontrado o preveo algún impedimento que pueda ralentizar o bloquear el avance de mi trabajo?

Los Developers dirigen su Daily Scrum. El Scrum Master ayuda a los Developers a comprender su propósito y eficacia cuando es necesario. El evento sigue durando 15 minutos; el formato de tres preguntas es opcional.

El objetivo de la Daily Scrum no incluye tomar decisiones que requieran mucho tiempo ni resolver problemas. Para acordar decisiones y resolver problemas, el equipo Scrum puede organizar reuniones independientes cuando sean necesarias. Estas reuniones centradas en decisiones o problemas suelen celebrarse después de la Daily Scrum.

El Scrum Master documenta los impedimentos identificados y sus fechas en un registro, rotafolio o informe independiente al que el equipo tenga acceso. Me resulta muy útil actualizar brevemente el estado de los impedimentos pendientes al final de la Daily Scrum.

Evento de Scrum 3. Sprint Review

El Reunión de revisión del Sprint se celebra al final del Sprint. Una revisión de una o dos horas puede resultar adecuada para algunos equipos; el máximo formal es de cuatro horas para un Sprint de un mes, y suelen convenir eventos más breves para Sprints más cortos. Según el tipo de software y la infraestructura disponible, la Sprint Review se celebra en una sala de reuniones, en un laboratorio o en la sala del equipo Scrum.

El objetivo de la Sprint Review es revisar el incremento de producto entregable desarrollado durante el Sprint y aportar transparencia al proceso de desarrollo del producto.

El equipo Scrum muestra los resultados de su trabajo. El equipo Scrum y las partes interesadas comentan lo que se ha conseguido y lo que ha cambiado en el entorno. Inspeccionan los resultados y consideran los siguientes pasos; la revisión no es una comprobación del cumplimiento de una lista fija de tareas prometidas.

La Sprint Review permite al equipo Scrum y a las partes interesadas inspeccionar los resultados del producto y adaptar el Product Backlog. Posteriormente, todo el equipo Scrum colabora en el siguiente Sprint Goal. Por tanto, la Sprint Review es una aplicación formal y práctica de «inspeccionar y adaptar».

En la Sprint Review participan el equipo Scrum, la Product Owner y el Scrum Master. También pueden participar otras partes interesadas, como usuarios finales, clientes y representantes del negocio.

En la Sprint Review pueden compartir sus comentarios sobre el incremento de producto presentado. Así, el equipo Scrum tiene la oportunidad de recibir aportaciones directas y sin filtros de las partes interesadas para quienes desarrolla el software.

Evento de Scrum 4. Sprint Retrospective

El Reunión de Retrospectiva del Sprint sigue a la Sprint Review y concluye el Sprint. Su duración máxima es de tres horas para un Sprint de un mes; para Sprints más cortos, suele ser menor.

El objetivo de la Sprint Retrospective es mejorar la colaboración entre los miembros del equipo Scrum y la aplicación del proceso Scrum.

Por tanto, la Sprint Retrospective ayuda a aumentar la productividad, el rendimiento de los miembros del equipo y la calidad del software.

La Sprint Retrospective es, en la práctica, un pequeño análisis posterior para definir posibilidades de mejora y eliminar obstáculos relacionados con el proceso. Algunos ejemplos de posibilidades de mejora que observamos con frecuencia en nuestros proyectos son:

• Adoptar prácticas de desarrollo ágil de software, como programación extrema (XP) o desarrollo guiado por pruebas (TDD).
• Identificar nuevas normas y principios del equipo, o
• Aumentar la disponibilidad de la Product Owner de Scrum.

Sin excepción, el equipo Scrum celebra una Sprint Retrospective al final de cada Sprint. Solo así estas reuniones permiten al equipo Scrum adaptar y mejorar sistemáticamente el uso del proceso Scrum según las particularidades de su proyecto.

Práctica relacionada: refinamiento del Product Backlog

Scrum Las reuniones de refinamiento del Product Backlog buscan mantener actualizado el Product Backlog. Así, el Product Backlog refleja los mejores conocimientos y la comprensión del Scrum Team sobre el proyecto en curso.

El refinamiento puede realizarse cuando sea necesario o mediante conversaciones programadas. Dos sesiones semanales de 30 minutos son un ejemplo práctico, no una frecuencia obligatoria ni un límite máximo. La Product Owner y los Developers colaboran, con la participación del Scrum Master y otras personas cuando resulte útil.

Durante las reuniones de refinamiento del Product Backlog, los participantes lo ajustan mediante las siguientes acciones:

• Añadir historias de usuario basadas en requisitos recién descubiertos.
• Eliminar historias de usuario que el producto ya no necesita.
• Ajustar las estimaciones de las historias de usuario.
• Actualizar las prioridades de las historias de usuario.
• Dividir las historias enormes en otras menores y manejables, y priorizarlas adecuadamente.

Cuatro pasos sencillos para obtener tu certificación Scrum Master

Obtener tu certificación Scrum Master es muy sencillo, rápido y completamente en línea.

Gracias a International Scrum Institute™, ahora puedes certificarte como Scrum Master de forma más rápida y económica que nunca.

Estos son los cuatro pasos sencillos para obtener tu certificación Scrum Master sin perder tiempo ni dinero y sin complicaciones.

• Paso n.º 1. Inscríbete en línea

  Inscríbete en línea para tu certificación Scrum Master mediante la página de inscripción de Scrum Master Accredited Certification™.

  Tras tu inscripción, International Scrum Institute™ te proporcionará al instante tu código de acceso al examen en línea.

  Desde el siguiente enlace puedes inscribirte en tu programa de certificación Scrum Master.

• Abrir imagen a tamaño completo ↗

  Paso n.º 2. Estudia en línea

  Estudia en línea para tu certificación Scrum Master con tu guía de estudio de Scrum, El marco Scrum™.

  El marco Scrum™ está concebido con una orientación totalmente práctica. Su contenido te ayudará a afrontar los retos diarios de tu trabajo y tu carrera como Scrum Master competente. El marco Scrum™ está lleno de casos de estudio y ejemplos prácticos que muestran el día a día de los Scrum Masters de mayor éxito.

  Desde el siguiente enlace puedes Solicita tu ejemplar gratuito de El marco Scrum™.

• Paso n.º 3. Realiza tu examen de certificación Scrum Master en línea

  Después de leer, estudiar y asimilar con atención tu guía de estudio, El marco Scrum™, ¡ya deberías estar listo! Deberías sentir plena confianza para aprobar tu examen de certificación Scrum Master.

  Desde el siguiente enlace puedes Accede a tu examen de certificación Scrum Master.

• Paso n.º 4. Obtén tu certificación Scrum Master

  En cuanto apruebes el examen, te entregaremos inmediatamente tu certificación Scrum Master.

  Tus empleadores y clientes pueden comprobar la autenticidad de tu certificación mediante la herramienta de validación de certificaciones Scrum para empleadores. Desde el siguiente enlace puedes acceder a la herramienta de validación de certificaciones Scrum para empleadores.

Mi conclusión sobre la certificación Scrum Master

Ha llegado el momento de recapitular. Si no has podido leer cada palabra de esta guía paso a paso para convertirte en Scrum Master, permíteme resumir mis ideas. Estas son mis reflexiones sobre las ventajas y los inconvenientes de obtener una certificación Scrum Master.

Ventajas

Ventajas para empleados, profesionales independientes, coaches y formadores

• Una certificación Scrum Master reconocerá tu competencia y tus conocimientos actualizados en el ámbito de Scrum.
• Una certificación Scrum Master te ayudará a destacar frente a quienes han dejado de desarrollarse profesionalmente. Te ayudará a conseguir el trabajo de tus sueños como Scrum Master certificado y competente.
• Una certificación Scrum Master ampliará tu perspectiva y abrirá aún más tu mente al aprendizaje continuo. Te ayudará a asumir más responsabilidades y acceder a excelentes oportunidades profesionales.
• Una certificación Scrum Master te proporcionará un conjunto de herramientas completamente nuevo para entregar excelentes productos y servicios que encantarán a tus clientes y empleadores.

Ventajas para organizaciones y empleadores

• Las certificaciones Scrum Master reducirán los costes al mejorar la eficiencia de tus equipos, actividades y procesos.
• Las certificaciones Scrum Master te ayudarán a conseguir, con tus empleados formados y capacitados, proyectos que de otro modo no conseguirías.
• Las certificaciones Scrum Master mejorarán la satisfacción y el compromiso de los empleados al animarlos a formarse y desarrollar sus habilidades.
• Las certificaciones Scrum Master mejorarán la calidad de tus entregas, la satisfacción del cliente y, en última instancia, el éxito y la rentabilidad de tu organización.

Inconvenientes

• Una certificación Scrum Master no debe detener tu aprendizaje. No olvides que certificarte como Scrum Master es solo el primer paso.

  Siguiendo el espíritu de «inspeccionar y adaptar» que has aprendido del marco Scrum, sigue siendo tu deber y responsabilidad experimentar, observar y aprender continuamente.

• No existe una solución única válida para todas las organizaciones del mundo. El marco Scrum de desarrollo y entrega de software no es una excepción.

  Hemos observado que la mayoría de las organizaciones que no consiguen sacar el máximo rendimiento al marco Scrum comparten una característica: no han sabido adaptar Scrum a su propio entorno empresarial y de TI.

  Por tanto, de nuevo siguiendo el espíritu de «inspeccionar y adaptar», no consideres el marco Scrum una receta con el éxito garantizado al 100%. No subestimes tu capacidad de reflexión para adaptarlo a la dinámica de tu negocio y tus TI. De hecho, como profesional remunerado, eso es lo que debes hacer para obtener el mejor ritmo de entrega y los mejores resultados empresariales mediante el marco Scrum.

• Scrum no resolvió todos los problemas de nuestros departamentos de TI. Sigue desarrollándote con procesos emergentes de desarrollo y entrega de software, como DevOps.

  Para comprender mejor las limitaciones conocidas del marco Scrum y cómo las aborda DevOps, consulta más adelante este destacado artículo: ¿Cuáles son las 6 principales diferencias entre DevOps y Scrum?

En conclusión, una certificación Scrum Master es una excelente forma de iniciarse en las prácticas ágiles de desarrollo y entrega de software.

Según un estudio de Gartner «Cómo ser un mejor Scrum Master» publicado en 2019, el artículo preveía para 2023 que el 92% de las empresas del mundo y el 96% de las empresas de Estados Unidos adoptarían prácticas ágiles de Scrum. Esta es la previsión recogida en el artículo original, no una tasa de adopción actual medida.

Por tanto, no habrá mejor momento que ahora para

• Empieza a aprender gratis el marco Scrum y
• Obtén tu certificación Scrum Master con las tarifas muy asequibles de International Scrum Institute™.

La única pregunta pendiente es: ¿cuándo vas a empezar?