Metodología Scrum en un startup especializado en investigación de mercados: el caso del área de Software

Por Wilibaldo Tolentino Corona

Resumen

Desde su concepción, el método Scrum se ha convertido en el modo en que la industria de la tecnología crea software y productos nuevos. Es considerado un marco adaptable, iterativo, ágil, eficaz y capaz de autocorregirse; diseñado para ofrecer un valor considerable en periodos cortos de tiempo a lo largo de un proyecto. Garantiza transparencia en la comunicación, crea un ambiente de responsabilidad colectiva y de progreso continuo. Pero, aunque Scrum se ha vuelto exitoso en la gestión de proyectos de software en Silicon Valley, es relativamente desconocido en la práctica general de negocios. Scrum representa un cambio radical respecto a los métodos usados en el pasado. Aquí se presenta el caso del área de Software dentro de un startup especializado en investigación de mercados. 

Palabras clave: metodología Scrum, ágil, software, tecnología, startup.

Abstract

Since its introduction, Scrum has become the go-to method for the creation of new software and products in the IT industry. It is considered an adaptive, iterative, agile, efficient, and self-correcting framework designed to deliver substantial value in short periods of time throughout a project. Scrum ensures transparency in communication and creates an environment of collective responsibility as well as continuous progress. Even though it has become successful in software project management in Silicon Valley, it is relatively unknown in general business practice. Scrum represents a radical paradigm shift from the methods used in the past; this will be illustrated in this article using the case of the Software Area within a startup specialized in market research. 

Keywords: Scrum methodology, agile, software, technology, startup.

Ra tsapu̷ ts’ike jñaa*

Ndeze gi d’obu, ne método Scrum gi ha pot’u̷ kja ne ja kja ko ne kjaa b’e̷pji gin ne tecnologiao jyoku software ñe pjo̱ngu̷ b’e̷pji d’adyo. Es tsjapu̷ ndu̷b’u̷ ndja nziyo ñu̷nu̷ jyoo ra tsjaa a kjanu, iteractivo, sa̷ja̷ in pjeñe, mbe̷pji ñe k’u̷ pa̱ra̱/k’u̷ pjechi yepe ra jyoku̷ na joo; kjaa jmicha ngeko s’e̷ngua ndja na joo tsjapu̷ ndu̷b’u̷ kja ya kjogu dya maja gi paa a yo maja gi ndja b’e̷pji. tee k’u̷ ra mbo̷xk’u̷ jyaxtjo kja ne jñaa, o jyoku ndja k’o kja k’a xoñijømu̷ gi martom jmuru̷ t’eñe ñe gi noku̷ yepe ra tsjaa. Ngeko zo Scrum gi ha pot’u̷ k’a ngins’i kja ne b’e̷pji k’o kjaa gi b’e̷pji gi software kja  Silicon Valley, na relativamente dya kjo pa̱ra kja ne mbe̷pji ndaxundaro gi k’o po̷o̷. Scrum ndajmu ndja o potu̷ tjoru̷ a jmii a yo kjobu a ta̷mbad’i kja ne o kjobu. A manu na ra nzho̷o̷ ne kja ne ñu̷nu̷ gi software a mboo gi ndja startup dyoxu̷ ñe pjiño k’o kjaa k’a kja jyod’u̷ ñ’iji gi cho̷jmu̷.

jña’a arkate: Metodologia Scrum, za̷ja̷ in pjeñe, software, tecnología, startup

* Traducción lengua mazahua, variante del norte del Estado de México: María Cristina Ventura Narciso.

PDF

Introducción

El startup —o compañías emergentes—, según la revista digital universitaria de la UNAM, son un modelo de empresas con un alto nivel de proyección debido principalmente al uso de la tecnología en su construcción y desarrollo. Por lo general, son respaldadas por equipos de trabajo apegados al ritmo que demandan los mercados actuales. Estos corporativos cuentan con áreas enfocadas a la innovación llamadas, Software —o Desarrollo—. Dentro de ellas se forman equipos de trabajo multidisciplinarios para cubrir las necesidades del área y que están enfocados en programación, diseño y gestión de equipos, para generar proyectos en común. Estos se ven afectados por procesos tradicionales, limitaciones de tiempo, costo, alcance, calidad, recursos, capacidades organizacionales y demás condicionamientos que dificultan su planificación, ejecución, gestión y éxito. 

En el presente artículo se presenta el caso de una empresa especializada en investigación de mercados en el área de Software en un startup, con las mismas limitaciones antes mencionadas. Por ello se propuso una solución viable, la metodología Scrum; como lo dice uno de sus creadores:

Scrum abraza la incertidumbre y la creatividad. Dota de estructura al proceso de aprendizaje, es lo que permite a los equipos evaluar qué crearon e, igualmente importante, cómo lo hicieron. Scrum se vale del trabajo real en equipo y brinda a este último las herramientas necesarias para organizarse y aumentar en poco tiempo tanto la rapidez como la calidad de su trabajo. (Sutherland, 14)

En ese sentido, es importante que las organizaciones seleccionen e implementen un método apropiado para la gestión de proyectos. En el caso de la implementación exitosa de la metodología Scrum en los equipos de Software dentro de un startup, proporciona considerables beneficios de negocio. 

