Saltar al contenido

We suck at agile and SCRUM, here’s why

La real academia de la lengua española es clara en la definición de la palabra ágil:

Ligero, pronto, expedito.

No en vano Fowler, Martin y compañía decidieron adoptar esta palabra para definir un proceso de desarrollo de software con métricas apegadas a la realidad pero lo más importante: con resultados tangibles.

Recientemente, en el proyecto más actual en el que me encuentro laborando, he tenido oportunidad de (intentar) implementar esta metodología de trabajo.

¿He sido exitoso en dicha implementación?

Más o menos…

Waterfall Vs SCRUM

Existen muchas metodologías de desarrollo de software siendo la más común waterfall, esa que nos dice que tenemos que hacer más o menos lo siguiente:

  1. Levantamiento de requerimientos
  2. Diseño
  3. Implementación
  4. Verificación
  5. Mantenimiento

640px-Waterfall_model.svg

El problema más grande que los detractores de waterfall identifican es la poca flexibilidad para ajustar los requerimientos o metas del proyecto ya que una vez que hemos pasado de un paso al siguiente es muy difícil, complicado y caro cambiar el objetivo del proyecto, situación que el 90% del tiempo va a suceder por varios factores, principalmente por:

  • El cliente cambia los requerimientos del proyecto, después de la fase planeación o negociación por tener poca visibilidad de las necesidades durante el análisis y diseño
  • Inconvenientes u obstáculos técnicos que son difíciles de encontrar en el análisis inicial, cuando solo se está enfocado en aspectos generales del proyecto y no de las particularidades
  • Cambios en el entorno del negocio en el cual se desempeña el cliente lo cual hace necesario repensar a que elementos darles prioridad

Es por estas y otras razones (principalmente el «epic failure» de la mayoría de los proyectos administrador con waterfall) que las metodologías ágiles de desarrollo de software han sido adoptadas en la última decada, particularmente SCRUM.

SCRUM

A diferencia de waterfall, SCRUM no pleantea una metodología de trabajo lineal sino más bien iterativa, es decir, con n cantidad de ciclos:

  1. Sprint planning (planeación del siguiente bloque de trabajo)
  2. Daily standup (revisión de progreso del día anterior y plan de trabajo del día actual)
  3. Sprint review (revisión de elementos o entregables listos)
  4. Sprint retrospective (o análisis del trabajo realizado y lo que se pudo completar)

scrum_process

Por supuesto que SCRUM es más que eso pero en los términos más simples estos son los procesos (o ceremonias, en la jerga de scrum).

De hecho, si tuviera que explicar SCRUM a alguien que nunca ha trabajado bajo esta metodología, de la manera más simple sería:

Es como waterfall, solo que infinito

A diferencia de waterfall, SCRUM requiere que los mismos procesos se repitan idefinidamente hasta que el producto esté listo, de hecho, en la naturaleza de SCRUM está el hecho de que no existe una meta como tal de un producto terminado sino que siempre es continuo el desarrollo. De este modo siempre hacemos análisis de requerimientos y estimaciones (sprint planning) diseño e implementación (durante el proceso de development) verificación (con las juntas diarias o los llamados daily standups y el sprint review) y finalmente el mantenimiento toda vez que se aplican fixes al software durante el mismo proceso. Este flujo de trabajo se repite por cada «sprint» que simplemente es un bloque de tiempo ya sea una semana, 15 días, etc. La ventaja de esta estrategia es que siempre se puede ir ajustando el proyecto según los requerimientos cambien y se pueden tener entregables fijos constantemente, es decir, el crecimiento del proyecto es orgánico.

Big ACME corporation VS startups

La mayoría de los proyectos en los que he estado involucrado han sido para empresas grandes, grandes y burocráticas. Naturalmente estos entornos de trabajo suelen ser los que más se inclinan por metodologías tradicionales como waterfall y es ahí donde he experimentado el fracaso de dicha metodología, salvo algunos honrosos casos.

