Hace más de 20 años, 17 desarrolladores de software publicaron el manifiesto ágil y afirmaban lo siguiente: “Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros”. Si bien es cierto el concepto de agilidad aparece propiamente en el año 2001, está presente desde hace décadas atrás. Aún recuerdo cuando leí por primera vez los temas relacionados con la agilidad, se me vino a la mente un libro maravilloso de economía publicado el año 1776, que leí en mi época de estudiante, el cual se llama “Una investigación sobre la naturaleza y las causas de la riqueza de las naciones” del escocés Adam Smith. En este libro, el autor, mediante el ejemplo soberbio de la fábrica de alfileres, explicaba lo que conocemos ahora como equipos funcionales, o cuando hablaba de learning by doing, que se enfoca en las bases de lo que ahora llamamos mejora continua que se dan en las iteraciones o sprints en Scrum.

Actualmente, la tendencia de muchas organizaciones, y sobre todo las dedicadas al desarrollo de   Software, es dar ese “Giro Copernicano” y volverse ágiles, incluso sin comprender completamente de qué trata en realidad la agilidad. En mi experiencia, la mayoría de las organizaciones ingresan al mundo ágil por un tema de moda, competencia, o la creencia que van a aumentar la celeridad de sus proyectos o por alguna otra razón, sin comprender a ciencia cierta en qué consiste la agilidad. Además, existen casos de organizaciones que, con la mejor de las intenciones, creen haber dado el salto a la agilidad por hacer iteraciones, pegar pósits en la pared, realizar reuniones diarias, etc., cuando debemos saber que la agilidad va más allá de todo eso. 

Recuerdo el caso de un señor cuya labor era revisar si la documentación estaba completa antes de pasar dicha documentación al departamento que le correspondía y de ser así le ponía un sello de conforme. En las reuniones diarias respondía a las preguntas de esta manera:

• “¿Qué hiciste ayer?”

“Revise documentos”.

• “¿Qué vas a hacer mañana?”

“Voy a seguir revisando documentos”.

Cuando le pregunté por qué hacía eso la respuesta fue la siguiente: “Así dice Scrum que debemos hacer”. 

En otros casos a un equipo de desarrollo de Software, supuestamente ágil, se le pregunta lo siguiente:

• “¿Cuántas funcionalidades han terminado en el último trimestre?”

“Cerca de 100 funcionalidades”.

• “¿Cuántas de esas funcionalidades está usando el cliente?”

“Ninguna”.

Entonces, nos percatamos realmente que el objetivo no es hacer Scrum, sino que la organización sea realmente ágil. La agilidad en realidad debe entenderse, independientemente de la industria del Software, como una filosofía que utiliza modelos de organización basados en las personas, la colaboración y los valores compartidos. 

A partir de ello, debemos preguntarnos lo siguiente: ¿qué significa realmente una organización ágil? Actualmente, las organizaciones deben entender que implementar la agilidad solo en el departamento de desarrollo de software no es suficiente. Si toda la organización no es ágil entonces vamos a terminar realizando el doble de desperdicio en la mitad de tiempo, pero eso sí de manera “ágil”. En este sentido, la agilidad debe basarse en lo siguiente:

• Entregar valor de manera temprana y continua. Debemos ser conscientes de que realmente estamos generando valor cuando solucionamos los problemas de nuestro cliente.  Esto debería darse desde una visión paretiana, por ejemplo, resolver el 80? los problemas en 20 días.

 

• Adaptación a las necesidades dinámicas de los clientes. Debemos dejar de ser empresas de meseros para empezar a ser empresas de doctores, por lo cual planteo la siguiente pregunta: ¿hay que darle al cliente lo que pide o lo que necesita? Si haces lo primero vas a terminar armando una retahíla de funcionalidades que será un gran dolor de cabeza tanto para usted como para el cliente. En realidad, hay que empatizar con lo que necesita el cliente, sino vamos a caer en lo que Jeff Patton denomina como el síndrome del garaje.

 

• Tener equipos de alto rendimiento enfocados en el cliente externo e interno. ¿Le ha pasado que en algún momento ha necesitado algo dentro de su organización, por ejemplo, contratar nuevo personal? Usted se dirige a la oficina de personal y hace el pedido, pero le informan que para proceder tienen que aprobar el presupuesto. Luego, el encargado de presupuesto informa que no ha llegado la aprobación del jefe de área. Más adelante, el jefe de área indica que no le ha llegado el requerimiento que enviaste hace dos semanas. Posteriormente, cuando preguntas por qué no se ha enviado tu requerimiento te dicen que la secretaria del área se encuentra de vacaciones hace un mes. Obviamente tenemos un serio problema en la organización cuando cada área se comporta como un silo limitado solamente a sus funciones.

 

• Mejora continua. ¿Alguna vez ha recibido una respuesta como “siempre lo hemos hecho así” o “es que el procedimiento no permite eso”, etc.? Por lo general todo puede ser perfectible y mejorable, lo cual es algo que toda organización debería tener como perspectiva para lograr ser competitiva en el mercado.

 

Con lo manifestado en este breve artículo, mi intención es brindar un pequeño conjunto de herramientas para que usted pueda responder a la siguiente pregunta: ¿qué tan ágil de verdad es su organización? Y si usted, amable lector, quiere que su organización dé ese salto importante hacia la agilidad lo más probable es que tenga que implementar un modelo de gestión de cambio organizacional como el ADKAR para tal propósito.

 

Referencias de consulta

- Highsmith, J. (2004). Agile Project Management: Creating Innovative Products. Pearson education. 

- Project Management Institute. (2017). Agile Practice Guide. PMI. 

- Smith, A. (1776). An Inquiry into the Nature and Causes of the Wealth of Nations.