Es bastante habitual certificarse en el mundo de la Consultoría Tecnológica. Las certificaciones mejoran los méritos de una empresa a la hora de conseguir proyectos y clientes. Las consultoras suelen apostar fuerte por programas formativos y por certificar a sus empleados. No obstante, existe una gran confusión en los profesionales que aplican Scrum en consultoría, muchos conceptos les cuestan encajarlos en su realidad.
Un ejemplo típico, si le preguntas el objetivo de la Sprint Review, muchos consultores de tecnología te responderán: entregar lo que nos hemos comprometido para que los clientes estén contentos. Esta es una respuesta muy de consultoría pero muy alejada de la propuesta de Scrum. ¿Por qué cuesta entender Scrum en las consultoras?
La palabra valor
Estuve cerca de dos años trabajando como Scrum Master en diferentes empresas sin saber que existía una guía Scrum oficial. Como muchos profesionales pensaba que Scrum era muy moldeable y adaptable a tu situación tal y como proponían muchos autores que hoy en día considero de poca relevancia.
Fue a raíz de un curso con Jerónimo Palacios donde comprendí el concepto de valor. Es clave entender muy bien que el valor está relacionado con el impacto en negocio y, si la empresa tiene ánimo de lucro, hablamos de dinero. Ahí es cuando te das cuenta y entiendes muy bien la propuesta de Scrum. Desde que “vi la luz” empecé a acompañar a otros profesionales para que entendieran todo esto y de hecho, nació este blog.
¿Qué consideran las consultoras sobre el valor?
El valor y la consultoría
El gran problema de la consultoría es que sus modelos de negocio se alejan muchísimo de la propuesta de Scrum. Para empezar, la mayoría viven o bien del outsourcing que no tiene absolutamente nada que ver con Agile/Scrum. Otra opción es que vivan de proyectos llave en mano (cerrados) cuyo éxito empresarial está a la fecha. Buscamos entregar una determinada solución en una fecha dada para mantener un margen y contentar al cliente lo suficiente como para que nos renueve y siga apostando por nosotros.
Tampoco quiero hacer sangre de un modelo del que he vivido muchos años pero es verdad que se aleja mucho del concepto de Scrum. Y, por desgracia, esta propuesta también se aleja mucho del modelo que tengo en la cabeza de un buen software. Porque para mí un software potente es aquel que soluciona problemas a los usuarios de manera continua. Sin embargo existe el eterno dilema entre el cliente y el usuario cuando hablamos del contexto de consultoría.
Quizás este sea el gran problema de Scrum en las empresas consultoras. Casualmente son estas consultoras las que más apuestan por certificaciones y por este tipo de formaciones. Por tanto he aquí el gran dilema cuando nos enfrentamos a la implantación de Scrum en la vida real.
¿Qué falla?
Vamos a intentar explicar los conceptos que fallan habitualmente. Por un lado, cuando hablamos de consultoría hablamos de que el equipo que va a resolver el problema tiene dos contratos sobre la mesa. Tenemos dos negocios: uno el de el equipo con los usuarios finales y otro el de la consultora con el cliente. Esto ya ensucia la relación donde los programadores deberían de estar directamente vislumbrando al usuario final y muchas veces tienen que estar velando por su propia consultora.
Otro concepto a romper es que el software se enfoca como si fuera a construir edificios donde podemos planificar todas las tareas. Realmente, el software funciona en base a cómo realizarías una vacuna, es decir, a base de investigación prueba y error. Por tanto, el objetivo de un software es resolver un determinado problema: vender más, reducir costes, mejorar la experiencia de cliente… Por ejemplo, un buen producto software con una mala campaña de marketing podría fracasar. ¡Por muy bien que estuviera hecho!
La distancia entre los usuarios y los desarrolladores suele ser muy alta y eso es un gran problema, es difícil acertar con un producto software si las personas que lo van a recibir tienen dificultades con las personas que lo crean. Necesitamos tener métricas de negocio en las que contrastamos el resultado de nuestro producto con los objetivos que nos habíamos planteado. Pero muchas veces en consultoría los objetivos no vienen del negocio sino de un departamento de tecnología cuya misión es implantar lo que negocio les ha pedido y en una fecha concreta (sin medir el impacto en negocio).
Scrum o muerte
Podemos hacer una reflexión subyacente: muchas consultoras afirman que su misión no es hacer Scrum. Su misión es desarrollar productos y soluciones para clientes finales que apuesten por ellos. Y está bien, es un modelo loable y bastante positivo pero también es verdad que Scrum tiene una aproximación muy cercana a la realidad de software, mucho más que a la realidad de las consultoras de entregar software corriendo para una fecha que alguien vendió.
Porque los mejores equipos de software del mundo se centran en resultados y Scrum proporciona herramientas en esa dirección. Hay grandes equipos que no utilizan Scrum y obtienen resultados pero su aproximación de prueba y error está mucho más cercana a este marco que la aproximación tradicional de planificar y cumplir el plan..
Y parte de todo esto también tiene la culpa los clientes que prefieren un modelo controlado de costes donde les digan a priori lo que van a pagar que un modelo abierto donde entregamos valor continuamente y cuyo coste dependerá del tiempo que queramos estar funcionando. Para mí estas son las piezas claves que han derrumbado un poco el mito de Scrum y que hacen que hoy en día se haya dejado de lado.
Y tú, ¿crees que Scrum se entiende bien en el mundo de la consultoría?