De hecho, en la mayoría de estos proyectos ni siquiera se ha seguido al pie de la letra una u otra metodología. Parte del fracaso de estos proyectos ha sido precisamente esa falta de organización y compromiso por todas las partes involucradas en el equipo.

¿Fracaso?…

Sí, bueno, a pesar de ser productos que probablemente vieron la luz y están felizmente ejecutandose en entornos de producción puedo asegurarles que la mayoría elevaron su costo de desarrollo a mas del triple y se entregaron en fechas muy diferentes a las acordadas inicialmente. Desde el punto de vista técnico probablemente el producto haga lo que tenga que hacer, pero desde la perspectiva de negocio fue un fracaso ya que probablemente no llego en tiempo ni forma, y eso siempre cuesta dinero y bueno, todos estamos en esto por el dinero ¿No?

La mayoría de las veces que he tenido que administrar proyectos los elementos involucrados en dicha tarea han sido inútiles por una serie de situaciones complicadas donde obviamente todos hemos tenido la culpa. Por ejemplo, usualmente para el diseño inicial de una aplicación se suelen desarrollar los siguientes documentos o elementos:

  • Documento de negocio que explica los requerimientos del proyecto, de sus usuarios y alcance
  • Documento con entregables, definición de funcionalidad por módulo, etc.
  • Diagrama de proyecto (gantt chart, calendario, etc.)

¿Sáben cual de los elementos anteriores sigue siendo válido después de un par de meses de iniciado el proyecto?

Ninguno.

Trabajar con corporativos o empresas grandes requiere hacer compromisos de caballeros, esos que van firmados en documentos y que tanto el cliente como el proveedor saben que no se cumplirán pero que de todas formas se necesitan para satisfacer al área de compras del cliente y la jurídica y administrativa del proveedor. Desgraciadamente, todos los niveles hacía abajo en el escalafón quedamos atrapados en dicha mentira pues la mayoría del equipo, desde el director de proyecto, hasta el programador, saben que será imposible entregar el producto y no precisamente porque crean que es complicado sino todo lo contrario: incertidumbre, se sabe a grandes rasgos que se debe hacer pero es imposible estimar un proyecto «de pi a pa» de manera tán genérica.

Lo anterior hace que pasados un par de meses no solo los documentos iniciales se vuelvan inútiles sino que además se tenga poca idea del rumbo que el proyecto debería de tener, cuales elementos deben llevar prioridad, donde están fallando las cosas, etc. Y al final, cuando el cliente está en una situación crítica donde no ha recibido absolutamente nada y ya ha pasado al menos la mitad del tiempo estimado de desarrollo se empieza a explotar al equipo para tratar de sacar un producto que ahora cuenta con requerimientos totalmente diferentes a los pactados inicialmente, peor aun, el seguimiento de avance y progreso del proyecto termina siendo administrado en una hoja de excel con colores chillones y columnas que nos indican la prioridad de cada uno de ellos: para antier, para ayer y crítico.

Después de años de estar involucrado en proyectos de este tipo, y aprovechando que ahora laboraba en una empresa de desarrollo de software que trabaja exclusivamente con startups decidí que era momento de intentar algo diferente. Si bien SCRUM y las metodologías ágiles no me eran ajenas tampoco podía decir que tenía experiencia real en el tema ya que haber sugerido dicha metodología de trabajo en proyectos anteriores hubiera sido causa de burla (lo menos) por parte de mis superiores sin embargo mi nuevo cliente SÍ estaba dispuesto a trabajar bajo dicha metodología.

Pensando que tenía el apoyo del cliente y suficiente conocimiento con el tema eché a andar la máquina y comenzamos a trabajar en nuestro proyecto donde finalmente entendí lo equivocado que estaba sobre el tema de colaboración.

Lo que NÓ es SCRUM

