En el artículo anterior James Shore compartió algunas estrategias de equipo para generar confianza. En este artículo continuamos la serie con estrategias corporativas que apunten a crear entornos de confianza para que los equipos logren crear los mejores productos posibles.
La primera impresión...
Conozco a alguien que trabajó con dos equipos para una organización. Un equipo usaba Extreme Programming (XP), cumplía sus compromisos, y entregaba de forma periódica. Al otro equipo no le iba tan bien: se atrasaba en la planificación y no tenía software funcionando para mostrar. Y sin embargo, cuando la empresa tuvo que hacer ajustes de personal, dejó partir al equipo XP en vez de al otro equipo!
¿Por qué? Cuando la gerencia miraba al equipo en problemas, veía programadores trabajando duro, quedándose largas horas y cubriendo las paredes con diagramas UML. Cuando miraba al equipo XP, la gerencia veía personas que hablaban, se reían, y se iba a casa a las cinco de la tarde, sin nada más que algunos borradores y gráficos en pizarrones.
Nos guste o no, nuestros proyectos no existen en el vacio. XP puede parecer extraño y diferente para una organización que nunca lo usó. "¿Realmente están trabajando?", se puede preguntar alguien de afuera. "Es demasiado ruidoso y confuso. No quiero trabajar así. Si tienen éxito, ¿me van a forzar a trabajar así también?".
Irónicamente, mientras más éxito tiene XP, más preocupaciones genera. Alistair Cockburn lo llama anticuerpos organizacionales. Si no se tienen en cuenta, los anticuerpos de la organización podrían desmantelar a un equipo exitoso de XP.
No importa qué tan efectivo seas en cumplir los compromisos técnicos, vas a estar sin el apoyo del cliente. Si, cumplir la planificación y las expectativas técnicas ayuda, pero las habilidades no-técnicas (habilidades interpersonales) que practique el equipo pueden resultar ser igual de importantes para construir confianza en el equipo.
¿Suena injusto e ilógico? Seguro que la habilidad de entregar software de alta calidad es lo que realmente importa.
Es injusto e ilógico. Y también es la forma en la que piensan las personas - incluso los programadores. Si el cliente no nos tiene confianza, no van a participar con el equipo, y dañará nuestra habilidad de entregar software valioso. Incluso pueden iniciar una campaña en nuestra contra.
No esperes a que ellos se den cuenta cómo los puede ayudar tu trabajo. Mostráselo.
Estrategia #1: demostrar actividad
Hace ya varios años contraté una empresa de mudanzas para mudar mis pertenencias de un departamento a otro. Cuando llegaron, me sorprendió lo activos que se veían - se movían con rapidez del camión al departamento y de vuelta. Esto me llamó la atención porque les estaba pagando por hora. No tenían necesidad de moverse con tanta velocidad.
La mudanza me impresionó. Sentía que estaban dedicados a satisfacer mis necesidades y cuidar mi bolsillo. Si todavía vivieran en esa ciudad no dudaría en contratarlos otra vez. Se ganaron mi confianza.
En el caso de los equipos de software, mostrarse activos es trabjar de forma energizante, productiva. La sensación de productividad se logra con un ambiente de trabajo informativo, informes adecuados, y demos en la iteración.
Estrategia #2: cumplir los compromisos
Si el cliente ya trabajó con otros equipos de software, es probable que ya tenga cicatrices y malas experiencias con planificaciones fallidas, defectos sin solución, y dinero desperdiciado. Además, probablemente no sepan mucho sobre el desarrollo de software. Esto los ubica en la incómoda posición de tener que confiar en nuestro trabajo, habiendo sufrido malos resultados anteriormente, y no poder determinar si trabajamos mejor que antes.
Mientras tanto, el equipo consume miles de dólares por semana en salarios y soporte. ¿Como hace el cliente para saber si estamos gastando este dinero de forma apropiada? ¿Cómo hace para saber si el equipo es competente?
Los clientes no saben cómo evaluar nuestro proceso, pero pueden evaluar los resultados. Hay dos clases de resultados que resultan muy claros para el cliente: el software que funciona y el cumplir con los compromisos.
Afortunadamente, los equipos XP demuestran estos dos resultados periódicamente. El equipo se compromete a entregar software que funciona cuando planifica la iteración y los planes de entrega. Se demuestra que se cumplió el compromiso de la iteración en la demo, y se demuestra que se cumplió el compromiso de entregas como se había predefinido.
Estas entregas periódicas y regulares ayudan a construir confianza con el cliente como ninguna otra cosa. Es extremadamente poderoso. Todo lo que se necesita es crear un plan que podamos cumplir... y luego cumplirlo.
Estrategia #3: gestionar los problemas
[inset side="right" title="¡Avisar!"]Cuando encontramos un problema, lo primero es hacérselo saber a todo el equipo. Como máximo debe surgir en la próxima reunión diaria. Así todo el equipo tiene la oportunidad de ayudar a resolver el problema.[/inset]
Algunas iteraciones no llegan a buen puerto el último día. Me recuerda a cómo sentí cuando me pidieron integrar un proyecto después de todo un año de desarrollo sin integrar. ¿Qué hacer cuando nuestro mejor plan se va a los caños?
Incluso allí tenemos oportunidad de hacer las cosas bien. Cualquiera puede verse bien cuando la vida va de acuerdo al plan. La verdadera habilidad se demuestra lidiando con problemas inesperados.
Lo primero es limitar nuestra exposición al problema. Debemos trabajar primero en las tareas más difíciles o inciertas de la iteración. Vamos a encontrar antes a los problemas, por lo que tendremos más tiempo para solucionarlos.
Si el problema es menor, quizás podamos tratarlo en la iteración usando algo del tiempo de slack. En ese caso, debemos juntarnos cuanto antes con el equipo y replanificar. Quizás debamos quitar una historia entera, o reduzcamos el alcance de algunas historias.
[inset side="right" title="Problemas grandes"]Mientras más grande sea un problema, antes deberíamos avisarlo.[/inset]
Cuando identificamos un problema, debemos informarlo al cliente. Van a apreciar nuestro profesionalismo aunque no les guste el problema. A veces espero hasta la demo de la iteración para contar problemas que pudimos resolver por nuestra cuenta, pero los problemas grandes se los informo al cliente de forma inmediata.
Mientras antes el cliente sepa del problema (y créanme, eventualmente se van a enterar), el cliente va a tener más tiempo para atajarlo. Incluyan un análisis de soluciones posibles y también el costo técnico de cada solución. Se requiere de coraje para tener esta discusión - pero tratar un problema con éxito ayuda a construir confianza como ninguan otra cosa.
[inset side="right" title="Ojo con el sobre-esfuerzo"]Depender del sobre-esfuerzo demuestra que hay un problema sistémico.[/inset]
Sin embargo, tengan cuidado. Es fácil enfocarse demasiado en cumplir con el compromiso de forma que terminemos dañando la confianza. Supongan que necesitamos un par de horas extra en la iteración para terminar una historia valiosa. Está bien un poquito de sobre-esfuerzo. Aplicar sobre-esfuerzo a un sprint importante puede hasta ayudar a la moral y cohesión del equipo, si se aplica correctamente. Ahora, depender del sobre-esfuerzo para cumplir compromisos atenta contra la energía del equipo y disminuye nuestra habilidad de absorber problemas. Irónicamente, nos lleva a incumplir más compromisos; implícitamente le prometemos al cliente más trabajo del que podemos entregar por el precio que esperan pagar, en tiempo y forma.
Si nos encontramos haciendo mucho sobre-esfuerzo, hay algo que está mal. La mayoría de las iteraciones no deberían tener problemas. Y cuando un problema aparece, deberíamos poder resolverlo usando tiempo de slack, y no sobre-esfuerzo. Debemos buscar problemas sistémicos si vemos que un equipo hace más del 10% de sobre-esfuerzo en más de una iteración por cuatrimestre.
Estrategia #4: respetar los objetivos del cliente
Cuando se conforma un equipo XP, suele llevarle un tiempo a sus miembros pensar como equipo. Al principio, los programadores, testers y el cliente se ven como grupos separados.
Los clientes on-site son los más complicados. Les resulta extraño ser parte de un equipo de desarrollo. Prefieren trabajar en oficinas normales, con colegas normales. Estos colegas suelen ser miembros influyentes de la empresa. Si el cliente no está contento, lo va a transmitir a los demás.
Cuando se empieza un proyecto XP, los programadores deben hacer un esfuerzo extra por darle la bienvenida a los clientes. Una forma particularmente efectiva es tratar con respeto los objetivos del cliente. Esto puede significar, por un tiempo, suprimir los comentarios cínicos sobre la planificación y las características.
El respeto va de ambos lados, y los clientes también deben suprimir su tendencia natural a quejarse por la planificación y discutir estimaciones. Hago énfasis en el rol de los programadores porque juegan un rol muy importante frente a la percepción de la empresa.
Otra forma para que los programadores se tomen con seriedad los objetivos del cliente es buscar formas alternativas para cumplir estos objetivos. Si el cliente quiere algo que podría llevar mucho tiempo o involucra un riesgo técnico muy grande, se pueden sugerir enfoques alternativos para lograr el mismo objetivo a menos costo. Si hay alguna mejor forma de lograr un objetivo que el cliente no consideró, no duden en avisarle - especialmente si no resulta muy difícil hacerlo.
A medida que los programadores y los clientes van teniendo estas conversaciones, se van derribando las barreras y se construye confianza. Y a medida que la empresa vea esto, su confianza con el equipo también aumentará.
También podemos construir con los grupos de interés de la empresa. Consideren esto: la próxima vez que algún interesado nos detenga en el pasillo y nos haga un pedido, ¿qué pasaría si contentos y en el momento agarramos unos post-it, lo ayudamos a escribir la historia, y la llevamos al gerente del producto para priorizar?
Podría significarnos una interrupción de 10 minutos, pero imaginen cómo se sentirá el interesado. Le respondimos con interés, lo ayudamos a expresar su necesidad, e inmediatamente tomamos los pasos necesarios para que se planifique.
Esto tiene infinitamente más valor que mandar un e-mail al agujero negro que resulta ser los sistemas de petición de proyectos.
Estrategia #5: promocionar al equipo
También podemos promocionar directamente al equipo. Un equipo pegaba fotos y gráficos en la pared exterior de su área de trabajo que mostraba en qué estaban trabajando y cómo progresaban. Otro invitaba a todos en la empresa a atender las demos de las iteraciones.
Ser abiertos sobre lo que hacemos también ayuda a que las personas aprecien al equipo. Es probable que otras personas de la empresa sientan curiosidad, y quizás ansiedad, sobre esta extraña forma de desarrollar software. Esta curiosidad de puede transformar en resentimiento si mantenemos cerrado y en secreto al equipo.
Hay muchas formas de ser abiertos. Pueden organizar almuerzos en donde describen el proceso, festivales de codificación públicos donde demostrar prácticas de XP, o un "Dia de casa abierta XP" en donde invitamos a las personas a ver cómo se trabaja e incluso participar un ratito. Si les gusta el show, también pueden usar pines o sombreros en la oficina que digan "Preguntame sobre XP".
Estrategia #6: ser honestos
No debemos exagerar en nuestro entusiasmo por demostrar el proceso. Este comportamiento incorrecto incluye pasar por alto defectos conocidos en la demo de una iteración, darse crédito por historias que no están 100% terminadas, y extender la iteración un par de días para terminar todo lo comprometido.
Son fraudes menores, si. Incluso podrían pensar que "fraude" es una palabra demasiado fuerte - pero todos estos comportamientos le dan la impresión al cliente que hicimos más de lo que realmente hicimos.
Hay un motivo práctico para no actuar así. Los futuros interesados y clientes esperarán que termines sus características igual de rápido, cuando en realidad no terminaste las primeras. Podemos construir un backlog que parezca terminado, pero que en realidad no lo está. En algún momento, vamos a tener que terminar el primer backlog, y el desfasaje de la planificación va a causar confusión, desilusión y enojo.
[inset side="right" title="Compromiso honesto"]Sólo comprometerse a tantas historias como el equipo pueda completar.[/inset]
Incluso los equipos honestos pueden meterse en problemas. En su deseo de verse bien, los equipos a veces se comprometen a más historias de las que pueden implementar bien. Terminan el trabajo, pero a costo de tomar atajos sin hacer el diseño ni los refactors suficientes. El diseño se ve afectado, los defectos empiezan a aparecer, y el equipo termina de repente avanzando mucho más lento y luchando por la calidad del código.
De forma similar, no se tienten en contar historias que no están "Terminadas Terminadas". Si una historia no está terminada por completo, no cuenta para la velocidad. Ni siquiera se toma crédito parcial. Como dice el dicho: el primer 90% se lleva el 90% del tiempo... y el último 10% se lleva el 90% del tiempo. Es imposible saber cuánto falta hasta que una historia está terminada por completo.
El desafío de decir la verdad
El proyecto más desafiante que tuve que hacer de coach tenía una fecha de entrega muy apretada (¿no es así siempre?). Nuestro cliente final era un cliente crítico: una gran empresa que representaba la mayor parte de nuestros ingresos. Si no los satisfacíamos, nos arriesgábamos a perder una enorme porción vital de nuestro negocio.
Sabiendo lo que estaba en juego, me puse como prioridad armar un plan de entregas confiable. Seis semanas después, no sólo no habíamos implementado las primeras seis semanas de historias, sino que también teníamos una estimación confiable de nuestra velocidad y una lista estimada completa de nuestras historias restantes.
Y nos mostró que estábamos terminado tarde - muy tarde. Teníamos que terminar en siete meses. Y de acuerdo al plan, ibamos a terminar en trece.
El líder del proyecto llevó el plan a nuestro director. Las cosas fueron de mal en peor. Nos prohibió compartir esta noticia con el cliente final. En cambio, nos ordenó cumplir como sea con la fecha original.
Ya sabíamos que no podíamos cumplir con esa fecha. No teníamos tiempo suficiente para agregar personas, les llevaría demasiado tiempo conocer la base de código. No podíamos recortar alcance porque no podíamos admitir el problema al cliente.
Nuestros trabajos estaban en juego e intentamos hacer el esfuerzo. Ignoramos la Ley de Brooks y contratamos algunos programadores, e hicimos todo lo posible para ponerlos productivos lo antes posible sin distraer a los miembros productivos del equipo. A pesar de nuestro mejor esfuerzo, entregamos seis meses tarde un producto lleno de defectos - que resultó ser a unas semanas de nuestra predicción original. Perdimos al cliente.
Quizás también hubiéramos perdido al cliente incluso si le decíamos la verdad. Es imposible decir. Sin embargo, mi experiencia me dice que los clientes, los interesados y los gerentes aprecian que se los participe de la solución. Cuando se demuestra progreso de forma semanal, se establece credibilidad y confianza. Con esta credibilidad y confianza, los clientes están mucho más interesados en trabajar junto al equipo para negociar y alcanzar los objetivos.
No me voy a volver a involucrar en una situación así. Las planificaciones no pueden ser secretas; no hay eventos milagrosos; la fecha de entrega real eventualmente llega.
En cambio, voy a hacer todo lo posible por presentar la situación más precisa que pueda. Si un defecto tiene que arreglarse para la entrega, planifico el arreglo antes que nuevas características. Si nuestra velocidad es menor a lo que quiero, igualmente informo fechas basadas en la velocidad real. Esa es la realidad, y sólo siendo honestos sobre la realidad podemos gestionar las consecuencias de manera efectiva.