Con base en lo dicho, el objetivo de este texto es explicar los fundamentos en los que se basa la metodología Scrum, para mostrar su eficiencia aplicada en el caso del área de Software dentro de un startup dedicado a la investigación de mercados. Pero, ¿por qué la metodología Scrum es una solución eficiente en el desarrollo de proyectos digitales en las áreas de Software dentro de una startup? Para el logro del objetivo y responder a la pregunta se plantean los siguientes apartados, el primero es explicar en dónde surge la metodología Scrum, cuáles son sus roles principales y su flujo de trabajo. El segundo describe el caso del área de Software, sus lineamientos y valoraciones, para señalar los beneficios que contiene la metodología Scrum aplicada en el Área dentro de una empresa orientada a la investigación de mercados. Y, al final, se ofrece una respuesta a la pregunta formulada.

1. Antecedentes

La metodología Scrum tiene sus inicios en la década de los 80, cuando Hirotaka Takeuchi e Ikujiro Nonaka —basados en estudios de casos de diversas industrias de fabricación— definieron una estrategia para el desarrollo de productos flexibles. Incluyeron el trabajo en común para el logro de objetivos con un enfoque innovador, al que llamaron holístico o Rugby. Este último se refiere al modo en el que un equipo se desempeña en conjunto para mover el balón por la cancha. El término Scrum se refiere a la formación de los jugadores en el mismo juego. 

Posteriormente, en 1995, Ken Schwaber y Jeff Sutherland retoman el concepto Scrum para el desarrollo de software. Las razones para aplicar esta idea surgen de las investigaciones que Sutherland realizó en diversas compañías del mundo al estudiar y examinar a los mejores equipos de trabajo del planeta, con base en: «… cómo trabaja la gente en realidad no cómo dice trabajar… ¿Qué los volvía superiores? ¿Qué los hacía diferentes? ¿Por qué algunos equipos alcanzan la grandeza mientras otros se estancan en la mediocridad?» (Sutherland, 13) A partir de estos cuestionamientos es que nace la metodología Scrum como una nueva forma de hacer el trabajo de manera ágil, confiable y eficaz. Desde entonces, varios autores y expertos continúan con la mejora de esta metodología.

• Roles principales 

Los pilares de este flujo de trabajo son el Product Owner, Scrum Master, y el Equipo Scrum. Es importante tener en cuenta que ninguno de ellos tiene autoridad sobre los otros. (SCRUMstudy 39)

• Product Owner: es la voz del cliente dentro del equipo, su responsabilidad principal es representar las necesidades del cliente para maximizar el valor del negocio.
• Scrum Master: es un facilitador que asegura que el Equipo Scrum esté dotado de un ambiente propicio para completar con éxito el desarrollo del ‘Producto O’. El Scrum Master, guía, facilita y les enseña prácticas de Scrum a todos los involucrados en el proyecto, elimina los impedimentos que enfrenta el equipo; y asegura que se estén siguiendo los procesos de Scrum. (SCRUMstudy 39)
• Equipo Scrum: grupo de personas o equipos también llamados «Development o Desarrollo», son los encargados de realizar el trabajo de las tareas del Sprint, la estimación, y los entregables en los tiempos establecidos.
• Flujo de trabajo Scrum

El ciclo de Scrum comienza con la preparación, en ella se reúnen el Product Owner y el Scrum Master con las partes interesadas (Stakeholder). El objetivo es definir la visión del proyecto con base en la lista de los pendientes o Backlog que se tienen que atender; se crean historias de usuario que contienen la descripción, los requerimientos y los criterios de aceptación. 

Posteriormente, se lleva a cabo la planeación, aquí se consideran las historias de usuario con alta prioridad, se estiman y se ejecutan en la siguiente etapa, para implementar en el proyecto nombrado Sprint. Este último suele durar entre una y seis semanas, este es llevado por el Scrum Team. En esta fase se efectúa una reunión diaria llamada Daily Standups, en donde los miembros del equipo se encuentran de pie para dialogar sobre el progreso de las tareas. 

Luego, se realiza la revisión; una vez que se concluye el Sprint se reúnen el Scrum Team y el Product Owner con los interesados para verificar si se han cumplido los criterios de aceptación predefinidos de la lista de prioridades. Antes de terminar el ciclo se cumple con otra junta llamada Retrospectiva del Sprint, en ella el equipo presenta modos para mejorar los procesos y el rendimiento a contemplar para el siguiente Sprint. Por último, el lanzamiento, en el que se preparan y envían los entregables a los Stakeholders pertinentes (definition of done). En la figura 1 se muestra una reinterpretación de los procesos propuestos por la Guía SBOKTM. (SCRUMstudy 2)

Figura 1. Flujo de trabajo Scrum desde su preparación hasta el lanzamiento. Fuente: elaboración propia.

• Preparación (Sprint Backlog) 

El proyecto se inicia con la presentación de un caso de negocio (business case), puede ser un documento bien estructurado o simplemente una declaración verbal que expresa la razón para iniciarlo. Puede ser formal y detallado o informal y breve. Independientemente del formato, a menudo incluye información sustancial sobre los antecedentes del proyecto, los objetivos del negocio y los resultados deseados, un FODA y análisis de brechas, una lista de los riesgos identificados, así como las estimaciones de tiempo, esfuerzo y costo. (SCRUMstudy 132)

1.2.2 Planeación (Sprint Planning)

