Scrum Gestión de proyectos: Lo que necesitas saber

Cómo ha cambiado el trabajo

El trabajo es un aspecto en constante evolución de nuestra vida cotidiana. No hace mucho tiempo que el trabajo se entendía como algo mucho más cercano a la artesanía y al trabajo manual durante los primeros periodos preindustriales. Fue en la década de 1950 cuando surgió la versión más reconocible de la gestión de proyectos, justo después de la Segunda Guerra Mundial y en medio del auge económico que experimentaba la civilización occidental de la posguerra. Fue aquí donde se introdujeron los conceptos de organización de proyectos a través de los trabajos de Henri Fayol y Henry Gantt (de la fama del diagrama de Gantt).

Naturalmente, las tecnologías en evolución siguieron avanzando e introdujeron metodologías más complejas para el seguimiento y la medición del progreso de varios proyectos. Richa Dhall, que comparte con LinkedIn, señala que "todo esto cambió la forma de trabajar, las tareas realizadas comparten datos y el ROI (Retorno de la Inversión) se convirtió en ROTI (Retorno del Tiempo Invertido). Todas las tareas se hacían más rápido y los proyectos se terminaban en mucho menos tiempo que antes."

Con todo ello, las tecnologías siguieron desarrollándose y las empresas de software fueron las primeras en darse cuenta de la necesidad de introducir mejores sistemas para hacer frente a la rápida evolución de los competidores del mercado. Sin embargo, la programación seguía siendo un proceso largo y tedioso, y los principales responsables de las empresas querían buscar formas de mejorar los plazos de entrega de los productos en respuesta a la evolución y los comentarios del mercado y de los consumidores.

Historia rápida de la gestión de Scrum

Durante la década de 1990, Jeff Sutherland y Ken Schwaber presentaron una versión publicada de la primera iteración de lo que ahora se conoce como "Scrum Gestión de proyectos". Es importante señalar aquí que lo que habían desarrollado formalmente no era del todo novedoso ni mucho menos, sino que se entiende mejor como una coalición de diferentes principios metodológicos de agile que estaban utilizando las empresas del sector.

En ese momento, había algunas formas en las que una empresa podía elegir ser mejor agile en sus etapas de producto, utilizando metodologías como las cadencias de Cascada en un esfuerzo por reaccionar rápidamente a los cambios necesarios en sus procesos de desarrollo. Schwaber, en un libro blanco publicado en su sitio web, afirmó que, aunque sistemas como el de la cascada pueden ser eficientes en el desarrollo de productos, también se basan en un proceso esperado bien entendido y estándar. Los escenarios de la vida real, argumenta Schwaber, son mucho más volátiles por naturaleza y requieren una retroalimentación mucho más consistente respecto a los cambios e iteraciones necesarios.

En 1994, se escribió un artículo clave para la Harvard Business Review en el que se esbozaba un "nuevo" método de desarrollo de productos. Este artículo, escrito por Hirotaka Takeuchi e Ikujiro Nonaka, esboza una teoría en la gestión de proyectos que puede permitir a los gestores y a los equipos evitar el "enfoque de relevos" y, en su lugar, trabajar dentro de equipos especializados para hacer avanzar un producto en un "scrum". Scrum es un término que el dúo tomó de la forma en que los equipos de rugby trabajaban juntos como una unidad para llevar el balón a la portería.

Con este artículo y el término ciertamente adecuado que lo acompaña, Schwaber y Sutherland expusieron una versión más completa de esta metodología y la presentaron en la conferencia OOPSLA'95 (Programación Orientada a Objetos, Sistemas, Lenguajes y Aplicaciones).

Cómo funciona Scrum

Aunque la historia nos muestra el contexto de por qué era necesario un sistema como éste para acomodar mejor el creciente movimiento hacia las nuevas metodologías deagile , los procesos exactos que contiene pueden ser desalentadores para que el lector que lo lea por primera vez los entienda completamente. Esencialmente, un scrum es un método para proporcionar calendarios rápidos de desarrollo incremental para sacar al mercado iteraciones de productos viables en un corto período de tiempo (normalmente de 1 a 4 semanas).

Estas sesiones de scrum se refieren a breves reuniones en las que los miembros del equipo, los directores de producto y los maestros de scrum se conectan para revisar el estado actual del producto en cuestión. En ellas se discuten los principales éxitos, las preocupaciones inmediatas e incluso los futuros retos que prevén que se producirán en el mercado. El objetivo final de estas reuniones es agilizar la entrega de un producto de alta calidad que esté mejor informado por los conocimientos internos y externos.

