Si investigamos un poco sobre cómo gestionar nuestros proyectos de forma productiva y con la mayor efectividad posible, nos vamos a encontrar múltiples veces con Scrum. Esta metodología basada en la filosofía Agile no deja de crecer en popularidad, demostrando su capacidad para gestionar equipos en entornos dinámicos, alcanzando el éxito en industrias exigentes.

Pero, ¿qué es Scrum? Esa es una de las tantas preguntas que buscamos responder con esta guía actualizada al 2022. Otras de las preguntas que se responderán aquí son:

• ¿Cómo se implementa?
• ¿Quienes forman parte de Scrum?
• ¿Qué podemos lograr con su implementación?
• ¿Qué herramientas podemos utilizar para Scrum?
• ¿Cómo saber si nuestro proyecto se beneficiará de Scrum?
• ¿Cómo se compara Scrum con otras metodologías?
• ¿Cómo se pueden beneficiar nuestras carreras profesionales con una certificación Scrum?

Después de leer esta guía, es probable que consideres estas preguntas como respondidas. Sin esperar más, empecemos por el comienzo.

¿Qué es Scrum?

Scrum es una metodología específica para la gestión de proyectos que busca atacar problemas complejos al producir soluciones escaladas, creativas y eficientes.

El corazón de Scrum está en la eficiente gestión de los esfuerzos de los miembros del equipo y el constante aumento de la calidad del trabajo realizado. Los miembros de un Equipo Scrum pueden apreciar con mayor claridad, a través de la colaboración diaria, en dónde pueden mejorar y hacerlo de forma exponencial durante el desarrollo del proyecto.

Para el correcto funcionamiento de Scrum, debe existir un ciclo de trabajo repetitivo pero optimizable que consiste en:

1. El Scrum Master enseña la teoría de Scrum, sus reglas y mejores prácticas, y se asegura de que todos entiendan la metodología implementada sobre la marcha.
2. El Product Owner (Dueño del Producto) establece el plan de trabajo dentro del Product Backlog (Pila de Producto).
3. El Scrum Team (Equipo Scrum) toma las tareas disponibles en el Product Backlog y las convierte en Increments (Incrementos), lo cual representa producción de valor, durante un Sprint.
4. Acabado el Sprint, el Scrum Team y el resto de partes involucradas analizan los resultados producidos y ajustan lo necesario para conseguir un rendimiento superior durante el próximo Sprint.

Estos cuatro pasos deben repetirse cíclicamente, un proceso de repetición activa que maximizan el valor del producto.

Algunos datos breves pero importantes a tener en cuenta sobre Scrum hasta ahora:

• El Product Owner representa tanto a los intereses del cliente final como de los miembros de la organización.
• El Product Backlog organiza las tareas según orden de prioridad.
• Un Sprint tiene una duración entre una y cuatro semanas.
• Una vez al día, todos los miembros del proyecto deben reunirse por 15 minutos en la denominada Daily Scrum para inspeccionar el progreso con respecto a los objetivos del Sprint y asegurar que no existen obstáculos al actual trabajo, posiblemente ajustando el Sprint Backlog en el proceso.
• Cuando acaba el Sprint, todas las partes llevan acabo un Sprint Review para inspeccionar los resultados de forma colectiva.
• El Sprint Retrospective es el último evento antes de cerrar el Sprint activo, en donde se provee feedback constructivo para aumentar el rendimiento.
• La naturaleza del Sprint es repetitiva, lo que significa que un nuevo Sprint empieza al acabar el anterior.

---

Hagamos un inciso antes de continuar para hacer una aclaratoria fundamental.

Si has estado investigando antes sobre Scrum y otros métodos para la gestión de proyectos, puede que, además de muchos otros términos, te hayas encontrado con la metodología Agile.

¿Es Scrum y Agile lo mismo?

Como ya mencionamos, Scrum es una metodología específica para la gestión de proyectos, la cuál enseña un marco teórico y procesos estrictos, con la finalidad de conseguir progreso en un proyecto mientras el equipo mejora sus capacidades técnicas y de colaboración.

Algo que no hemos mencionado es que Scrum entra dentro del paraguas de métodos Agile. Más que una metodología, término utilizado habitualmente en este contexto, Agile es más una filosofía para la gestión de proyectos, un universo de ideas y valores correctamente estructurados que dan paso al nacimiento de metodologías más específicas como Scrum.

Una vez hayamos estudiado Scrum en detalle, dedicaremos algunas líneas a diferenciar Scrum de otros métodos de gestión de proyecto disponibles.

¿Son el Product Owner y el Scrum Master lo mismo?

Una pregunta habitual llegados a este punto es, “¿El Product Owner es lo mismo que el Scrum Master? ¿Puede ser la misma persona?”

La respuesta es: no. Trabajan juntos pero son profesionales distintos.

Los roles de estos dos profesionales son muy similares vistos desde afuera, tan similares que esta ilusión nos puede invitar a pensar que una sola persona podría cumplir con ambos roles.

Pero cuidado, no nos dejemos engañar. Esta es una peligrosa ilusión para cualquier empresa que quiera implementar Scrum. Y es que cuando un equipo intenta hacer esto, asignar ambos roles a una sola persona, el único resultado posible es negativo.