El objetivo de esta etapa es crear, detallar, estimar y aprobar las historias de usuario, a las cuales el Equipo Scrum se pueda comprometer. El Product Owner —basado en su previa interacción con los Stakeholders, en el conocimiento del negocio, en la experiencia y las aportaciones del equipo— desarrolla las historias de usuarios que formarán el Backlog inicial para el proyecto. Esta historia indica tres cosas: quién (un tipo de usuario), qué (una función) y por qué (un beneficio o valor). Estos datos expresados son declaraciones breves, simples y fáciles de entender. (SCRUMstudy 178) Para estimar los tiempos y su viabilidad, las herramientas que se utilizan para el proceso de aprobar, estimar y comprometerse son algunas de las siguientes: planning poker, puño de cinco o con puntos de estimación.

• Implementar (Daily Standups)

Para llevar a cabo el desarrollo de las historias de usuario y dar seguimiento a los estados de las tareas, los miembros del Equipo Scrum mantienen al tanto a sus compañeros por medio de una reunión de corta duración (con límite de 15 minutos) llamada Daily Standup; se le denomina así porque los miembros están de pie durante toda la sesión. Los miembros del equipo discuten logros y la experiencia de trabajo del día anterior. (SCRUMstudy 2006) Se espera que todos los miembros del Equipo Scrum asistan; sin embrago, no se cancela o se retrasa si uno o más miembros no pueden asistir. En la reunión cada miembro del Equipo Scrum proporciona respuestas a las tres preguntas diarias: 

• ¿Qué terminé ayer? 
• ¿Qué voy a terminar hoy? 
• ¿Qué impedimentos u obstáculos (si los hay) estoy enfrentando en la actualidad?

Al centrarse en estas tres preguntas todo el equipo puede tener una comprensión clara de la situación laboral. En ocasiones, otros elementos pueden ser discutidos, pero esto se reduce al mínimo para respetar el aspecto del tiempo de la reunión. Es muy recomendable que las dos primeras preguntas, si es posible, se respondan de manera cuantificable en lugar de respuestas largas y cualitativas. Los miembros del equipo pueden organizar reuniones adicionales para hacer frente a los aspectos que necesitan un análisis o intervención adicional. (SCRUMstudy 206)

Con el fin de mostrar el progreso de trabajo se utiliza una herramienta abiertamente visible para el Scrum Board, que muestra el progreso del equipo. Sirve para planificar y realizar un seguimiento de los progresos realizados durante cada Sprint. El tablero contiene cuatro columnas principales en las que se indican los avances de las tareas estimadas para el Sprint: primera columna, ‘To Do’ (Por Hacer), para las tareas aún no iniciadas; segunda columna, ‘In Progress’ (En curso), para las tareas iniciadas pero que no se han terminado; tercera columna, ‘Testing’ (Prueba), aquí se colocan las tareas completadas que en el proceso requieren pruebas para validarlas; cuarta la columna, ‘Done’ (Hecho) se refiere a las tareas que se han completado con éxito y han sido aprobadas. (SCRUMstudy 200). En la figura 2 se puede ver una representación gráfica del Scrum Board, en la que cada tarea se mueve hacia adelante en función de su progreso.

Figura 2. Scrum Board. Fuente: elaboración propia.

1.2.4 Revisión (Review)

Los miembros del Equipo Scrum, junto con los Stakeholder correspondientes participan en la reunión de revisión del Sprint, para aceptar los entregables en acuerdo con los criterios de aceptación de la historia del usuario; aquí se rechazan las entregas inaceptables. Estas reuniones son convocadas al final de cada Sprint. El Equipo Scrum demuestra los logros e incluyen las nuevas funcionalidades o productos creados. 

Este momento proporciona una oportunidad para que el Product Owner y el/los Stakeholder(s) inspeccionen lo que se ha completado hasta el momento y determinen si algún cambio se debe hacer en el proyecto o procesos en Sprints posteriores. (SCRUMstudy 221)

1.2.5 Retrospectiva (Sprint Retrospective)

La reunión de la Retrospectiva del Sprint es un elemento importante dentro de Scrum llamado ‘inspeccionar–adaptar’, es el paso final en un Sprint. Todos los miembros del Equipo Scrum asisten a la reunión, que es facilitada o moderada por el Scrum Master. Se recomienda, pero no se requiere, que el Product Owner asista. Un miembro del equipo documenta las charlas y los elementos para acciones futuras. Es esencial tener esta reunión en un ambiente abierto y relajado para obtener la participación de todos los miembros del equipo. 

Los debates en la reunión de la Retrospectiva del Sprint abarcan tanto lo que salió mal como lo que salió bien. Los objetivos principales de la reunión se centran en identificar tres elementos específicos: 

• Las cosas que el equipo tiene que seguir haciendo: mejores prácticas. 

• Las cosas que el equipo necesita empezar a hacer: mejoras en el proceso.

• Las cosas que el equipo necesita dejar de hacer: problemas de proceso y embotellamiento. (SCRUMstudy 224)

En esta reunión se presentan al equipo: mejores prácticas, lecciones aprendidas de los errores cometidos durante el Sprint, registro de las opiniones, discusiones y artículos planteados, detección de los elementos no funcionales en el backlog, mejoras acordadas, métricas y técnicas de medición como la velocidad del equipo, porcentaje de tareas realizadas, discrepancia entre el tiempo previsto y el tiempo verdadero que se ha utilizado en las tareas e historias de usuarios, retroalimentación 360 de los compañeros, calificación moral del equipo, información crítica y constructiva sobre el rendimiento del equipo; así como el valor representado por el progreso actual hacia una liberación. Esto contribuye a la motivación y al nivel de satisfacción en el trabajo. 

1.2.6 Lanzamiento (Definition of Done)

