Consejos para hacer Scrum en una consultora

Durante los últimos años, he tenido la oportunidad de trabajar en diferentes consultoras con temas de Agile como Beeva (actual Next Technology), Paradigma Digital, Efron Consulting, Accenture Digital, Sopra y Atmira Digital. En todas ellas, se ha intentado hacer Scrum y, dado que en España el uso de consultoras está muy extendido, voy a sugerir algunos consejos e ideas para debates que hay que tener si se pretende  aplicar Scrum en nuestro equipo.

¿Por qué hago Scrum?

Conocer el motivo es vital porque dependerá mucho de cómo nos queramos posicionar en el mercado. Para algunas consultoras, Scrum supone una ventaja competitiva que aportar al cliente final para desarrollar un mejor software. Para la mayoría, es una moda que adoptar porque los clientes lo demandan. Es importante que tengamos el  debate sobre el objetivo de aplicar Scrum antes de meternos en la película. Si deseamos ser referentes de la aplicación de Scrum, tendremos que tener claro que deberemos rechazar algunas oportunidades si vemos que las finalidades no son coincidentes y que tenemos poco futuro.

¿Quién pone los roles?

Esta pregunta tiene múltiples debates paralelos. Por un lado, tenemos que componer un Development Team. Hay empresas que prefieren proporcionarlo; otras prefieren hacerlo mixto con el cliente para, de esa manera hacer, el traspaso e, incluso, vender el servicio de “te enseño a programar mejor”. En este aspecto, lo importante es analizar si tenemos todas las habilidades para que el equipo realmente pueda desarrollar el producto.

En cuanto al Scrum Master, hay múltiples opciones. Algunas consultoras lo proporcionan junto al Develelopment Team y, otras veces, se prefiere que el Scrum Master sea del cliente o bien que lo proporcione otra empresa diferente. La experiencia aconseja evitar la situación de poner dos Scrum Master, uno de cliente y otro, de consultora. Otra mejora, en mi opinión, es proporcionar un 100% de este perfil. Lo comento porque muchas consultoras se plantean poner un 50% o menos en clientes donde Scrum no está asentado o con equipos con poca madurez y experiencia.

Respecto al Product Owner, podemos decir que hay más controversia. En algunas consultoras  suelen pedírselo al cliente porque es el dueño del conocimiento de negocios, pero se producen  debates internos sobre si se puede proporcionar ese servicio. En otras empresas, que disponen de expertos en ciertas partes del mundo bancario,  es más común asumir esa responsabilidad. Si la idea es hacer bien Scrum, y nos planteamos seriamente la pregunta anterior, entonces es mejor que el perfil tenga la capacidad de hacer un buen Product Management.

¿Cómo se alteran ahora los costes?

Cuando trabajamos con Scrum en consultoría, tenemos que tener un interesante debate interno sobre los costes. En el mundo tradicional, siempre teníamos un Jefe de Proyectos, que normalmente tenía un sueldo elevado. Si apostamos por hacer Scrum en consultoría, ahora disponemos de dos roles: Product Owner y Scrum Master. Para más inri, estas figuras suelen percibir un sueldo elevado porque estamos “de moda” en este  momento. Por tanto, estamos encareciendo el coste de nuestro equipo. Además, explicar que el Scrum Master, a veces, está haciendo labores como transformación o de aprendizaje es complicado de justificar.

Como debatimos antes, si el Product Owner lo facilita nuestra cliente, quizás así, no seamos tan caros. Todo va a depender del modelo con el que nos presentemos y queramos trabajar.

¿De quién es la responsabilidad?

El concepto de responsabilidad contractual es complicado de resolver en estos escenarios. En primer lugar, recordemos que estamos hablando de Agile, donde el contrato es importante, pero es más importante la colaboración. Ya en esto, estamos diciendo mucho: si tenemos que sacar a relucir el contrato es que algo no hemos hecho bien con respecto a esa confianza.

Hay quien opina que el Product Owner lo debe facilitar el cliente para que asuma la responsabilidad. Si lo asume la consultora, entonces toda la responsabilidad pasa a ser de la misma. En esta disyuntiva, se pueden plantear problemas:  si se asume todo el peso del producto y el cliente no colabora convenientemente para que hagamos el trabajo, entonces la responsabilidad seguirá siendo del mismo. Al final, es una cuestión de intereses.

El problema real radica en que, realmente, cualquier equipo software que se precie tiene muchísimas dependencias con las diferentes áreas del cliente: sistemas, calidad, negocio… Todo esto hace que la velocidad de trabajo no sea real, porque puedes desarrollar muy rápido, pero no puedes terminar sin esas dependencias.

Es importante saber quién “paga el pato” si todo va mal. Sin embargo, es complicado empezar una relación de confianza pensando en qué medidas podemos tomar si el de enfrente se equivoca.

¿Composición del equipo?

La composición de los equipos también requiere de un debate interesante. En teoría, es el propio Product Owner quien compone el equipo a nivel de costes, y es el propio Development Team quien determina sus necesidades y su composición. Pero, desgraciadamente, hay consultoras que no le dan importancia ni a la autoorganización ni al Product Owner, por lo que la composición acaba delegada en directores o managers.

También ocurre que, en el escenario donde el Product Owner lo pone el cliente, en teoría no tiene “poder” sobre el Development Team porque no puede fichar “por la consultora”. Incluso a veces, se componen los equipos con personas de diferentes consultoras.

Este aspecto es complicado porque hablamos de personas, y no se pueden convertir en “recursos” de ahora me quitas y ahora me pones gente.

Si extendemos este debate a otras cuestiones como son: motivación del equipo, incentivos, subidas salariales, capacitación, formación, asistencia a eventos…, los problemas se multiplican.  Todas las cuestiones planteadas son importantes para los profesionales y es difícil para un Product Owner fomentarlo porque el equipo pertenece a otra empresa. Sin embargo, medir la felicidad del equipo es clave porque es parte del valor de tu producto.

Conclusión

Como ya vimos en este artículo, la estrategia de venta es complicada en el mundo de la consultoría. Scrum se creó para lidiar con la incertidumbre y la consultoría añade más incertidumbre a la ecuación a cambio de otros intereses. Quizás los clientes finales tengan que apostar más por sus propios departamentos IT y menos por la subcontratación excesiva.

Aún así, si eres una consultora y quieres apostar por Scrum, saca a la luz con tu cliente todos estos temas y ten conversaciones en torno a ellos para conseguir que el verdadero cliente, nuestros usuarios, tengan el mejor servicio posible.

Y tú… ¿Cómo resuelves estos temas en tu consultora?