Entendamos estos roles en Scrum.

¿Qué es el Scrum Master?

Como hemos mencionado antes, el Scrum Master es responsable de que el equipo siga la metodología Scrum según la teoría lo indica. Es decir, se concentra en la teoría y en su correcta implementación. Pero que esto no haga pensar que está desconectado de la realidad práctica o que los equipos se pueden adaptar fuera de este marco teórico para conseguir mejores resultados.

Ese no es el caso. Scrum funciona muy buen cuando se sigue al pie de la letra, por eso el rol del Scrum Master es tan importante. También es cierto que el Scrum Master tiene una labor esencial en indicar al Product Owner cómo hacer el trabajo correctamente y sugerir correcciones de ser necesario.

Efectivamente, el Scrum Master debe hacerse responsable por la efectividad del equipo, pues en gran medida se determinará al seguir los lineamientos de la metodología Scrum.

En términos prácticos, así se ve el trabajo del Scrum Master en la vida real:

• El Scrum Master ayuda al equipo a orientarse correctamente, ayudando a que el trabajo realizado les acerque al Definition of Done (Criterio de Aceptación).
• El Scrum Master ofrece coaching a los miembros del equipo de desarrolladores con la frecuencia que sea necesaria, con la finalidad de que posean herramientas de auto-gestión y productividad.
• El Scrum Master trabaja directamente con el Product Owner para ayudarle a diseñar sistemas de trabajo para una correcta gestión del Product Backlog.
• El Scrum Master diseña a grande y pequeña escala la implementación de Scrum dentro de una organización y, durante, elimina las barreras de comunicación entre las partes interesadas a través de la educación y el entrenamiento.

¿Qué es el Product Owner?

Por otra parte, el Product Owner gestiona los esfuerzos del equipo de desarrollo a través del Product Backlog y Sprint Backlog, asegurándose así de que el Sprint produzca el máximo rendimiento posible al acabar.

Scrum busca crear tanto valor como sea posible. Este valor será provisto por el producto que nazca tras la finalización de cada Sprint y es el Product Owner el máximo responsable de ello. Este producto debe solucionar con efectividad el complejo problema que motiva la implementación de Scrum y debe aportar el máximo valor a la empresa y sus clientes.

Quizás ver al Product Owner en acción nos ayude a entender (y diferenciar) mejor su rol dentro de Scrum y en cada uno de los Sprints que se realicen. Aquí unos ejemplos prácticos:

• El Product Owner define desde cero el Product Goal (Producto Objetivo), la meta detallada a alcanzar durante cada Sprint y proyecto en general.
• El Product Owner gestiona todos las tareas que entran y salen del Product Backlog, incluyendo su orden.
• El Product Owner conecta el Product Backlog con el equipo de desarrolladores y comunica las información de forma clara y estructurada.

El Motor de Scrum: Equipo de desarrollo

El equipo de desarrollo, comúnmente referido como Developers, es el motor de esta metodología. Es un pilar fundamental de Scrum y son los desarrolladores los que ejecutan las tareas productivas que terminan produciendo soluciones.

Es importante aclarar que los tres miembros en Scrum (Scrum Master, Product Owner y Scrum Team) son de fundamental importancia y que no hay Scrum operativo en la ausencia de alguno de ellos. Dicho esto, así luce el trabajo del equipo de desarrollo en la vida real:

• Los desarrolladores diseñan el plan de trabajo para cada Sprint.
• Los desarolladores consideran el Definition of Done (Criterio de Aceptación) y determinan su viabilidad.
• Los desarrolladores ajustan, de forma diaria, el Sprint activo para conseguir mayores resultados progresivamente.

¿Qué son los Scrum Events?

Ahora que conocemos quienes forman parte de Scrum, quienes le dan vida a un proyecto que implemente esta metodología, repasemos los tipos de eventos que conforman la vida útil del proceso.

Normalmente referidos como Scrum Events (Eventos Scrum), son los diferentes eventos que ocurren durante el proyecto con la finalidad de inspeccionar el progreso hasta el momento y adaptar para mejorar los resultados.

Todos los Scrum Event ocurren dentro del Sprint activo. Según la teoría, no hay ningún evento que tome lugar fuera del marco de los Sprints, bien delimitados en el tiempo y por el trabajo que llevan a cabo los miembros del equipo.

Los diferentes Scrum Events son:

1. Sprint
2. Sprint Planning (Planificación del Sprint)
3. Daily Scrum (Scrum Diario)
4. Sprint Review (Revisión del Sprint)
5. Sprint Retrospective (Retrospectiva del Sprint)

Aunque diferentes en funcionamiento, todos los eventos buscan el mismo objetivo: alcanzar el Product Goal.

¿Qué es el Sprint en Scrum?

Empecemos por la mayor unidad: el Sprint.

Este evento contiene el resto de los eventos y establece una dimensión temporal muy útil para el equipo. Tiene una duración de entre una y cuatro semanas y posee una naturaleza cíclica, lo que significa que al acabar un Sprint inmediatamente comienza el siguiente.

La idea de limitar el Sprint a cuatro semanas es que hace infinitamente mas fácil el aprendizaje y progreso exponencial del proyecto. Los plazos más extensos generan un mayor riesgo de desconexión del equipo con el Product Goal y se vuelve más difícil valorar el rendimiento de forma objetiva.