En este proceso se realiza el envío de los entregables aceptados a los Stakeholders pertinentes, de manera formal se documenta la finalización con éxito del Sprint. Es importante crear entregables basados en valor y enfocados en las prioridades determinadas del proyecto durante y al final del Sprint. De esta forma los clientes validan la importancia que juegan los equipos en las áreas al implementar Scrum.

Dentro del proceso de la metodología Scrum se recomienda realizar los pasos antes expuestos en el orden en el que se han marcado. Lo planteado aquí es un escenario ideal; sin embargo, para que esto sea así se sugiere que dentro del equipo exista el rol de un Scrum Master, quien conoce las fases, los principios y los aspectos del marco de trabajo. También, considerar que es un marco adaptativo, por lo tanto, se ajusta a los cambios que requieran una prioridad urgente, sin que esto afecte a los miembros del equipo. Son fundamentales, la colaboración de los participantes con empatía y trabajo en equipo, la verificación de que las necesidades del área sean idóneas; si el equipo está preparado para una metodología ágil o si los miembros lo sugieren, como lo veremos en el siguiente tema. 

• Metodología Scrum aplicada en el área de Software dentro de un startup

Hoy en día los startups dedicadas a diferentes sectores ofrecen sus productos o servicios dentro de un sitio web para implementar este modelo de negocio. Detrás de ello, y dentro de cada organización, existen grupos de trabajo multidisciplinario llamados áreas de Software, Development o Desarrollo. La demanda de trabajo en estas áreas requiere de agilidad, los métodos tradicionales ya no son funcionales debido a las necesidades y a la rapidez que exige la tecnología actual. Como lo dice Schwaber: “… lo tradicional solo da seguridad a la dirección de que tenemos el control del proceso de desarrollo.” (Sutherland 16) Sin embargo, a la hora de ejecutar el trabajo se rebasa en tiempo, trabajo, esfuerzo y presupuesto, sin lograr los objetivos planteados.

Es importante para una organización llevar a cabo una evaluación apropiada del negocio antes de comenzar un proyecto. Esto ayuda, a quienes toman decisiones, al entendimiento sobre la necesidad de cambio en la empresa o de un nuevo producto o servicio. Dentro de este cálculo se toman en cuenta: el método de trabajo, cómo gestionar a los equipos, cómo obtener resultados óptimos; el tiempo, los recursos, los procesos, etc. Al elegir una metodología ágil se tiene que verificar si la cultura de la organización está preparada para ello. La metodología Scrum cuenta con lineamientos que se presentan para su buen funcionamiento, transparencia, inspección, adaptación, auto–organización, colaboración; para ofrecer el máximo valor y utilizar el tiempo eficazmente. Así como para generar un desarrollo iterativo que permita crear productos que satisfagan las necesidades del cliente. Contiene también valoraciones fundamentales para la compañía, como la organización, la justificación del negocio, la calidad y el cambio. Tanto como para los equipos y la compañía, tomar en cuenta estos datos puede ser de alto valor para la implementación la metodología Scrum. Aquí se describe el caso de un startup que realizó el proceso y la evaluación con éxito. 

2.1 Caso del área de Software dentro un startup

En el 2013 nace un startup dedicado a la investigación de mercados, cuyo objetivo principal fue obtener ventas directas a través de su plataforma. Con la necesidad de actualizar, refrescar y volverla atractiva para el 2019 se plantearon metas a nivel empresa, un punto clave a consolidar para este fin fue el área de Software con equipos auto–responsables. 

Dentro del grupo la organización presentaba situaciones complejas con demora en los tiempos de entrega, resultados desalentadores, frustración en cada uno de los integrantes del equipo, restricciones, desafíos y oposiciones respecto a la forma de producción. De ahí surgió la necesidad de incorporar una metodología ágil como una solución a lo antes expuesto. Posteriormente, los miembros del equipo afinaron y buscaron nuevas formas de concebir el trabajo por medio de la metodología Scrum, con el fin de agilizar sus procesos con menos personas, en el menor tiempo posible, con mejor calidad, menos costo y resultados óptimos. Cabe decir que la compañía decidió implementar la metodología Scrum únicamente en el área de Software y, para fortalecer el proceso con buenas prácticas, se necesitó incorporar la figura de un Scrum Master. 

De ahí se puso en práctica la metodología sobre la organización. Se efectuó la primera reunión clave con el Scrum Master, el Product Owner y los interesados, para la preparación de los requerimientos ejecutados durante el Sprint, con una duración de dos semanas. Dentro del procedimiento los miembros del equipo se dieron a la tarea de realizar los Standups todos los días y con responsabilidad; estos momentos diarios fueron de ayuda para evitar retrasos y confusiones al momento de liberar el trabajo. Después, llegó la etapa de revisión en donde se llevó a cabo una junta, en la que se incluyeron a todos los involucrados y se abrieron debates de trabajo para futuras mejoras. Al finalizar se efectuó la retrospectiva, este espacio funcionó para expresar el estado de ánimo, tanto personal como profesional de los miembros del equipo; se incentivó la motivación para continuar con el proyecto y abrir el camino a la comunicación. Cabe señalar que esta última etapa fue prioritaria para la colaboración del equipo, dónde las opiniones y las entregas fueron reconocidas por la compañía. 

Para llevar el registro de este proceso, el área de Software hizo uso de dos herramientas: la primera, Azure DevOps, sirvió para la gestión de los proyectos, ahí se registraron los roles, las historias, las tareas y los puntos de estimación. Los avances se visualizaron en un tablero a manera de gráficas, con ello el equipo contó con una forma de medir el desarrollo y los resultados (imagen 1).

