Por un Scrum popular, por un mundo mejor

Por un Scrum popular, por un mundo mejor

El mes anterior estuve organizando mis prioridades de lectura, ya que estaba perdiendo un poco el foco debido a las nuevas tareas de este año. Haciendo esa labor me encontré con “Por un scrum popular”, una recomendación de un antiguo compañero de trabajo.

Este libro, escrito por Tobias Mayer & Alan Cyment, publicado en el 2014, llega a las profundidades del framework para invitarnos a cuestionar el mensaje original y contrarrestarlo con prácticas que, según Tobias, han sido más efectivas en diversos escenarios.

Iniciando la lectura se puede llegar a creer que Tobias es un rebelde sin causa, pero pensar esto es completamente erróneo. Sin duda es una persona que desafía las prácticas convencionales del mundo ágil hasta al punto de cuestionar si las convenciones con las que nació Scrum son las correctas.

Si pensamos esto por un momento y aceptamos el hecho de no creer todo lo que nos vende la organización, la idea de Tobias no parece tan descabellada. De hecho, realizar esta práctica para cualquier aspecto de nuestro trabajo nos llevará a profundizar con el fin de conseguir el éxito de nuestros proyectos. De igual forma, Tobias tampoco está satanizando toda la cultura que la organización provee. A mi manera de ver, el mensaje principal de este libro consiste en pensar que Scrum es adaptativo.

El libro basa su argumento en ese mundo empresarial que desea implementar scrum, nos cuenta sobre esa lucha que existe entre la gerencia, que solo ha leído dos panfletos sobre el agilismo y los desarrolladores quienes ya tienen una relación estrecha con el framework desde hace mucho tiempo.

Lo que quiero hacer a continuación es resaltar algunos mensajes que me parecieron interesantes del libro en pocas secciones.

Matrimonio feliz

“El buen desarrollo de productos lo hacen realidad individuos felices y apasionados, participando de equipos motivados y llenos de energía”, Tobias Mayer.

Para que una relación de pareja funcione deben existir muchos aspectos, pero el más importante es la felicidad. Si ambas partes no son felices, esa relación está destinada a fracasar. Lo mismo sucede en el trabajo en equipo. Los ambientes laborales en los que el empleador supervisaba al subalterno de manera exhaustiva ya se están extinguiendo, tanto así que los desarrolladores ya lo saben y no están dispuestos a aceptar el mismo ritmo de presión que en épocas pasadas.

Por eso, es muy importante que el equipo de trabajo en un proyecto esté conformado por seres humanos y no por “recursos”. La palabra “recurso” se toma de forma despectiva actualmente. Estos talentos que conforman el equipo van desde el desarrollador hasta el product owner. Todos por igual son responsables de que el proyecto salga de la mejor manera. Esto nos invita a dejar la batalla que existe (en muchos escenarios) entre el equipo de desarrollo y el product owner. Primero, porque genera un ambiente tóxico, crea división entre las partes y colabora a medias con el éxito de los objetivos.

Tener en cuenta a todos como un equipo sería el panorama ideal, pero la mayoría de las veces las organizaciones no entienden esto de la misma forma y su única acción es ejercer presión sobre el product owner y el equipo, lo cual impide cualquier tipo de diálogo o no permite escuchar las observaciones que vienen desde el desarrollador. En algunos casos, la arrogancia empresarial llega hasta el punto de saber que el entrenador ágil o desarrollador tiene la razón, pero el mensaje que emiten es “aquí se trabaja así”. Esto en parte puede ser por miedo al cambio o por simple arrogancia.

“La gente es quien va a crear un entorno de trabajo feliz, no algún proceso aprendido por ahí”, Tobias Mayer.

De cualquier forma, para un matrimonio feliz es necesario principalmente una comunicación efectiva; en Scrum es exactamente lo mismo.

Corazón valiente