De la misma forma, los Sprints más cortos promueven un mayor volumen de feedback y sesiones de aprendizaje mucho más frecuentes. Por este motivo, muchas organizaciones con la necesidad de crecer agresivamente, como las startups, utilizan Sprints cortos.

Entonces, una vez activo el Sprint, ¿qué ocurre?

¿Qué es Sprint Planning en Scrum?

Podemos decir que el Sprint Planning (Planificación del Sprint) es el evento fundamental del Sprint, en donde se construyen las bases para que el trabajo pueda materializarse.

Durante el Sprint Planning, se diseña en gran detalle el plan de trabajo. El trabajo es realizado entre el Product Owner y el Scrum Team y durante la sesión, se discuten y analizan las tareas a incluir en el Product Backlog.

Es muy importante que durante el Sprint Planning se construya una clara e incondicional relación entre los items del Product Backlog y el Product Goal (Producto Objetivo).

¿Cómo planificar un Sprint?

Vale la pena hacer un breve inciso para indagar en el trabajo práctico de planificar un Sprint. En el mundo real, el Sprint Planning se lleva a cabo en una reunión que incluye:

• El Product Onwer,
• al Scrum Team,
• y a todas las partes interesadas dentro de la organización en función de invitados con derecho a opinar.

El éxito de un Sprint Planning puede definirse por una serie de factores. Por ejemplo, podemos mejorar nuestras posibilidades si el Product Owner prepara con antelación un Product Backlog preliminar que dé un primer punto de discusión al inicio de la reunión. Empezar con un Product Backlog a modo de borrador es muy recomendable para el Product Owner, ofreciendo un excelente comienzo.

Otro consejo para el Product Owner es consultar con todos los asistentes la disponibilidad que tienen para asistir al Sprint Planning. Es importante que la reunión de planificación no entre en conflicto con tareas de alto valor que algunos miembros del equipo pueden estar llevando a cabo. Por ello, es fundamental preguntar antes de establecer la cita en el calendario. Lo mismo aplica para los recursos potencialmente necesarios durante la reunión.

Y aunque el Product Owner tiene todas estas responsabilidades, parte importante de planificar esta sesión de trabajo depende del Scrum Master, aunque no esté de cuerpo presente durante la reunión. Es este profesional quien tiene que dar un repaso a la lista de asistentes, establecer la duración de la reunión, definir una agenda para la reunión y distribuirla a todos.

Si esta sesión de Sprint Planning corresponde a un segundo o subsecuente Sprint, es recomendable empezar haciendo hincapié en progreso logrado con el Sprint anterior. Vale la pena retomar no solo el progreso conseguido a través de los esfuerzos del equipo, sino también navegar las expectativas y objetivos generales del proyecto.

Durante el Sprint Planning, el Product Owner necesita preguntar al equipo de desarrolladores cuál es su estado en términos de velocidad. En Scrum, la velocidad es una unidad de medida que hace referencia a la cantidad de trabajo que el Scrum Team puede realizar durante un Sprint. Por supuesto, esta es una unidad de medida fundamental para poder definir cuántas tareas y de qué naturaleza se pueden incluir en el Product Backlog de cada Sprint.

Una de las cosas más importantes a llevar a cabo durante un Sprint Planning es revisar de forma grupal y en detalle el Product Backlog. Se debe abordar cada tarea y asignarse al miembro o miembros del equipo que corresponda.

La teoría Scrum nos enseña que el Sprint Planning debe responder tres preguntas esenciales:

1. ¿Por qué este Sprint es valioso para el proyecto en curso?
2. ¿Cuánto trabajo podemos completar durante este Sprint?
3. ¿Cómo se completará el trabajo seleccionado durante este Sprint?

Al final del Sprint Planning, tenemos que poder responder con claridad estas tres preguntas y todos los miembros del equipo deben sentirse cómodos con respecto a las decisiones tomadas.

¿Qué es un Daily Scrum?

El Daily Scrum se realiza, con su nombre lo sugiere, de forma diaria y tiene una duración de 15 minutos. El objetivo de este evento es inspeccionar con transparencia el progreso que el Sprint está registrando y, de ser necesario, adaptar Sprint Backlog para producir mejores resultados.

El Daily Scrum se trata de optimizar hasta el último detalle. Todos los miembros participan para revisar y ajustar en pro de generar más valor. Esto incluye al Product Owner y/o Scrum Master en el particular caso de que ellos estén trabajando en tareas presentes dentro del Sprint Backlog.

Lo interesante del Daily Scrum, además de su naturaleza estricta (sesión de 15 minutos todos los días y a la misma hora), es que a su vez, ofrece gran flexibilidad a los desarrolladores para que estos elijan cómo trabajar, qué tareas atacar, cuáles herramientas y estrategias utilizar, entre otros aspectos del proyecto, siempre y cuando sea para que el Sprint se mueva hacia el Sprint Goal. También es útil para identificar impedimentos en ciertas tareas y solucionarlos para que el equipo pueda seguir avanzando.

Un efecto muy poderoso del Daily Scrum en el equipo es su capacidad de motivar al equipo, brindando los medios para auto-gestionarse y continuamente mejorar.

¿Qué es un Sprint Review?