Imagen 1. Azure DevOps, Herramienta para la gestión de proyectos de desarrollo de Software. Fuente: Twitter @AzureSupport. <URL>

La segunda herramienta fue un documento de Excel llamado Burndown Chart, que es una representación gráfica de la estimación del trabajo y del tiempo; ayuda a comparar las horas de trabajo ideal con el trabajo real. Esto permite tener una perspectiva del desarrollo de un proyecto en un plazo determinado (imagen 2).

Imagen 2. Burndown Chart,  Representación gráfica del trabajo por hacer en un proyecto medido por puntos y tiempo. Fuente: Plantilla Excel del Burndown Chart de Capterra. <URL>

Puesto en práctica el proceso Scrum —junto con las herramientas antes citadas— hubo un incremento en la productividad, la colaboración, el logro de objetivos y sensación de menos carga de trabajo; así como equipos motivados para continuar en crecimiento. Esto último es de gran importancia en el desarrollo de proyectos digitales en diferentes áreas laborales en las que se unen y se cumplen las necesidades personales, profesionales y empresariales. 

Pero: ¿por qué esta metodología Scrum fue exitosa en su implementación dentro de este startup? ¿Qué fue lo que volvió al área de Software un equipo auto–organizado? Con la ayuda de los lineamientos y valoraciones efectuadas se mantuvo estable a la metodología Scrum dentro del equipo, que se revisará posteriormente.

• El equipo y la cultura organizacional

¿Cómo hace un startup para poner en marcha una metodología que no había llevado a cabo antes, así como para los miembros del equipo sin experiencia alguna? Esa es la pregunta que se presentó en el Área al proponer una nueva forma de ejecutar el trabajo. Al principio fue un desafío implementar un enfoque ágil, ya que implicaba flexibilidad en los tiempos de entrega ya calendarizados; sin embargo, era necesario hacer una pausa para hacer este acoplamiento. Dentro de ello se identificaron dos categorías para ajustarse a este nuevo modelo: el equipo y la cultura organizacional. De ahí comenzó a elaborarse un plan con las necesidades requeridas por ambos.

• El equipo

El área de Software está conformada por un equipo de seis a siete miembros: un líder de proyecto, dos desarrolladores backend, dos frontend y un diseñador UX-UI, cuyo objetivo es el de generar soluciones que simplifiquen los procesos de desarrollo dentro el startup. El desempeño de esta área se encontraba en un 50% a 60% de capacidad, antes de la aplicación de la metodología Scrum. Existían atrasos, un clima disperso, poca comunicación de las necesidades por parte del líder hacia los integrantes del equipo. Esto último representaba un reto importante, ya que uno de los factores principales para el éxito de la aplicación era tener a todo el grupo dedicado completamente a este tipo de operación. Finalmente se obtuvo estabilidad por medio de la práctica y al conocer, aprender y entender el desarrollo de un producto, la metodología Scrum, así como a sus mismos compañeros.

Cabe señalar que la metodología Scrum se centra en los equipos, así como

en su forma de trabajar y la colaboración es de vital importancia, ya que quienes ejecutan las tareas del día a día. Los integrantes comprometidos que quieren alcanzar resultados óptimos tienen un propósito más allá de lo normal, esta meta de realización grupal les permite pasar de lo ordinario a lo extraordinario. Esto genera buenos equipos auto–organizados que se gestionan solos y con el poder para tomar sus propias decisiones sobre la forma en la que realizan sus funciones. 

• La cultura organizacional

Dentro de la organización se puso en marcha la metodología Scrum sobre el área de Software, en la que su manera de desarrollar el trabajo es una mezcla entre el modelo tradicional y lo ágil, puesto que es un startup con ideas de cambio constante. De ahí es que surgieron estas adecuaciones entre el equipo y la cultura de la compañía, con el objetivo de generar una cultura de éxito, a través de procesos eficientes tanto a nivel interno como para sus clientes. 

Los aspectos importantes de la cultura dentro de esta startup dedicada a la investigación de mercados son: valores, alto rendimiento y alinación, así como el no control. Su base, la integridad, comunicación, respeto y excelencia. Sus valores principales son: honestidad, transparencia, excelencia, innovación, agilidad, simplicidad, valor agregado, pasión y curiosidad, por mencionar algunos. 

Como efecto de este acoplamiento por medio de Scrum es que aparecieron los siguientes desafíos, culturales y del equipo:

• Cambio de un modelo tradicional a un método ágil en la gestión de los proyectos. 

• Modificación en la gestión de tiempos, entregas y costos de estimación del trabajo realizado.
• Obtención de equipos autodirigidos en entornos de constante cambio.
• Asimilación de conocimientos sobre la metodología Scrum por parte del equipo, la startup y los líderes principales.
• Comunicación errónea para realizar las actividades. 
• Los miembros del equipo se sentían abrumados por las cargas excesivas de trabajo con resultados desalentadores. 

Dadas estas oposiciones se propuso y se ejecutó un plan de acción con los siguientes componentes clave:

• Supresión de la estructura del modelo tradicional por un ambiente ágil, adaptado a requerimientos dinámicos, iteraciones en los diseños y en los productos.
• Capacitaciones al Equipo Scrum para explicar los conceptos, procesos, lineamientos y valoraciones. 
• Exposición a nivel empresa del flujo de trabajo del área de Software para mostrar avances, aportaciones y beneficios que hay en las entregas.
• Reuniones semanales, para mostrar avances de la compañía, del equipo, así como del desempeño individual.
• Se incorporó el recurso de un Scrum Master con conocimientos de la metodología Scrum con el fin de demostrar los beneficios.
• Se otorgó una vez por semana home office, para equilibrar las cargas de trabajo, lo que ayudó poco después como recurso durante la pandemia.
• Eliminación de documentación excesiva.
• Creación de Sprints cortos, de dos semanas, para tener una rápida adaptación con la ayuda de herramientas digitales. 