“Cuanto más enseño y brindo consultoría sobre Scrum, más me convenzo de que el tablero físico es el corazón de Scrum”, Tobias Mayer.

A todos nos gusta llegar donde nuestros amigos, compañeros o familiares con buenas noticias. No obstante, hay que tener más valentía para llevar las malas, pues es necesario sacar el coraje para decir “me equivoqué”, “hubo un error”, “fracasé”. Uno de los valores que más me gusta de Scrum es la transparencia.

Un artefacto que nos ayuda a que este valor se lleve a cabo es el tablero de tareas e historias. En un concepto muy filosófico, es el lugar donde la tribu se reúne a discutir sobre los avances y retrocesos que están teniendo en su comunidad. Tobias así lo ve, y lo comparto. En esta era tecnológica se nos están olvidando las costumbres más humanas como la comunicación en persona, el manejo de la escritura a mano, entre muchas otras. Algunas organizaciones por ahorrar recursos deciden usar herramientas digitales para controlar día a día el avance de los equipos.

En este punto estoy a favor del tablero físico, pues las herramientas digitales fomentan el aislamiento de los miembros del equipo y reducen una cantidad de situaciones a un simple número. Por otro lado, la transparencia no es realmente venerada en este tipo de instrumentos por una cantidad de factores gerenciales que ejercen presión para mostrar un sprint más convincente.

El tablero físico fomenta la comunicación, la colaboración, el compromiso. Además, permite entender día a día sobre el avance, conocer con más detalle las situaciones del equipo. El product owner o cualquier miembro de la capa de gerencia podría enterarse fácilmente sobre los avances obtenidos en corto tiempo. Las alarmas se encienden rápidamente en caso de un bloqueo y se transmite un mensaje a cada miembro del equipo con tan solo verlo.

No es una bala de plata, pero puede ser la bala que necesita

“Scrum es como un baile: hay ciertas premisas que hay que respetar y el resto de las cosas se va adaptando, consiguiendo la armonía con la pareja de baile”, Tobias Mayer.

Un día el gerente del banco se despertó y dijo “Hagamos Scrum”. Enhorabuena por la decisión, ¿pero cómo es eso de hacer Scrum? ¿Dónde empiezo? La mayoría de las corporaciones dan el primer paso hacia la implementación del agilismo por varias razones, pero las más frecuentes son porque la competencia lo usa y le va bien: “Es lo que se está haciendo”, “creemos que es la solución al problema que tenemos de rendimiento”.

En este segmento me enfocaré en esa última sentencia.

Muchas compañías, de hecho más de las que deberían, poseen problemas de entregas en los desarrollos por las fechas que comprometen, porque la cohesión de los distintos proveedores ha sido difícil o porque simplemente no se les ha dado el resultado deseado.

Como alguien debe pagar las consecuencias, el señalado es el equipo de desarrollo. Es ahí donde entra la frase “hagamos Scrum”. Eso está genial, pero, si se piensa que el framework va a resolver de raíz todos los problemas que tenga el proyecto o la compañía, está equivocado. Scrum va más allá de un proceso: hay que jugar con la filosofía del ser humano en sí, profundizar y dejar de lado métodos tradicionales. Es necesario entrar en un nuevo escenario en el que no todos están dispuestos a jugar: unos por miedo; otros, peor, porque están en la zona de confort que dice “aquí se trabaja así”.

Aunque puede sonar complicado hacer Scrum, no es así. De hecho, hacer Scrum es muy sencillo; hacer mal Scrum es más difícil, y paradójicamente muchas compañías logran hacer esto último. Lo más difícil es adquirir nuevas prácticas, lo difícil es romper ese paradigma, lo que es realmente difícil es que el ser humano cambie.

Tobias lo define en algo muy pragmático y sencillo. Para que un equipo evolucione adoptando Scrum son necesarias tres cosas en el equipo de trabajo: honestidad, mente abierta y voluntad.