Digamos que el Sprint acaba. ¿Ahora qué? Si algo hemos aprendido de Scrum hasta el momento es que la optimización continua de los procesos juega un rol fundamental. Si no mejoramos nuestros procesos, no estamos usando Scrum.

El Sprint Review es el evento que toma lugar justo al finalizar el Sprint y tiene como finalidad la inspección de los productos. El equipo de desarrolladores, después de una inspección interna, presentan estos resultados al resto de profesionales involucrados.

Durante el Sprint Review, se genera una conversación en torno al progreso logrado hacia el Sprint Goal y Product Goal. Se analiza cómo los esfuerzos cambiaron la forma de trabajar del equipo y su entorno. Pero cuidado: no se trata de una simple presentación, sino de una sesión de trabajo completa en donde todos los participantes tienen que aportar y ayudar a la optimización.

En términos de planificación, hay que limitar la duración del Sprint Review a 4 horas. Si hemos tenido un Sprint inferior a 4 semanas, podemos tener una sesión de Sprint Review más corta.

¿Qué es un Sprint Retrospective?

El Sprint Retrospective es el último evento del Sprint y es la sesión que ocurre justo antes de reiniciar el ciclo de trabajo. Su objetivo es implementar todas las mejoras posibles y utilizar de forma práctica toda la sabiduría obtenida durante el Sprint.

Se lleva a cabo una revisión muy detallada de cada aspecto de Scrum, incluyendo el Definition of Done (Criterio de Aceptación). También se presta especial atención a los problemas encontrados y se decide si tales obstáculos quedaron solucionados o no. La prioridad número uno es solucionar y mejorar todo lo que se pueda solucionar y mejorar antes de continuar trabajando. Si alguna optimización no se puede implementar en el momento, se incluye como tarea dentro de Sprint Backlog para el próximo Sprint.

---

Hasta el momento hemos aprendido la teoría más básica de Scrum, quién compone un Scrum Team, cómo se diferencian el Scrum Master y el Product Owner, cómo planificar un Sprint Planning y los diferentes eventos dentro de Scrum.

El último elemento esencial dentro de la teoría de Scrum son los Artefactos, comúnmente referidos como Scrum Artifacts.

¿Qué son los Scrum Artifacts o Artefactos?

Antes vimos cómo el Scrum Team estaba compuesto por el recurso humano, profesionales que realizan el trabajo. Luego conocimos en detalle los Scrum Events, etapas dentro del proyecto que encapsulan tareas de diferentes naturalezas.

Ahora es momento de entender cómo se calcula y evalúa el trabajo en Scrum. La forma de hacerlo son los Artefactos. Comúnmente referidos como Scrum Artifacts, estos son representaciones prácticas del trabajo realizado y el valor producido. El objetivo de los Scrum Artifacts es maximizar la transparencia y garantizar la representación precisa del progreso u otra información esencial. Su uso habilita la evaluación objetiva del progreso.

Existen tres Artefactos y cada uno de ellos sirve el propósito de medir el progreso de cada tipo de objetivo. Repasemos cada Artefacto y el tipo de progreso que reflejan, empezando por el de mayor escala.

¿Qué es el Product Backlog en Scrum?

El Product Backlog es el principal medio de trabajo utilizado por el Scrum Team. Este Artefacto contiene una lista de tareas que están organizadas según su prioridad y que buscan mejorar el producto.

Dicho esto, la efectividad del Product Backlog se contrasta con el progreso hacia el Product Goal, el cual es el objetivo a largo plazo para cualquier Scrum Team. El Product Goal describe las condiciones y características del producto que se desea producir con Scrum. Por ello, todas las tareas en el Product Backlog deben diseñarse para alcanzar este objetivo.

Pero, ¿qué es el producto en Scrum? Una definición sencilla: El producto en Scrum es el vehículo utilizado para entregar valor a la organización.

Durante la planificación, hay que invertir trabajo en definir muy bien el producto particular que se busca, es decir, el Product Goal. Algunos de los datos a incluir en el Product Goal son su naturaleza (servicio a prestar, producto físico, etc), las partes interesadas que estén involucradas en su producción, las características del usuario final, entre otros aspectos que nos ayuden a entender la meta.

Los miembros del equipo trabajan en el Product Backlog durante el Sprint Planning, evento que toma lugar justo al comienzo de un Sprint y que tiene como objetivo indicar la dirección y procedimientos. En este momento, el equipo trabaja para refinar las tareas dentro del Product Backlog, haciéndolas tan claras como fuese posible.

¿Qué es el Sprint Backlog en Scrum?

El siguiente Artefacto es el Sprint Backlog, una combinación productiva de múltiples elementos:

1. Sprint Goal: El “Por Qué” del Sprint, su razón de ser.
2. Selección de tareas desde el Product Backlog: El “Qué” del Sprint, los items que hay que completar.
3. Increments: El “Cómo“, los pasos prácticos para lograr progreso real.

Podemos decir que el Sprint Backlog es el plan de acción de un equipo de desarrolladores durante el Sprint. Es la lista de tareas a atacar, junto con todos los detalles necesarios para lograrlo.