Tan pronto como inició el proyecto empecé a hacer un poco de investigación sobre el tema: me leí algún par de libros (recomiendo este y este otro), monté un proyecto en pivotal tracker con algunas de las historias de usuario o elementos iniciales del proyecto y comencé a diseñar un proceso de trabajo interno en el equipo.

Al cabo de un par de meses me dí cuenta que a pesar de intentar implementar la metodología y seguir más o menos al pie de la letra los pasos las cosas no estaban saliendo como se habían planeado. El principal problema era la falta de colaboración entre el cliente y el equipo de desarrollo. Por ejemplo, nuestro CTO o director técnico del proyecto no estaba disponible para responder dudas la mayoría del tiempo y por otra parte no había un rol definido sobre quien sería el «product owner» o quien debería priorizar las tareas y que era más importante para entregar en cada ciclo.

Tras varias juntas y discusiones con el cliente intenté explicarles no solo la metodología de trabajo sino las ventajas de seguirlo al pie de la letra. Una de las ventajas de nuestro cliente es que la mayoría de los miembros de su equipo son personas jóvenes y abiertas a cambios o metodologías de trabajo diferente, sin embargo parecía que aún cuando entendían las ventajas de SCRUM no entendían las responsabilidades porque tanto el cliente como el proveedor tenemos responsabilidades en SCRUM. Para el cliente, SCRUM seguía siendo un buzzword de moda entre startups que permite entregar trabajo de manera ligera, pronta, y expedita, solo que por arte de magia o generación espontánea.

La parte más difícil de enseñar SCRUM a un cliente es hacerle entender que si este no se involucra será prácticamente imposible que el proyecto sea exitoso.

Pero, ¿Qué es realmente lo que debemos ayudar a nuestro cliente a entender?

En un artículo de Mike Hadlow podemos leer lo siguiente:

So what happened? Why is agile now about stand-ups, retrospectives, two-week iterations and planning poker?

Somehow, over the decade or so since the original agile manifesto, agile has come to mean ‘management agile’. It’s been captured by management consultants and distilled as a small set of non-technical rituals that emerged from the much larger, richer, but often deeply technical set of agile practices.

Involucrar al cliente significa hacerlo entender el alcance técnico del proyecto. Tal como menciona el artículo citado SCRUM no es una metodología de administración de proyecto, es una metodología de desarrollo de software y tanto al cliente como a mi (el administrador de proyecto) nos ha costado entenderlo.

Aun cuando recientemente hemos llegado a un punto donde nuestro cliente se ha involucrado lo suficiente (gracias a la propia presión que he ejercido para que esto suceda) siento que podríamos tener mejores resultados. Sí, tenemos planeación de sprint cada semana donde el cliente está involucrado. Sí, tenemos una llamada diaria con el cliente a manera de daily standup donde revisamos lo que hizo cada miembro del equipo el día anterior y lo que hará el día de hoy y si tiene algún obstáculo para completar dicha tarea. Sí, hacemos «groom» del backlog y nos aseguramos que cada miembro tenga suficiente trabajo para las siguientes iteraciones, priorizado y bien explicado. Sí, tenemos «team retrospectives» donde se discute el performance de todo el equipo y como podemos mejorar.

Pero esto no ha sido suficiente.

Citando de nuevo el artículo de Hadlow:

The core problem is that non-technical managers of software projects will always fail, or at best be counter productive, whatever the methodology. Developing software is a deeply technical endeavour. Sending your managers on an agile course to learn how to beat developers over the head with planning poker, two week iterations and stand-ups will do nothing to save spaghetti code and incompetent teams. You might have software projects that succeed despite the agile nonsense, but that would be coincidence, not causation.

Afortunadamente me puedo considerar lo suficientemente técnico para entender las partes complicadas de un proyecto de software pero lo suficientemente imparcial para entender las necesidades a un nivel de negocio, sin embargo, si parte de las personas involucradas en la planeación de cada iteración son personas que carecen de entendimiento y conocimiento técnico entonces es necesario que alguien sea capaz de explicar a estos miembros las implicaciones de tareas muy técnicas a un nivel relevante para ellos, es decir, el impacto a nivel de producto o de operatividad de negocio, riesgos o ventajas que una decisión técnica implica; puede ser que signifique más tiempo para entregar funcionalidad que se requiere inmediatamente, introducir inestabilidad en producción, incompatibilidad con la integración de un tercero, etc.