“Una persona, un equipo o una organización que no aprenda simplemente no está reflexionando sobre su forma de actuar ni mucho menos modifica su comportamiento en consecuencia”, Tobias Mayer.

Introduce algo de anarquía

“…altera el orden establecido, y el mundo se volverá un caos. Soy un agente del caos. ¿Te digo algo sobre el caos? Es miedo, el miedo a cambiar, la ruptura de un paradigma, el caos como revolución social”, The Joker.

Normalmente la palabra caos nos lleva a pensar en algo malo. Su definición, en efecto, tiene las palabras “desorden” y “confusión”. Si vamos más adentro, para que exista un desorden debe existir un orden, y son las personas quienes lo dictan. Si las personas pueden estar equivocadas con el orden establecido, ¿el desorden viene a convertirse en algo positivo?

Quizás fui muy cominero rodeando la definición, pero nunca me ha parecido mal el caos. Apple tuvo un caos en los 90; hoy en día es una de las empresas más rentables del mercado. Durante los últimos años de Pinochet existió un caos, y hoy en día Chile es una de las potencias más grandes de Sudamérica.

Lo que quiero decir es que, para poder generar cambios que revolucionen la calidad de un trabajo, debe existir una libertad de voltear todo al contrario para no cometer los mismos errores. Por el contrario, cometer nuevos y continuar el camino es lo que produce la anarquía.

Tobias lo explica de manera adecuada en su libro. Anarquía no es exactamente oponerse a todas las decisiones que tome la gerencia del proyecto. Anarquía es cuando el equipo tiene la libertad de tomar decisiones como un conjunto y no impuestas. Anarquía es cuando el equipo estima los desarrollos en el tiempo adecuado y no tiene que entregarlos en una fecha indicada porque la gerencia lo quiere así, lo que pone en riesgo la calidad del trabajo.

Siempre me ha parecido curioso que la gerencia de un proyecto indique la fecha de entrega sin consultar con el equipo de desarrollo, teniendo conocimiento que al final el que va a desarrollar es el equipo, no el gerente. Es aquí donde el factor confianza debe hacerse presente.

La deuda se paga

Esta es quizás mi parte favorita del libro. Primero, porque vuelve todo el argumento terrenal. Scrum lo hace posible las personas, los seres humanos, con gustos distintos, con valores diferentes, incluso con errores particulares: todo eso va en el paquete.

Es por eso que a veces por premuras, presiones o simplemente poco foco en el día a día del sprint pueden presentarse lo que se conoce como “deudas técnicas”. La definición es simple: son cosas que se hicieron de una forma, funcionan, pero se pueden hacer mejor o deben hacerse de mejor forma.

La aparición de la deuda técnica no la puede absorber solamente el equipo de desarrollo porque, si todos están en las felicitaciones, todos deben estar juntos en los problemas. Tampoco la deuda es una manzana podrida, pero puede llegar a convertirse en una si se empiezan a acumular muchas y al final acaban con el huerto.

Para que esto último no suceda, debe prevalecer la transparencia en el equipo, establecer las razones por las cuales se va a generar la deuda, exponer en un lugar visible para todos sepan que la deuda existe, comprometerse como equipo a buscar un espacio para resolverla, pero nunca puede tratarse este tema como la culpa del equipo de desarrollo y como si ellos tuvieran que trabajar horas extras para resolverla.

Ojo con el último comentario. Aunque no esté de acuerdo con dicha frase, hay que reconocer que no todos los equipos son iguales, y a veces existen desarrolladores que les gusta dejar deudas técnicas en su código como dulces en Halloween.

Existen muchos más segmentos fascinantes en este libro y podría seguir escribiendo párrafos sobre prácticas y conceptos interesantes, pero es mejor que cada uno de ustedes saque sus propias conclusiones y determine las prácticas que considere necesarias para su status quo.

Nos vemos en un próximo post.

0 Comentarios

Dejar un comentario