De nuevo, Scrum en sí no es la única forma de poner en práctica la perspectiva agile en tu trabajo, ni está totalmente confinada dentro del espacio de desarrollo de software. ScrumSu principal objetivo es proporcionar un marco general para que los equipos lo sigan, basado en la acción, la revisión y la adaptación en un proceso breve pero eficaz. De este modo, Scrum es lo suficientemente flexible como para incorporarse a diferentes contextos, al tiempo que permite un mínimo de orientación a los equipos que navegan por procesos de desarrollo poco claros.

Principales procesos de Scrum

El marco Scrum , tal y como lo describen Schwaber y el Instituto de Gestión de Proyectos (PMI), no es tanto una metodología exacta paso a paso como una estructura en la que los equipos pueden poblar sus propios procesos de forma más organizada. Los principales componentes de un scrum que un gestor de proyectos debe conocer son los Backlogs de Producto, los Sprints y los Incrementos de Producto, que en sí mismos contienen subcomponentes que los gestores deberán tener en cuenta para el éxito de un scrum.

Los atrasos de los productos

Como precursor de todo el producto, se define una meta clara para el negocio como objetivo general para el equipo en general. Después de esto, se definen los backlogs del producto, que son esencialmente un conjunto de características del producto que están informadas por la necesidad del mercado, el desarrollo de la competencia, los comentarios de los clientes u otros aspectos que pueden influir en la implementación de las características. Es aquí donde los "Propietarios de Producto" designados se encargan de gestionar la comunicación de estas características solicitadas entre el "Scrum Master" y el "Scrum Team".

Los Sprints

A continuación, se establece un marco temporal o "caja de tiempo", que en el marco scrum se conoce como iteración individual o "sprint". Con este sprint, se establece una duración entre todos los miembros de scrum , en la que deben entregar las características seleccionadas como parte del backlog del producto. El tiempo necesario para cada sprint varía, pero suele fijarse en un estándar de 1 a 4 semanas.

Se trata de una línea de base integral con la que trabajar, ya que establece esencialmente la cadencia en la que el equipo de scrum trabaja para desarrollar el producto según las características acordadas, que se deriva del backlog del producto y se define como el "sprint backlog" para el sprint específico en cuestión.

Durante el sprint propiamente dicho, el equipo de scrum puede concentrarse plenamente y se le asignan recursos para terminar el sprint en el tiempo previsto. Es importante señalar aquí que el scrum requerirá la gestión práctica del maestro Scrum , ya que es probable que surjan problemas durante estos períodos de desarrollo. Dependiendo de la sensibilidad temporal del producto, el tiempo asignado podría ajustarse para adaptarse mejor a cualquier problema crítico.

El trabajo de sprint en sí no debe modificarse durante este periodo, lo que significa que no deben inyectarse características adicionales durante el propio sprint . Pueden añadirse nuevas solicitudes de desarrollo de productos a los siguientes backlogs de productos que, a su vez, se desarrollarán en los siguientes backlogs de sprint . Dentro de estos periodos de sprint , los equipos de scrum , junto con el maestro de scrum y el propietario del producto, si es necesario, volverán a conectarse en reuniones breves (de una duración estándar de entre 15 y 30 minutos) para alinearse sobre las tareas terminadas, lo que planean completar al final del día, así como cualquier obstáculo importante en el camino del trabajo específico a realizar. Estas breves reuniones son un recurso fantástico para el trabajo interfuncional, especialmente cuando el equipo se acerca a la finalización de sus sprints.

Revisión de los incrementos de producto

Es después de estas sesiones individuales de sprint cuando entra en juego el aspecto breve, pero no por ello menos importante, de scrum , a través de las revisiones incrementales del producto. Algunos recursos de scrum pueden referirse a este método como refinamiento del backlog, grooming u otros términos similares.

El aspecto esencial de este componente de scrum es revisar el estado del producto en su iteración más reciente después de la sprint, reevaluar si el actual backlog del producto sigue siendo relevante y si es necesario realizar algún ajuste en los procesos de desarrollo. Esto incluirá la obtención de comentarios de las partes interesadas internas y externas para ver dónde y cómo pueden mejorar.

Es aquí donde scrum se apoya en los principios de acción, revisión y adaptación que hemos mencionado antes. Sin este último paso de revisión y adaptación, es probable que el producto se pierda características clave que podrían ser fundamentales para el éxito del producto en el mercado. Con el panorama actual, que cambia rápidamente en cuanto a lo que es probable que se desarrolle en los próximos meses, es absolutamente importante revisar constantemente dónde está el producto y adaptarse en consecuencia dentro del marco de scrum .