Esta integración del equipo con la cultura junto con las soluciones dadas resultó favorable, tanto para el área de Software, el Scrum Team y la startup, como para los clientes finales.

• Lineamientos 

Ya hemos hablado del flujo de Scrum y de cómo se implementó con éxito dentro de un startup en el área de Software y, con la finalidad de asegurar los fundamentos indispensables para su ejecución, se especifican los lineamientos o principios que le sirven de sostén. Cuando este método se puso en práctica dentro la compañía en dicha área se empleó el uso de seis principios que propone la guía SCRUMstudy. (SCRUMstudy 9) A continuación se explican:

1. A) Control del proceso empírico

En Scrum las decisiones se basan en la observación y se apoya en tres ideas principales: transparencia, inspección y adaptación. Estos pilares son importantes para el equipo, la compañía y los proyectos. La transparencia busca que los implicados tengan conocimiento de lo que ocurre en el proyecto y de cómo se desarrolla, esto hace que haya una visión global. La inspección promueve que los miembros del equipo frecuentemente inspeccionen el progreso para detectar posibles problemas; esto no es un examen diario, sino una forma de saber que el trabajo fluye y que el equipo funciona de manera auto–organizada. Por último, la adaptación es necesaria cuando hay algo que cambiar y el equipo se ajusta para conseguir el objetivo del Sprint; es la clave para conseguir el éxito en proyectos complejos, en donde los requisitos son cambiantes o poco definidos y la adaptación, la innovación, la complejidad y flexibilidad son primordiales.

1. B) Auto–organización

Se cree que los empleados que se auto–motivan aceptan mayores responsabilidades, entregan un valor significativo cuando son auto–organizados, lo cual resulta en equipos con un gran sentimiento de compromiso y responsabilidad; a su vez, esto produce un entorno innovador y creativo que es más favorable para el crecimiento. 

1. C) Colaboración

Se refiere a que el equipo principal de Scrum trabaja e interactúa con los Stakeholders para crear y validar los resultados del proyecto con el fin de cumplir con los objetivos que se plantean en la visión del proyecto. 

1. D) Priorización basada en el valor

Se guía con la finalidad de ofrecer el máximo valor del negocio en un mínimo periodo de tiempo. Una de las herramientas más eficaces para entregar el mayor valor en el menor tiempo posible es la priorización, que se puede definir como la determinación del orden y la separación de qué debe hacerse ahora y de lo que debe hacerse después. Este es un principio básico que impulsa la estructura y funcionalidad de todo el marco de Scrum. 

1. E) Time–boxing

Aquí se trata al tiempo como una de las limitantes más importantes en la gestión de un proyecto. Para hacer frente a la restricción del tiempo, Scrum introduce el concepto Time–boxing (o asignación de un bloque de tiempo), que propone la fijación de cierta temporalidad para cada proceso y actividad en un proyecto. Esto garantiza que los miembros del equipo no ocupen demasiado o muy poco tiempo para un trabajo determinado; que no lo desperdicien ni tampoco gasten energía cuando se tienen poca claridad. Los elementos que participan en el Time–boxing son: la planificación, Standups y la revisión del Sprint.

1. F) Desarrollo iterativo

Aquí se enfatiza en cómo manejar mejor los cambios y crear productos que satisfagan las necesidades del Cliente. (SCRUMstudy 21) El beneficio del desarrollo iterativo permite la corrección y una mejor comprensión del proyecto al incorporar las variantes para alcanzar un punto de entregables exitosos. 

Mantener los principios intactos y usarlos apropiadamente infunde confianza en los usuarios del marco de Scrum con respecto al logro de los objetivos del proyecto. Estos lineamientos puestos en práctica dentro del desarrollo del proceso metodológico, brindan: claridad, información y buenas prácticas a los integrantes de los equipos, auto–organización, intención de colaborar y priorización de las actividades para generar valor, todo sostenido en un control de tiempo para no tener reuniones excesivas si no concretas; además, se aceptan las iteraciones con el fin de conseguir una mejora continua. En la figura 3 se observa el esquema de principios Scrum que durante la ejecución del proyecto–metodología deben mantenerse presentes. (SCRUMstudy 9)

Figura 3. Principios SCRUM. Fuente: elaboración propia.

Estos lineamientos se pueden aplicar a cualquier tipo de proyecto u organización y deben ser respetados con la intención de garantizar la aplicación apropiada de la metodología Scrum.

• Valoración  

Con el propósito de obtener un panorama general, en el principio y durante el desarrollo de un proyecto con la metodología Scrum, se sugiere tener en cuenta las siguientes consideraciones:

Primero, la organización —como ya lo hemos mencionado— que se centra en entender los roles y responsabilidades que cada integrante tiene para afianzar la exitosa implementación de Scrum. Segundo, la justificación de negocio, muestra los motivos por los cuales se realiza un proyecto, responde a la pregunta: ¿por qué se necesita este proyecto? Esto ayuda a quienes toman decisiones a entender la necesidades de la empresa o de un nuevo producto o servicio. Tercero, la calidad, en Scrum esta se define como la capacidad con la que cuentan el producto o los entregables para cumplir con los criterios de aceptación y alcanzar el valor de negocio que espera el cliente. (SCRUMstudy 14)

