¿Puede tu organización IT adoptar la metodología SCRUM como marco de trabajo?

De acuerdo con el reporte anual de “State of Agile 14th”- un estudio efectuado por la compañia CollabNet donde se analizan las tendencias, herramientas y lecciones aprendidas en la adopción de Agilidad en la industria del Software  en el 2020 - un 76% de las organizaciones encuestadas utilizan el proceso Scrum o alguna variación del mismo como marco de trabajo a la hora de desarrollar softwares. Año a año este número continúa creciendo, dejando en evidencia que este ágil marco de trabajo es el más elegido por las organizaciones de IT.

A lo largo de este artículo analizaremos las 4 dimensiones que toda organización debe atravesar a la hora de decidirse por implementar el método SCRUM para desarrollar un nuevo mecanismo dinámico y ágil a la hora de desarrollar softwares

Estas dimensiones son:

  • El contexto organizacional.
  • Los intérpretes del Equipo Scrum.
  • La Cultura DevOps.
  • El Cliente.

Es importante destacar que el hecho de no contar con alguna de ellas, no significa que este marco de trabajo no pueda ser adoptado, sino que se obtendrán éxitos parciales. Por ejemplo habrá una mejora en la moral de equipo, pero no habrá entrega sostenida a nuestros clientes tendremos un time-to-market óptimo pero nuestros productos o servicios no contarán con la calidad esperada, o se detectarán cuellos de botella en los procesos pero no se podrá accionar sobre ellos. 


¿Qué es el marco de trabajo Scrum?

Antes de comenzar a analizar estas preguntas, es importante ponernos de acuerdo en qué es Scrum. 

Scrum no es otra cosa que un framework de trabajo empírico utilizado para implementar agilidad a un nivel táctico, basado en la mejora continua y la entrega de valor (aquello que nuestro cliente está esperando) en forma iterativa e incremental a través de time-boxes denominados Sprints. 

Existe una paradoja con SCRUM, que yo considero muy valiosa, y es que es lo suficientemente abierto para dejarnos adoptar herramientas, procesos, metodologías y tecnologías de otros frameworks (TDD, DDD, Design Thinking, Lean Inception, Event Storming, Pair Programming, etc), pero también lo suficientemente restrictivo como para tener reglas que deben respetarse para asegurar su efectividad. Es simple de entender, y difícil de implementar, como todo lo referente a la agilidad.

Habiendo definido qué es Scrum en el marco de este artículo, procederemos a analizar cada uno de los puntos mencionados.


El contexto organizacional:

No es posible aplicar Scrum sin tener un contexto organizacional que lo apoye: cultura, estructura y procesos deben converger en un entorno que nutra y dé soporte a la implementación de cualquier framework o metodología Ágil.

Tanto la estructura como los procesos deben ser lo más flexibles y dinámicos posibles para permitir la evolución de la organización. 

En cuanto a la cultura, Scrum utiliza el empirismo como proceso de control, por lo que la experimentación debe jugar un papel clave dentro la cultura organizacional. Otro rasgo importante debe ser la colaboración. Ya sea dentro del equipo de Scrum o hacia el resto de la organización, la colaboración es fundamental para asegurar el éxito.


Los intérpretes del equipo Scrum

Scrum entiende únicamente de 3 roles: 

El Product Owner, quién es responsable de crear y transmitir la visión del producto al equipo de desarrollo. Es el que conoce el “Qué” hay que hacer, y el “Para qué” y se ocupa de compartirlo con el resto del equipo. En última instancia, es quien maximiza la entrega de valor.

El Desarrollador quien, en conjunto con otros desarrolladores, forman el Equipo de Desarrollo. Estos equipos suelen ser multidisciplinarios, ya que deben contar con todas las habilidades necesarias para poder materializar la visión del producto de manera independiente del resto de la organización. Son los que determinan, en forma colaborativa, “Cómo” se va a hacer lo que hay que hacer.

Y por último, tenemos el rol del Scrum Master, quien guía a través de Scrum al Product Owner y al Equipo de Desarrollo por un camino hacia la autoorganización y la alta productividad. Es quien remueve los impedimentos externos para que el equipo mantenga el foco en lo realmente importante. Además, se encarga de asegurar el proceso de mejora continua dentro del equipo.

Tanto el Product Onwer como el Scrum Master son los líderes serviciales del equipo Scrum. Este tipo de líder se caracteriza por estar a disposición del equipo para todo lo que necesiten. Distribuyen el poder hacia los demás rompiendo cualquier tipo de jerarquía que pueda existir. Por eso es importante que ambos roles tengan la empatía para entender cómo las tareas y responsabilidades de uno afectan y se alimentan directamente de las del otro, para en conjunto, con el equipo de desarrollo, crear esa sinergia tan necesaria para poder entregar valor en forma continua y sostenida a nuestros clientes.


Cultura DevOps

Como explicamos antes, la entrega de valor en forma sostenida y continua es una de las características de Scrum. Y esta no es posible de alcanzar sin una cultura DevOps fuerte que nos apoye en pos de conseguir esto.

¿Pero qué significa el término “Cultura DevOps” y cuál su relación con Scrum?

Simplificando el concepto, podemos decir que “Cultura DevOps” es un conjunto de prácticas colaborativas que buscan acortar la distancia entre las áreas de Desarrollo y Operaciones, con el objetivo de crear productos y servicios que sean fácilmente sostenibles y de rápido despliegue en entornos accesibles para nuestros clientes. No es una cultura en sí, sino una metodología de trabajo, pero que requiere de un alto alineamiento organizacional para poder conseguirlo.

Por otro lado, Scrum trabaja de manera iterativa e incremental, entregando incrementos de productos al finalizar cada Sprint. ¿Pero cómo podemos disponibilizar estos incrementos hacia nuestros clientes si no fueron desarrollados a través de esta metodología? Todo el equipo de desarrollo debe adoptar este conjunto de prácticas para agilizar el ciclo de feedback con el cliente. 


El Cliente

¿Qué rol tiene el cliente en nuestro proceso de desarrollo? Ya sabemos que mientras más cerca de los equipos esté el cliente, más fácil será interpretar sus inquietudes y necesidades. ¿Pero es esto suficiente? 

Aquí aparece otro concepto importante que es el de la escucha activa y la cultura del feedback. La organización debe estar abierta a recibir un feedback en todo momento y tomarlo como una oportunidad de mejora permanente para, de esta forma, reforzar el vínculo entre ambas partes. La escucha activa es importante en todos los niveles de cualquier organización que quiera adoptar algún framework de trabajo Ágil.


Conclusión

Estas son las 4 dimensiones que pude detectar dentro del contexto de donde me veo involucrado dia a dia. Las 4 deben ser transversales para poder sacar el mayor rédito posible a Scrum, pero probablemente no sean las únicas y dependen del tipo de industria de tu organización y de las formas de tu organización.

El enfoque que dimos en este artículo es desde la perspectiva de una organización IT, para ser más preciso el de una Fintech. Ya sea que tu organización pertenezca al mismo rubro, o no ¿Se te ocurre alguna otra dimensión? ¿Cómo crees que esta metodología se adapta a tu organización?


fintech
scrum
cultura
Por

Gonzalo Iullera

Agile Coach
Publicado el
Jul 24, 2020