El Sprint Backlog es un Artefacto flexible, sensible a modificaciones y ajustes durante cada Daily Scrum. Los desarrolladores determinan si el plan de acción inmediato debe cambiar y si es el caso, ocurre en el Sprint Backlog. Mientras, el Sprint Goal (el “Por Qué“) se mantiene riguroso para garantizar la concentración de los esfuerzos del equipo.

¿Qué es un Increment en Scrum?

Un Increment en Scrum, también referido como Incremento, es una unidad de progreso dentro del Sprint. Cada Increment representa un paso hacia el Product Goal. Entonces, más Increments representan mayor progreso.

Sin embargo, hay una consideración muy importante a la idea de ir sumando Increments: cada Increment que se consiga debe ser aditivo a los Increments conseguidos anteriormente, como una cadena. Esto es así para garantizar coherencia y veracidad de los datos.

Pueden existir múltiples Increments en un Sprint pero no es necesario. Como esta unidad de medida busca hacer referencia al progreso hacia el Product Goal y no el Sprint Goal, se puede tener un Increment de alto valor por Sprint.

Durante el Sprint Review, el equipo presenta y analiza el Increment o Increments conseguidos durante el Sprint. La condición estricta para considerar el progreso como un Increment es el denominado Definition of Done (Criterio de Aceptación). El Definition of Done, de hecho, es el elemento con el cuál se contrasta la validez de un Increment. Este elemento es una descripción minuciosa y detallada del criterio a utilizar para considerar si un Increment ha conseguido la calidad y cualidad necesaria, para decir, si es válido o no.

La calidad del Definition of Done (Criterio de Aceptación) es importante en sí misma pues debe garantizar claridad. Los miembros del equipo no deben conseguir ningún obstáculo para entender el Definition of Done en detalle, lo que implica. Este elemento establece un estándar necesario de trabajo.

Comparativa de Scrum con diferentes metodologías y filosofías de gestión de proyectos

Con una búsqueda online, podemos conseguir abundantes detalles sobre la multitud de metodologías disponibles para que organizaciones y equipos operen productivamente. Tantas opciones pueden, sin embargo, desanimar a profesionales que sean nuevos en el tema.

Por ello, tener algo de contexto sobre las otras metodologías ahí fuera puede servir para entender mejor Scrum, sus ventajas y beneficios, así también como sus debilidades.

El hecho de que hoy estemos hablando extensivamente sobre Scrum no significa que necesariamente consideremos Scrum como la mejor opción para tu gestión de proyectos. De hecho, siempre existirá la posibilidad de que otra metodología sea más compatible con tu organización, recurso humano y objetivos empresariales. Las comparativas son útiles para continuar navegando el universo de posibilidades y, con paciencia, descubrir cuál es la mejor opción.

Y como hemos mencionado, tenemos que tener presente la situación de Scrum con respecto a otros conceptos en gestión de proyectos, principalmente con la metodología Agile.

Podemos encontrar explicaciones en donde Scrum se compara en el mismo contexto con Agile, cuando esto no es del todo correcto. Agile es una filosofía para la gestión de proyectos que brinda un universo de ideas y conceptos de muchísimo valor pero no es, en sí, una serie de técnicas estandarizadas para lograrlo. Luego viene Scrum, la metodología clara y estructurada, como producto de la filosofía Agile. También podemos decir correctamente que Scrum es una forma de implementar el sistema Agile en tu organización.

Sin más dilación, conozcamos qué más hay ahí fuera.

Metodología Scrum vs Kanban

Al igual que Scrum, Kanban es una metodología práctica para implementar la gestión de proyectos en una organización. Cualquier persona que haya usado Trello en algún momento, ha tenido contacto con la metodología Kanban. Esta se basa en un proceso fluido y continuo, con la menor fricción y pausas posibles.

Kanban es una metodología que prioriza la visualización del trabajo usando tableros (conocidos como tableros Kanban) con columnas dinámicas, las cuales contienen las tareas por venir, en progreso y completadas, así como otros datos necesarios durante el desarrollo de cada proyecto.

Se suele recomendar Kanban a equipos con la misión de completar un proyecto en la menor cantidad de tiempo posible. El elemento visual del tablero y sus columnas, entre otras técnicas, buscan estimular la velocidad de producción y el trabajo en proceso se limita para que las tareas reciban una inversión de esfuerzo superior a la vez.

Esta reducción en los tiempos de trabajo normalmente tiene un costo en la capacidad de aprendizaje del equipo. Al mismo tiempo, se require menos estructura para implementar Kanban y se disfruta de una mayor flexibilidad en dicha implementación. Un ejemplo de la flexibilidad, también con su costo inherente, es la ausencia de roles estrictos como los que encontramos en un Scrum Team.

Kanban se basa en fluidez y la representación visual del trabajo mientras que Scrum apuesta por la continua mejora de las capacidades del equipo y el aprendizaje. Podemos de que ambos métodos se diferencian ideológicamente, priorizando cosas completamente diferentes. Vamos a ver un ejemplo más claro de ello a continuación.

Filosofía Agile vs Lean

Otro término que probablemente has encontrado mientas investigas Scrum o, inclusive, Agile, podría ser metodología Lean. Pero comparar Lean con Scrum directamente no sería correcto, así como no es posible hacer una comparación adecuada entre Scrum y Agile.

¿Por qué no es posible? Simplemente porque Lean es, como Agile, una filosofía y no una metodología práctica y con recetas.