Funciones clave Scrum

A pesar del recorrido relativamente robusto que acabamos de comentar sobre el proceso general por el que pasa scrum , el número de roles clave dentro del marco de trabajo es relativamente sencillo en comparación. Scrum sólo necesita que se definan adecuadamente tres roles principales para ser totalmente funcional a efectos de gestión de proyectos. Según el formador certificado de Scrum , Mike Crohn, de ScrumAlliance.org, estos roles se definen como el Propietario del Producto, el Maestro de Scrum y los Equipos de Scrum .

El propietario del producto

Esencialmente la parte del proyecto scrum orientada al cliente y al negocio, el propietario del producto gestiona y sirve de enlace entre el maestro de scrum , el equipo de scrum y cualquier otra parte interesada interna o externa que tenga influencia en el proyecto. El propietario del producto también puede entenderse como una voz clave para la forma eventual y la versión final del producto de acuerdo con la visión empresarial principal del proyecto.

Dado que es probable que se produzcan muchos cambios entre cada backlog del producto y el posterior sprint, es el propietario del producto el que tiene que ser totalmente responsable de la adhesión a los elementos clave que se necesitan para el éxito del producto en el mercado. También tendrá que ser experto en comunicar esta visión tanto al maestro de scrum como al equipo de scrum , ya que estos dos últimos se encargarán de la gestión y el desarrollo real del producto de forma adecuada.

Los Propietarios de Producto cualificados saben cómo aprovechar los backlogs del producto para alinear mejor a todo el mundo con los elementos prioritarios para el desarrollo del proyecto, ya que probablemente serán los que comprendan plenamente lo que buscan los usuarios del producto. El conocimiento de la industria y la previsión son clave para ello, ya que deben ser capaces de adaptarse a cualquier cambio visto (y no visto) en el mercado.

El maestro Scrum

Si el Propietario del Producto está a cargo del aspecto del negocio y del usuario final del producto, entonces el Scrum Master está a cargo de gestionar el lado del proceso de desarrollo del proyecto. Su función principal es asegurarse de que cada miembro del equipo de scrum comprenda la cobertura de scrum , así como sus funciones individuales dentro de ella.

Actuando como facilitador general, guía y entrenador a lo largo del proceso, se espera que el Scrum Master sea capaz de comprender el flujo operativo de lo que supondrá cada sprint , ya que debe sortear cuidadosamente las preocupaciones que pueda tener el equipo de Scrum . Dados los ajustados plazos de cada sprint (de 1 a 4 semanas), la mano firme del Scrum Master es una necesidad absoluta para mantener a todos en el buen camino.

Al asumir este papel de supervisión, es esencial que el Maestro Scrum también sea consciente de los límites de sus respectivos Equipos Scrum para evitar cualquier problema de exceso de capacidad en sus tareas. El Scrum Master también puede proporcionar orientación de pensamiento lateral para ayudar mejor a los miembros del Scrum Team a salir de los atolladeros de desarrollo.

El equipo de Scrum

Por último, pero no por ello menos importante, el equipo Scrum se encarga de la carne del proyecto scrum . Mientras que el Product Owner y el Scrum Master gestionan y delegan las tareas, el Scrum Team lleva a cabo el desarrollo y la implementación en los sprints propiamente dichos.

Estos equipos de Scrum son, en general, multidisciplinares, y suelen estar formados por personas con diferentes enfoques del proyecto, como analistas de negocio, probadores de productos, desarrolladores de productos, directores de marketing e incluso directores financieros.

Es este equipo el que trabaja conjuntamente en los sprints en un esfuerzo por cumplir con los backlogs de sprint , aprovechando la experiencia de los demás durante sus reuniones diarias de scrum , así como proporcionando asistencia siempre que puedan dentro de la actual sprint.

El resultado final que quieres de un equipo Scrum plenamente funcional es uno que practique un fuerte sentido de autonomía y propiedad con su trabajo. La autoorganización y la confianza en sus capacidades durante las fases de crujido de sprint son necesarias para producir los mejores resultados para la iteración del producto.

Con estas tres funciones definidas, puedes delimitar mejor las responsabilidades y reducir la ineficacia generada por los solapamientos de trabajo y los malentendidos. La claridad y la organización son claves en la gestión de proyectos de Scrum y siguen siendo un principio clave en el funcionamiento de las metodologías de agile en su conjunto.