Para garantizar que un proyecto cumpla con los requisitos de calidad, Scrum adopta un enfoque de mejora continua en donde el equipo aprende de sus experiencias y de la participación de los Stakeholders para mantenerse en constante actualización ante cualquier cambio en los requerimientos. También los debates constantes entre el Equipo Scrum y los Stakeholders (incluyendo los clientes y los usuarios) reducen la confusión entre las expectativas y los verdaderos requerimientos.

El cuarto, el cambio, cada proyecto, independientemente de su método utilizado, está expuesto a ello. Es importante que los miembros del equipo del proyecto entiendan que los procesos de desarrollo de Scrum están diseñados para aceptar el cambio. (SCRUMstudy 14) Al reconocer que los interesados pueden cambiar de opinión acerca de lo que quieren y necesitan durante el curso del proyecto o que pueden no definir con exactitud los requisitos al inicio. Scrum, mediante el uso de Sprints cortos e iterativos, incorpora la retroalimentación del cliente sobre los entregables, esto permite que se interactúe regularmente con los miembros del Equipo Scrum. Lo anterior posibilita ver el trabajo a medida que esté listo y, si existen mejoras, sean detectadas de manera temprana en el ciclo de desarrollo.

Y el quinto, el riesgo que se define como un evento incierto o conjunto de eventos que pueden afectar a los objetivos de un proyecto y contribuir a su éxito o fracaso. (SCRUMstudy 15) A los riesgos pueden tener un impacto positivo en el proyecto se les conoce como oportunidades, mientras que las amenazas son riesgos que podrían afectar al proyecto de una manera negativa. La gestión del riesgo debe hacerse de forma preventiva y es un proceso iterativo que debe aplicarse al inicio y continuar a lo largo del ciclo de vida del proyecto. 

Con lo dicho se ha logrado mostrar los componentes de este marco metodológico, Scrum, en sus tres partes: flujo de trabajo, lineamientos y valoraciones suficientes para poder funcionar. Al ser aplicada dentro de un área de Software al interior de un startup se puede considerar exitoso debido a la aplicación de estos tres momentos que Scrum ofrece dentro del desarrollo de productos digitales y que requieren resultados superiores a la demanda del mercado actual. 

En cuanto a los resultados obtenidos durante este proceso, con la integración de la metodología Scrum se logró el objetivo principal ya abordado, a nivel externo se actualizó el sitio en un 90 % en menos de un año de trabajo colaborativo. Internamente, el negocio estableció un importante programa para gestionar las tareas de la compañía; recordemos que esta herramienta se desarrolló dentro del área de Software. A nivel equipo, los resultados se dieron de forma favorable, ya que, al aceptar los cambios y la incertidumbre, y gracias al aprendizaje de los errores incluidos como aciertos en una mejora continua. La disposición del equipo resultó de mente abierta, lo que ofreció un abanico de posibilidades al reconocer que conforme avanzaba la metodología —con la medición de los riesgos, la aplicación del proceso y la previa evaluación de los aspectos— se obtuvieron los siguientes resultados benéficos:

• Flexibilidad
• Transparencia 
• Retroalimentación 
• Colaboración
• Mejora continua
• Entregas de valor 
• Ritmo sostenible 
• Productividad
• Proceso de desarrollo eficiente 
• Motivación 
• Resolución de problemas
• Entregables efectivos 
• Proyectos centrados en el cliente y usuario
• Entorno de confianza 
• Ambiente innovador

Los elementos resultantes son de alto valor para los startups dedicados a cualquier sector que haga uso de la tecnología y requiere de la gestión de sus equipos de Software, así como esta compañía dedicada a la investigación de mercados tuvo resultados con una gran ventaja competitiva y con el objetivo de seguir en constante evolución. 

Conclusiones

La conclusión de este artículo responde a la pregunta inicialmente formulada: ¿por qué la metodología Scrum es una solución eficiente en el desarrollo de proyectos digitales en las áreas de Software dentro de un startup? La respuesta es positiva debido a que Scrum desde su concepción se ha pensado como una nueva forma de ver el trabajo, en el cual se eliminan las jerarquías para: abrir espacio a la colaboración activa de los equipos, adaptarse al cambio y ofrecer resultados ágiles que van de acuerdo con la demanda de productos tecnológicos; un requerimiento de las los startups actuales, en comparación con modelos tradicionales. Esto ha sido fundamental para el éxito del caso expuesto. 

Fue posible también detectar que para implementar la metodología Scrum es necesario identificar y entender el rol de cada miembro del equipo dentro de la organización; estos tres roles son responsables de cumplir con los objetivos del proyecto: Product Owner (Voz del cliente), Scrum Master (Guía o facilitador) y el Equipo Scrum (Desarrollo).