Lean es una filosofía de gestión que se basa en proveer una experiencia favorable desde la perspectiva del cliente final, uso eficiente de los recursos mientras se elimina cualquier posible desperdicio y la mejora continua de los procesos, el recurso humano y el producto. Metodologías muy famosas de gestión y producción como Six Sigma tienen sus raíces en la filosofía Lean.

Pero, ¿cómo se comparan Agile y Lean? Similares en ciertos aspectos, podemos conseguir diferencias clave entre Agile y Lean al observar ritmos y cargas de trabajo, relación producto-cliente, roles dentro del equipo y valores humanos.

Mientras que Agile presenta métodos escalables en donde el trabajo se divide en diversos bloques para su mejor apreciación y análisis, Lean apuesta por velocidad y flujo. Una muestra práctica de ello es cómo Scrum se compara con Kanban. Kanban es, de hecho, una metodología basada en Lean, por lo que la fluidez en el trabajo es de vital importancia.

A su vez, Lean da prioridad a eliminar cualquier posible desperdicio durante producción. La justificación de esto, más allá de la clara búsqueda por eficiencia en los recursos, es el deseo por poner a las necesidades del cliente primero. ¿Qué significa esto? Desde los orígenes de Lean, se ha considerado que cualquier grado de desperdicio durante el proceso atenta directamente en contra de la experiencia del usuario. Agile, a su vez, brinda plenitud de atención al cliente pero lo hace de una forma distinta, como por ejemplo, creando un canal de comunicación para escuchar al público.

Finalmente, tenemos el elemento de la disciplina. Cuando comparamos Agile con Lean, nos encontramos con que Agile es una filosofía más rigurosa y estricta, así como lo hemos visto en Scrum. Existe una implementación y procesos a respetar; si no se respetan, no es Scrum. Esta rigurosidad hace posible resultados muy satisfactorios en la gestión del proyecto. Por el otro lado, Lean prefiere la fluidez y la flexibilidad. Los procesos pueden modificarse según se considere necesario o preferible.

Metodología Scrum vs Waterfall

Volvemos a Scrum para compararle con Waterfall, una metodología popular con la que nos podemos conseguir fácilmente. ¿Cuáles son las características de la metodología Waterfall?

Con Waterfall, se establece una secuencia bien definida de acciones y procesos definida en fases. Los desarrolladores no pueden avanzar de una fase a la siguiente hasta que no se obtenga la aprobación final del trabajo realizado. En la práctica, con Waterfall, resulta difícil volver a fases anteriores en caso de correcciones necesarias, lo cual puede traer problemas.

La diferencia aquí con Scrum es monumental. La corta duración de los Sprints permite la revisión constante antes de seguir avanzando pero, a la vez, un método ágil y productivo para aprobar resultados y continuar el trabajo.

Metodología Scrum vs XP (Extreme Programming)

Por último, tenemos una comparación entre Scrum y XP (Extreme Programming). Estas dos metodologías son realmente similares pero, aún así, poseen diferencias considerables que las separan lo suficiente.

Ya sabemos que en Scrum, los equipos trabajan en bloques de tiempo denominados Sprints. Estos periodos tiene una duración entre 1 y 4 semanas. Sin embargo, en el caso de XP, los desarrolladores organizan el trabajo en periodos no superiores a 2 semanas.

Una diferencia importante la encontramos en la rigurosidad de la planificación. Durante el Sprint Planning del Scrum, el equipo se compromete a un marco de trabajo estable, en donde lo único que cambia son los Sprints y Product Backlogs; el resto de aspectos determinantes del proyecto se mantiene hasta el término del Sprint, en donde todo se estudia y reconduce. Esto no sucede en Extreme Programming. Al contrario, los equipos que utilizan XP tienen la posibilidad de cambiar dramáticamente la dirección antes de culminar un periodo de trabajo, si así lo consideran justo y necesario, más que nada basados en las prioridades del producto que están desarrollando (ejemplo, una característica del software ha ganado mayor prioridad).

Dentro de esta flexibilidad que ofrece XP, también está el hecho de que los equipos pueden modificar el marco práctico de la metodología y adaptar flujos de trabajo según prefieran. Como hemos dicho antes, Scrum es bastante riguroso en este sentido, estableciendo que la teoría se tiene que respetar al pie de la letra y que en el momento que el equipo se desvía ligeramente de la metodología, la gestión de proyecto en su totalidad deja de ser Scrum.

Finalmente, XP está más orientada, como metodología, a equipos de ingenieros y muchos de los enfoques para conseguir una mayor eficiencia se basan en métodos de ingeniería, software y automatización. Al mismo tiempo podemos decir que Extreme Programming es más dependiente de las capacidades técnicas del equipo.

Herramientas para Scrum: Selección de mejor software SaaS para gestión de proyectos

Llegados a este punto, podemos decir que entendemos los fundamentos básicos de Scrum. Para mejorar nuestras capacidades, los recursos educativos abundan. También existen las muy valiosas certificaciones de las cuál hablaremos al final de la guía. Sin embargo, hay otra opción para ir practicando y entendiendo aún mejor la metodología Scrum.