Por ejemplo, recientemente en una de las planeaciones de nuestros sprints un miembro del equipo por parte del cliente requirió cierta funcionalidad que tenía la más alta prioridad, después de haberla estimado entre el equipo se me hizo la siguiente pregunta:

¿Cuándo puede estar listo para probarse esto? ¿Miércoles o Jueves?

A pesar de haber estimado la tarea no tendríamos suficiente tiempo para entregarla esa semana. El razonamiento del cliente fue que «particularmente esta funcionalidad es crítica para nosotros y necesitamos entregarla esta semana» a lo que contesté:

Sería similar a pedirle a una mujer que es urgente que tenga un bebé y que lo necesitamos en 4 meses

Hay cosas que no se pueden apresurar, tal como la reproducción y desarrollo embrionario. De igual manera, ciertos factores en el desarrollo de software impiden que tengamos entregables en una fecha específica solo porque se le aumente prioridad a la tarea o se trate de agilizar su desarrollo poniendo a todo el equipo de trabajo en ella. El desarrollo ágil no tiene nada que ver con acelerar las cosas, tiene que ver con organización. Si alguien en el equipo es incapáz de transmitir esta información de una manera no técnica a quien requiere dichos cambios entonces estamos fritos, y, usualmente, para que esto suceda, debemos contar en el equipo con un administrador de proyecto que entienda ambas partes.

Because creating good software is so much about technical decisions and so little about management process, I believe that there is very little place for non-technical managers in any software development organisation. If your role is simply asking for estimates and enforcing the agile rituals: stand-ups, fortnightly sprints, retrospectives; then you are an impediment rather than an asset to delivery

La parte clave del texto citado arriba es: «Crear buen software tiene mucho que ver con decisiones técnicas y muy poco sobre procesos administrativos»

Tal cual: La clave está en tomar las decisiones técnicas adecuadas que nos permitan entregar lo que el cliente necesita, siempre y cuando existan las condiciones técnicas para hacerlo o de lo contrario hacérselo saber al cliente para que este tome la decisión pertinente.

Cómo mejorar el flujo de trabajo en SCRUM

A pesar de seguir experimentando con esta metodología de trabajo y puliendo nuestro flujo interno he tenido suficientes experiencias para discernir cuando estamos haciendo algo bien y cuando estamos haciendo algo mal, pero sobre todo, hacer ejercicio de auto-evaluación para poder ayudar a los miembros del equipo, labor más importante de mi puesto.

Estos son algunos de los puntos que consideraría claves para mejorar el flujo laboral basado en SCRUM:

Ser un «team lead«, no un «project manager«

La diferencia es grande. Pero si ustedes como en mi caso están encargados de «administrar el proyecto» es mejor comenzar a ver las cosas de otra manera. La psicología es poderosa y verse así mismo como administrador envenena el entorno y nos vuelve inútiles hacia nuestros compañeros. Por otra parte si tratamos de convertirnos en líderes de equipo significa que tomaremos un rol más importante que administrar: ayudar. Como se titula este artículo:  «You are not a software development manager, you are software helper» la única misión que deberíamos tener en mente es ayudar al equipo de desarrollo a cumplir las metas y objetivos, nada más. Esto me ha costado entenderlo pero la ayuda y feedback del equipo han sido de mucha ayuda. Pedir retroalimentación de los miembros de nuestro equipo constantemente y conocer sus necesidades nos ayudará a pulir este, nuestro rol.

Involucrar a todas las personas necesarias

