Este post quiero que sirva de reflexión personal sobre mi visión del Desarrollo Ágil de Software y si el concepto de distancia es viable para ello. El sábado 22 de marzo, entrevistaron a Jordi Évole desde su casa para hablar del programa del día 23. En este programa, iba a charlar con varias personas, entre ellas con el Papa Francisco. El programa, para los que no lo vierais, se hizo enteramente con herramientas digitales (como Skype) incluída la entrevista al pontífice. Évole comentaba que para él, había sido uno de los programas más difíciles de hacer, ya que le gusta estar con su equipo trabajando todos juntos, porque eso le permite trabajar mejor. ¿Es el teletrabajo una buena herramienta para el trabajo en equipo?
Principios del Desarrollo Ágil de Software
Agile, está cerca de cumplir los 20 años de existencia. Su nacimiento se debió a varios Desarrolladores Software de referencia que veían cómo se hacía software de baja calidad, que no quería nadie, o se generaba documentación, que nadie leía. Todo ocurrió en el febrero de 2001 en la estación de esquí de Snowbird, allí se reunieron 17 profesionales del software (realmente, quedaron para esquiar, lo demás ocurrió por casualidad). Tras ese fin de semana, presentaron el Manifiesto por el Desarrollo Ágil de Software, basado en cuatro valores y 12 principios. Todos estos valores y principios buscaban solucionar algunas deficiencias que habían detectado en múltiples ocasiones.
Una de esos principios está íntimamente relacionado con la comunicación y dice así:
“El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara”.
Por tanto, Agile no parece especialmente alineado con el teletrabajo, y menos aún, con el equipo hiperdistribuido donde cada miembro está en un lugar diferente.
La oficina “agile”
Hace un tiempo, estuve trabajando en una consultora que había decidido crear una Oficina Agile en una ciudad del sur de España. En esta ciudad, lo sueldos son inferiores, hay una Escuela de Informática y, además, los ciudadanos son reticentes a irse de su ciudad. Por tanto, es un sitio ideal para invertir en la creación de equipos software a distancia que permitan el abaratamiento de costes y mejoren la competitividad de la consultora.
Esta técnica de abaratamiento de costes es bastante habitual en software debido a los costes bajos de transporte. En muchos países anglosajones, se han creado las denominadas “factorías” en ubicaciones como India o Filipinas donde la mano de obra es muy barata. Recordemos que, en países del primer mundo, los salarios son el principal coste del desarrollo.
En principio, esta fórmula funciona, sino fuera porque en el mundo Digital, apreciamos la capacidad de entrega rápida ya que el “coste de oportunidad” es elevado. Es la gran diferencia, en Agile pensamos en Producto, en entrega y en beneficios, mientras que el modelo tradicional busca proyectos, abaratar costes y controlar a las personas, ¡por eso cuesta tanto!
Los pokemon son la clave
En el verano de 2016, apareció un juego que revolucionó la industria del entretenimiento: el Pokemon Go! Este juego, una app para móviles, consistía en andar por la ciudad cazando pokemons. Este juego disparó la venta de baterías portátiles hasta el doble y fue una auténtica revolución en calles, plazas e incluso trabajos. A la vuelta del verano, quedamos varios amigos para jugar un partido de fútbol. Antes de empezar, un amigo me preguntó: “¿estáis jugando a los pokemon?, en nuestra empresa lo hemos instalado todos, estamos buscando oportunidades de negocio”.
Curiosamente, cuando el fenómeno del Pokemon Go! era una realidad, en McDonalds vieron una oportunidad de negocio maravillosa. Hicieron que hubiera pokemons dentro de los McDonalds para que las personas se acercaran a ellos y, así, aumentar el consumo.
¿Cómo funciona esto en la mayoría de compañías españolas?
Imaginemos que pertenecemos a una empresa que quiere aprovechar este movimiento para obtener beneficios. Por un lado, seguramente no tendremos un equipo especialista en innovación, por lo que no tendremos a nadie mirando al mercado para adelantarnos a la explosión de Pokemon Go! De pronto, llega Julio y se hace patente que hay una oportunidad de negocio. Rápidamente, hacemos un business case para poder aprovecharlo, sin este documento no nos aprobarán el presupuesto.
Llega agosto, y el Comité de Dirección está de vacaciones, y, no tenemos competencias, tenemos que esperar a septiembre para que nos aprueben este proyecto. Imaginemos que nos lo aprueban a la primera (muchas veces aparecen dudas y tenemos que modificar nuestro caso de negocio, a pesar de que todo es humo). Una vez aprobado, tenemos que buscar un proveedor que nos lo apruebe. Tardamos tres semanas en contactar con varios proveedores y darles tiempo para que nos hagan sus propuestas. Una vez tenemos claro qué proveedor nos lo hará, ya estamos en octubre, y le pedimos que arranque lo antes posible, porque este proyecto es estratégico. Nuestro proveedor nos dice que ellos también eficientan recursos, y que ahora tienen que formar el equipo y para eso necesitan tres semanas. Una vez el equipo está formado, llega el famoso “sprint 0” o “toma de requisitos” y esto nos lleva otra serie de semanas. Estamos hablando de que en noviembre el equipo ya tiene claro lo que va a hacer y lo que va a costar, y arrancamos. Necesitamos varios Sprints para tener algo en producción, hemos firmado un Producto Mínimo Viable en dos meses (todo un reto)… Para cuando tenemos algo que darle a nuestros usuarios estamos en enero… ¡Nadie juega ya a los Pokemon!
Hemos intentado competir en el mundo digital y hemos llegado muy tarde, ¡game over! Y todo esto sin usar factorías en diferentes países, lo que hubiera complicado todavía más la entrega de valor.
La capacidad de entregar es la clave de todo
Si te preguntara cuál es la capacidad de entrega de tu equipo software, ¿qué responderías? Seguramente piensas “depende de lo que tengamos que hacer”. Esto es cierto, pero, sin saber la capacidad de entrega de tus equipos, es difícil medir el coste de una oportunidad (como los pokemon).
Las empresas están orientadas a reducir costes, sobretodo en el área de tecnología, debido a que lo siguen viendo como un “gasto” y no como una “oportunidad”. Ese es el motivo de que haya más equipos Scrum midiendo puntos, que equipos midiendo métricas del valor real que aporta el producto a la organización.
El teletrabajo puntual ayuda a las personas a conciliar, pero cuando se convierte en un derecho, dificulta la entrega de valor ya que interfiere en las relaciones entre las personas. Por ejemplo, hay personas que se adjudican un día a la semana como de teletrabajo obligado, de pronto, hay una reunión urgente y se evita ese día, lo que afecta a la entrega de valor. Cuando el foco es la entrega, es importante que podamos interactuar de la manera más clara posible, necesitamos que haya la mejor comunicación.
Por tanto, Agile busca la entrega continua de valor, por eso la comunicación cara-a-cara es la más efectiva. Usar el teletrabajo está bien, pero usarlo para distanciar a los desarrolladores de los usuarios es lo que afecta a nuestra capacidad de entrega y de acertar.
Y tú, ¿mantienes a los desarrolladores unidos?
Qué articulo más bueno! Me ha encantado.
Y estoy totalmente de acuerdo, el trabajo cara a cara es mucho más eficiente.
Yo tengo una experiencia pasada en la que gestionaba un equipo de desarrollo con scrum. La mayoría estaba en la misma ubicación, pero teníamos algunas personas en otras oficinas. Y era un problema, porque a pesar de que eran (y son) grandes profesionales, se perdían muchas conversaciones informales, la química no era la misma…. y eso se notaba en la famosa entrega. Yo mismo hice un estudio con dos años de histórico basado en los puntos historia, y los resultados eran brutales 😲😲😲
Se que la gente está emocionada con el teletrabajo, pero cuidado, cuando el resultado es la entrega de valor… el teletrabajo no ayuda. Otra cosa es que, tengamos esa posibilidad cómo beneficio, por aquello de quedarnos en casa si un peque está malo, o tienen que cambiarnos la nevera… Es mi visión 🙂 gracias!
El manifiesto es del año 2001, y no existían las herramientas que podemos usar hoy en día. Cara a cara, como estar uno delante del otro, no tiene sentido en la actualidad. El teletrabajo no implica menos entrega de valor, pero para los SM también es un reto porque tienen que guíar a los equipos de otra manera.
Exactamente. Hace 20 años las video conferencia, incluso las redes sociales estaban en pañales. Hoy puedes gestionar perfectamente un proyecto de manera remota por teletrabajo. Sólo se debe cambiar el interruptor mental.
Creo que este artículo está demasiado orientado a la literalidad de los principios Scrum. El problema es cuando se consideran a las personas del equipo que trabaja en remoto como secundarios y no del mismo nivel que los presentes. ¿Cómo o por qué pasa eso? Mi experiencia me dice que sucede por estos motivos
1) Los que están en presencial dominan las reuniones por estar viéndose las caras con el resto de presenciales y se ignoran a los remotos (de hecho, hay veces que no se invita a los remotos a las reuniones)
2) El canal informal supera en importancia al canal oficial de comunicación. Si se establece un canal de comunismo informativo (slack, hangouts etc.) se igualan las condiciones entre todos los miembros del equipo
3) nos falta cultura de trabajo remoto. Hay empresas muy exitosas con un modelo full remote y sus productos son impecables. Gitlab por ejemplo. De hecho, en su blog hay una gran cantidad de información sobre su filosofía del teletrabajo y no están ubicados físicamente nadie en ninguna oficina (incluyendo el CTO)
Aunque no sea representativo para nadie, yo estoy participando en un proyecto Scrum, con un equipo de 15 personas que nunca habían trabajado en Scrum, y no nos hemos puesto cara (las videoconferencias les funcionan fatal) y estamos haciendo una entrega de valor constante y muy bien planificada (PoC’s y quick wins Porque estamos en fase inicial). Y es a base de iterar y conseguir flujos de comunicación fiables, uso de herramientas, pair programming y hablar por videollamada. Creo que este proyecto si va todo bien acabaremos en febrero y probablemente no nos pongamos cara físicamente nunca, pero no dudo que será un éxito aunque no hayamos compartido mesa jamás
La pregunta no es si se puede trabajar a distancia, es evidente que en 2020 se puede, hay muchas herramientas para poder hacerlo. La pregunta es, ¿si las mismas personas estuvieran juntas serían capaces de entregar más valor? En mi opinión digo que sí, porque el estar juntas creo que ayuda, fíjate que has puesto varios problemas típicos cuando el equipo está semi-junto.
Esto plantea también un debate, que seguramente tenga en github: si nos centramos solo en presencialismo, seguramente haya muchas personas del mundo con las que no podamos contar, y nos gusta trabajar con ese talento. Por tanto, es mejor que lo tengamos.
Por encima de todo, hay un debate más importante Ernesto: ¿podemos decidir como equipo cómo queremos trabajar? Porque quizás, no necesitemos estar todos juntos siempre. Podemos estar dos días y el resto desde casa sabiendo como hemos organizado el trabajo. Faltan muchas conversaciones sobre organización del trabajo, y, ahí, el teletrabajo es una opción más que podemos utilizar 🙂
Eso sí, aquí lo relevante es la entrega de valor, porque en el mundo digital funciona así, o entregas valor o no sirve de nada. A nadie le importa si el equipo que nos da un software está a distancia o en presencial… nos importa que nos resuelva un problema 🙂