Ahora mismo existe una variedad de herramientas para Scrum a bajo costo o directamente gratuitas. Te invitamos a conocer estos productos SaaS y a experimentar con Scrum.

ClickUp

En ClickUp han sido vocales en cuanto a la capacidad del producto para implementar Scrum. De hecho, ofrecen una guía completa para empezar a usar Scrum con la herramienta: dejamos el link a la guía de Scrum con ClickUp aquí (en inglés).

Ya hemos hablado múltiples veces de ClickUp, un extraordinario gestor de proyectos con una gran variedad de características. Desde el comienzo, la misión de ClickUp ha sido convertirse en el all-in-one de la gestión de proyectos y comunicación de equipos, añadiendo además una excelente app móvil, dashboards, reportes personalizados, recordatorios y notificaciones push, administración avanzada de tareas, múltiples vistas (incluyendo tableros Scrum, Kanban y diagrama de Gantt), entre muchas otras.

Haz clic aquí para visitar la ficha de producto de ClickUp en SaaS Rank.

Trello

Trello es un clásico de la gestión de proyectos. Aunque la primera impresión que nos da esta herramienta es que está diseñada para la metodología Kanban, la verdad es mucho más complicada.

Trello es igual de ideal para la implementación de Scrum. La combinación de columnas dinámicas con capacidad de automatización y tarjetas ricas en detalles (usuarios, comentarios, listas de tareas, fechas de vencimiento, archivos adjuntos, entre otras) crea un entorno de trabajo perfecto para Scrum. Además de sus funciones por defecto, Trello tiene Power-Ups específicamente diseñados para workflow de Scrum, lo cuál facilita mucho más el trabajo del equipo.

Tal como lo ha hecho ClickUp, Trello ofrece una guía detallada en su sitio web para implementar Scrum con su herramienta (en inglés).

También puedes aprender más sobre Trello en nuestra ficha de SaaS Rank.

Monday.com

Otra buena opción para implementar Scrum es Monday.com. Esta plataforma es un gestor de proyectos muy capaz con increíble flexibilidad para adoptar distintas metodologías.

Sin embargo, dentro de su mensaje de marketing, promueven el uso de la herramienta para organizaciones Agile. Por ello, podemos estar seguros de que nos ofrecerá todas las características necesarias para una buena implementación de Scrum e inclusive, de ser necesario, una transición cómoda a otros métodos.

De hecho, podrás encontrar en el blog de Monday.com una guía comprehensiva para la implementación de Scrum con esta herramienta. Puedes acceder al material aquí (en inglés).

También puedes aprender más sobre Monday.com en la ficha correspondiente de SaaS Rank.

Notion

Un favorito en SaaS Rank, con Notion podemos hacer virtualmente cualquier cosa. Una de ellas es implementar Scrum con éxito en nuestras organizaciones.

Si ya conoces Notion, sabrás que este producto SaaS ofrece una extraordinaria flexibilidad junto con potentes capacidades gracias a sus bases de datos y conectividad de las mismas. Al mismo tiempo, entre las opciones de visualización de las bases de datos podemos encontrar tableros, lo cual es ideal para implementar Scrum.

En el siguiente enlace podrás encontrar la guía de Notion sobre Scrum y Kanban, con ejemplos de cómo utilizar esta herramienta para el uso de estas metodologías.

Haz clic aquí para aprender más sobre Notion en su ficha de SaaS Rank. También hemos publicado un artículo sobre Notion como gestor de proyectos ideal.

Jira

Si le preguntas a un Scrum Master o cualquier gestor de proyectos con experiencia, una de las recomendaciones que te hará será Jira. Esta plataforma es legendaria entre equipos de desarrollo de software, convirtiéndose en el estándar dentro de muchos círculos.

Aunque Jira es, sin duda alguna, excelente, esto no significa que es la herramienta correcta para tu empresa. Como hemos dicho, Jira es un favorito de la comunidad de desarrollo de software. Esto quiere decir que equipos menos técnicos, por ejemplo, de marketing o de ventas, pueden sentir que Jira les es inadecuado.

Dicho esto, Jira está diseñado según la filosofía Agile, así que hay pocas herramientas tan apropiadas para esta clase de proyectos. Puedes conocer más sobre las capacidades de Jira para Scrum haciendo clic aquí (en inglés).

Certificaciones Scrum para potenciar tu carrera

Siendo honestos, una guía como esta no hace justicia a todo lo que hay para aprender sobre Scrum. Esta es una metodología con abundante teoría y mucho que aprender sobre la marcha. No hay forma de saber lo suficiente con una lectura. Por ello, existen abundantes recursos, incluyendo certificaciones que pueden hacer avanzar tu carrera.

Las certificaciones Scrum son muy bien valoradas en 2022. La demanda también va en alza. Si vives en Madrid, una posición como Scrum Master puede brindarte un salario medio de 53.000 € al año. Si por otro lado, vives en Raleigh, Estados Unidos, el salario medio es de US$121.000 para la misma posición.

Tanto equipos de desarrollo de software como de marketing, ventas y diseño, entre muchos otros, pueden beneficiarse de Scrum. Por ello, profesionales que puedan implementar el sistema y asegurarse de que el equipo alcance un buen rendimiento resultan tremendamente atractivos en 2022.