Planeación de sprint entre desarrolladores solamente no es planeación. Estimación sin las personas de calidad no es estimación. Priorizar tareas sin contar con participación del cliente será inútil. Es elemental que todos los roles estén involucrados siempre: cliente, desarrolladores, calidad, team leads, etc. Cada una de estas personas juega un papel importante en scrum ya sea como team member, scrum master, product owner o stake holder. Cualquier ceremonia o evento de SCRUM que no involucre a todos estos roles no servirá de nada.

Es también esencial hacer entender a las dos partes (tanto al cliente como al equipo de desarrollo) la importancia de su participación y hacerlos co-responsables del proceso. La adecuada ejecución de SCRUM no es solo responsabilidad del «administrador del proyecto» o del cliente, es de todos.

Pulir el flujo de trabajo

En algunas ocasiones aun cuando seguimos al pie de la letra SCRUM los resultados no son inmediatos. Para ello es necesario ir puliendo y acoplando el flujo de trabajo para que sea compatible con SCRUM y no lo contrario. Por ejemplo, uno de los inconvenientes que ocurren con mas frecuencia durante nuestros daily standups es dificultad para transmitir de manera sintentizada información sobre las actividades de cada desarrollador en un lapso corto de tiempo. Para ello he recomendado a cada uno de los desarrolladores tener listas sus notas sobre lo que deben discutir día a día pero solo con los puntos importantes, es decir: ¿En qué estoy trabajando? ¿Cuál es el avance o estatus actual?, proyección de las siguientes tareas, etc. Ir mejorando cada una de las partes o «rituales» dentro de SCRUM nos ayudará a invertir más tiempo en desarrollar el producto que en administrarlo.

Colaboración constante con el cliente (y viceversa)

Este es uno de los puntos críticos: si no se tiene colaboración y comunicación constante de equipo de desarrollo hacia el cliente y viceversa entonces será difícil tener entendimiento de los requerimientos de cada iteración o bien para el cliente será difícil entender obstáculos técnicos al menos en un tiempo saludable para tomar decisiones y revalorizar la importancia de las tareas. Mi regla es simple: si al momento de hacer la estimación de una tarea alguien del equipo no entendió a la perfección lo que se debe desarrollar entonces no podemos estimarla. Tampoco podemos estimar algo que el cliente no puede explicar fácilmente y en su totalidad; si esa unidad de trabajo no es completamente estimable y entendible entonces no debería trabajarse en ella.

Otro punto clave en la comunicación es que el desarrollador informe al cliente cuando una tarea que se estimó presenta obstáculos o tomará más tiempo de lo acordado. Esto no es un pecado ni una debilidad por parte del programador pero si es necesario informarlo ya que el cliente debe tomar la decisión si se sigue invirtiendo tiempo y capacidad en dicha tarea o se reasignan los recursos.

Por otra parte cuando sucede lo inverso, es decir, el cliente cambia requerimientos que afectaran algunas tareas o historias ya definidas, es importante notificar al equipo de desarrollo para revalorizar dichas tareas e informar de vuelta al cliente los cambios necesarios.

Uso de herramientas de apoyo

Finalmente diría que una de las cosas que más nos ayudaran es el uso de herramientas para administrar el proyecto SCRUM como dashboards digitales, bug trackers, etc. Lo más importante: utilizarlos. Si nadie utiliza las herramientas adecuadamente entonces solo nos estorbarán. Hay que educar tanto al cliente como a los desarrolladores el uso adecuado de estas herramientas para evitar perder más tiempo en depurar la información dentro de la herramienta que lo que nos ayuda para llevar acabo el proyecto; títulos descriptivos, descripciones de tareas con casos de uso y recursos como fotos, textos, wireframes, tags o etiquetas para categorizar, asignación de tarea a las personas adecuadas, etc.

Publicado engeneralprogramacióntecnología

Un comentario

  1. […] algunos años escribí sobre este tema. La verdad es que podría decirse que he estado involucrado en pocos proyectos utilizando SCRUM, 4 […]

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.