Recapitulando, el flujo de trabajo Scrum nos proporciona una perspectiva de su desarrollo, con la finalidad de conseguir entregables de alto valor para el cliente, que va desde la preparación hasta su lanzamiento. Primero la reunión del Product Owner, el Scrum Master y las partes interesadas, definen la visión del proyecto con base en la lista de pendientes. Posteriormente, se lleva a cabo la planeación, en la que se consideran las historias de usuario con alta prioridad, se estiman y se ejecutan en el proyecto nombrado Sprint, que suele durar entre una y seis semanas, y que es llevado por el Scrum Team. En esta fase se efectúa una reunión diaria llamada Daily Standups donde los miembros del equipo se encuentran de pie para dialogar sobre el progreso de las tareas. Luego se lleva a cabo la revisión, una vez que se concluye el Sprint se reúnen el Scrum Team con el Product Owner y los interesados para verificar si se han cumplido los criterios de aceptación predefinidos en la lista de prioridades. Antes de terminar el ciclo se cumple con otra junta, llamada Retrospectiva del Sprint y en la que el equipo presenta modos para mejorar los procesos y el rendimiento a contemplar para el siguiente Sprint. Por último, el lanzamiento, en el que se preparan y envían los entregables a los Stakeholders pertinentes.

Otro eje primordial que confirma la efectividad de Scrum son los lineamientos, estos dirigen principalmente a la transparencia, inspección y adaptación. Primero, la auto–organización, en la que se cree que los empleados que se auto–motivan, aceptan mayores responsabilidades y entregan un valor significativo. Segundo, la colaboración, se refiere a que el equipo principal de Scrum trabaja e interactúa con los interesados. Tercero, priorización basada en el valor, se guía con la finalidad de ofrecer el máximo valor del negocio en un mínimo periodo de tiempo. Cuarto, Time-Boxing, se trata al tiempo como una de las limitaciones más importantes en la gestión de un proyecto. Por último, desarrollo iterativo, enfatiza en cómo manejar mejor los cambios y crear productos que satisfagan las necesidades del cliente.

También, la metodología Scrum nos enseña a tomar en consideración algunas valoraciones como:

• La organización: entender los roles y responsabilidades de cada integrante.
• La justificación de negocio: responde a la pregunta: ¿por qué se necesita este proyecto?
• La calidad: se adopta un enfoque de mejora continua.
• El cambio: los miembros del equipo entienden que los procesos de desarrollo de Scrum están diseñados para aceptar el cambio.
• El riesgo: se define como un evento incierto o conjunto de eventos que pueden afectar a los objetivos de un proyecto y pueden contribuir a su éxito o fracaso.

Los hallazgos de la presente investigación evidencian que la metodología Scrum no solo es un proceso de trabajo lineal, sino un marco íntegro en el que cada individuo dentro del área tiene una participación activa e iterativa. Enseña a mantener una mente abierta, adaptable y que aprende de los errores. Así mismo, sugiere un cambio de cultura tanto personal, de equipo y organizacional. También, por ser un método flexible, se puede utilizar, tanto en áreas Software o startups como en diferentes sectores. Otro tema principal es el presupuesto, Scrum puede funcionar sin herramientas adicionales como Azure, que se utilizó dentro de la startup para gestionar el trabajo, pero que de otro modo se puede hacer uso del Scrum Board si no se cuenta con las licencias convenientes.

Como ya lo hemos visto, el objetivo se pudo cumplir con los temas centrales que ofrece este estudio, desde los antecedentes, los roles principales, flujo de trabajo, el caso de áreas de Software y los lineamientos y valoraciones. Con ello se visibilizan los beneficios de la aplicación de la metodología Scrum dentro de un startup. Sin embargo, este trabajo podría enriquecerse con temas enfocados principalmente en los equipos de trabajo Scrum como: ¿qué motiva a los equipos Scrum? ¿Qué tipos de personalidad son recomendados para cada rol Scrum? ¿Cómo se aplica Scrum a grandes corporativos? Y, ¿cómo es Scrum en una PYME?

Fuentes de consulta

Herández, Carla. “Startup”. Economipedia, Haciendo fácil la economía. Creative Commons. Web. 20-12-21. <URL>

Revista Digital Universitaria. “Startups, modelo para una economía emergente y creativa”. Revista Digital Universitaria. Enero 2014: 4. Revista UNAM. Web 28-11-21. <URL>.

Sutherland, Jeff. Scrum. El arte de hacer el doble de trabajo en la mitad de tiempo. México: Océano de México, 2014. Impreso.

SCRUMstudy. Cuerpo de conocimiento de Scrum (Guía SBOK). Phoenix, Arizona.VMEdu, Inc. 2016. SCRUMstudy. Web 28-11-21. <URL>.

Imagen 1. Azure DevOps, Herramienta para la gestión de proyectos de desarrollo de Software. 2019. Screenshot. Twitter @AzureSupport. Web 07-01-2022. <URL>

Imagen 2. Burndown chart,  Representación gráfica del trabajo por hacer en un proyecto medido por puntos y tiempo. 2019. Screenshot. Plantilla Excel del burndown chart. Capterra. Madrid, España. Web 07-01-2022. <URL>

Semblanza

Wilibaldo Tolentino Corona.

Formación académica: licenciado en Diseño Digital por ICONOS, Instituto de Investigación en Comunicación y Cultura. Además, cuenta con certificado Scrum Fundamentals por SCRUMstudy, ha cursado diversos cursos como: Diseño UX por le wagon, Diseño de producto digital Lean y UX por Domestika, Diseño UX/UI y Copywriting por Platzi, Scrum: Gestionando equipos de trabajo por Crehana, entre otros.

Actividad laboral: ha trabajado en tres áreas del Instituto Nacional Electoral como Diseñador UX/UI, Diseñador instruccional y Arquitecto de información, Diseñador UX/UI en Atlantia Search, Creación de identidad visual para Partidos Políticos. Su trabajo abarca en la creación de Wireframes, Arquitectura de información, Interacción, Copywriting, Research, Metodologías ágiles, entre otros.

Correo: tolentinocorona@gmail.com