En conclusión, una certificación Scrum puede cambiar el curso de tu carrera para mejor. Sin embargo, hay varias opciones a considerar, ya que requieren esfuerzo y la mayoría de ellas no son necesariamente baratas.

La siguiente lista incluye las certificaciones más interesantes según Coursera y los enlaces a cada una de ellas si quieres conocer más:

• Certified ScrumMaster (CSM): Según los datos de Coursera, esta es la certificación más popular entre las ofertas de trabajo. CSM es respaldada por Scrum Alliance, organización que ofrece los cursos a diferentes niveles y las respectivas certificaciones. Los precios van entre $400 y $1.000 por el curso (un par de días, usualmente) y la evaluación que garantiza la certificación. Puedes conocer las opciones disponibles en Certified Scrum Master (CSM) aquí.
• Certified Scrum Product Owner (CSPO): También impartido por Scrum Alliance, esta certificación está orientada a Product Owners. Existen, como en el caso anterior, varios cursos según el grado de especialización que deseamos y los precios varían en base a esto. Haz clic aquí para conocer más sobre el Certified Scrum Product Owner (CSPO).
• Professional Scrum Master (PSM I): Certificación ofrecida por Scrum.org, esta es una de las opciones clásicas y de mayor calidad. Este primer nivel como Scrum Master se puede conseguir con una certificación mucho más económica pero menos popular entre las ofertas de trabajo analizadas, según los datos de Coursera. Haz clic aquí para conocer más sobre PSM I en Scrum.org.
• Certified Scrum Professional (CSP): Esta certificación por Scrum Alliance difiere un poco de las mencionadas anteriormente. La idea del CSP es obtener los conocimientos necesarios para ser un profesional Scrum con mayor alcance, uno que pueda mejorar cada aspecto de cómo el Scrum Team opera. Es más económico, alrededor de US$250, pero al mismo tiempo es necesario tener una certificación activa como Certified Scrum Developer, también ofrecida por Scrum Alliance, así como una cantidad mínima de experiencia trabajando con Agile. Conoce más sobre CSP haciendo clic aquí.
• SAFs Scrum Master (SSM): Scaled Agile es una organización que es responsable por el diseño y mantenimiento del Scaled Agile Framework, una metodología basada en Agile. Obtener la certificación de SSM puede resultar interesante para operar en organizaciones que utilizan Agile en gran escala, donde el resto a enfrentar es complejo. Los cursos junto certificación tienen un costo alrededor de US$800. Haz clic aquí para conocer más sobre SAFs Scrum Master.
• Professional Scrum Product Owner I (PSPO I): De vuelta a Scrum.org, esta certificación ayuda a profesionales con la misión de convertirse en Product Owners altamente capacitados. Esta certificación es más accesible a nivel económico y nos permite ir avanzando de forma escalada en nuestra formación, ya que podemos empezar con PSPO I y poco a poco ir consiguiendo las certificaciones en PSPO II y PSPO III.

Conseguir trabajo como Scrum Master o Product Owner

Deseamos cerrar esta lista de certificaciones con la opción que ofrece Google en Coursera. El Google Project Management es una certificación compuesta por 6 cursos diferentes que enseñan una visión global pero detallada de la gestión de proyectos. El quinto curso dentro de la certificación es Agile Project Management, enseñando en mayor detalle la implementación de Scrum. Esta serie de cursos, al término, ofrecen una certificación válida para entrar en el mercado profesional, tal como las otras opciones descritas más arriba.

Si quieres aprender Scrum y hacerlo de forma seria, con la intención de conseguir un trabajo como Scrum Master o Product Owner, todas las opciones indicadas arriba son muy válidas y te pondrán en el camino correcto para conseguir resultados.

Entrar en esta industria como profesional de Scrum es una carrera muy emocionante (y lucrativa) para personas con vocación a la organización, planificación, dirección de equipos, comunicación efectiva y mucha disposición para ayudar a equipos enteros a hacer el mejor trabajo posible.

Últimas palabras

El mundo de la gestión de proyectos es realmente apasionante. La importancia de planificar, organizar, gestionar y dar dirección a equipos es mayor que nunca. Nuestra economía basada en la información puede ser abrumante. Por ello, la existencia del Scrum Master jamás había sido tan necesaria.

Scrum es uno de los tantos métodos que tienen el potencial de transformar tu organización. En SaaS Rank esperamos que este artículo sirva como una introducción decente al tema y que nuestras recomendaciones sobre herramientas y certificaciones sean de utilizar para tomar un primer paso hacia este campo. En el pasado publicamos un artículo corto sobre las ventajas y desventajas de Scrum que sin duda abrió nuestro apetito sobre el tema. Lo puedes ver aquí.

Sin duda, en SaaS Rank continuaremos explorando temas muy relacionados a Scrum y Agile. La gestión de proyectos es un apasionante interés que tenemos en nuestro equipo, así como el encontrar la mejor herramienta para realizar el trabajo.

Lecturas recomendadas

• Agile tools for software teams – Jira (en inglés)
• What is Scrum? – Scrum.org (en inglés)
• Scrum Glossary – Scrum.org (en inglés)
• The 2020 Scrum Guide – Scrumguides.org (en inglés)

The post Qué es Scrum: Todo lo que necesitas saber + Herramientas appeared first on SaaS Rank.