Archivos Mensuales: octubre 2014

Estrategias corporativas para generar confianza

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.

Traducido de Trust, por James Shore.

http://www.dosideas.com

Ya no es mi dinero: lecciones de poker por Kent Beck

Y esa es mi primera lección del poker. Retiro lo dicho. Mi primera lección del poker es que cuando dos extraños te piden unirse al juego, pierden un poco toda la noche, ofrecen cortar el mazo por $100 cuando el juego está por terminar, entonces tengo que contar el mazo antes y después de que hacen aparecer el as.

Okay, entonces esta es mi segunda lección del poker: cuando el dinero deja mi mano ya no es mio. La noche después al juego estaba increíblemente frustrado. Había perdido y perdido toda la noche. Seguia apostando y perdiendo, apostando y perdiendo. Todo lo que podía pensar era en el próximo juego para poder recuperar mi dinero.

En el trascurso de la sigueinte semana me obsesioné con esa idea: debeía recuperar mi dinero. Y a la vez, una parte de mi estaba al costado diciendo: “Disculpame, hola, eso no tiene sentido”. En algún momento me di cuenta lo que estaba mal con mi razonamiento – no era mi dinero. Había dejado de ser mi dinero ni bien alguien más lo había ganado. De hecho, había dejado de ser mi dinero del momento en que puse la apuesta. Le di mi dinero al juego, y el juego le dio el dinero al ganador, y eso fue todo. No podía recupera mi dinero porque no era mi dinero.

Paz. A veces las obsesiones funcionan así. Te das cuenta lo que estaba mal con tu razonamiento y el ciclo se detiene. Esta fue una de esas veces. No era mi dinero. No lo podía recuperar, porque no era mio. La próxima vez que jugué, tan sólo jugaba. Comencé con $20 y fui desde ahí.

Muchos reconocerán la Falacia del Costo Irrecuperable. El dinero ya había sido apostado, se había ido, era irrecuperable.  No tiene sentido incluir eso en la toma de decisiones. Conocía la Falacia del Costo Irrecuperable, pero no la tenía en cuenta.

Esta misma situación ocurre todo el tiempo en la programación. Venimos de una larga sesión de refactor, cada paso del cual es perfectamente seguro. Y entonces corremos las pruebas. Una prueba se rompe. ¿Qué deberíamos hacer? ¿Qué deberíamos hacer si el error no es obvio? ¿Qué deberíamos hacer si el error no es obvio y llevamos haciendo el refactor por un minuto? ¿Por una hora? ¿Un día? ¿El tiempo invertido influye en cómo proceder?

Mi experiencia es que lo correcto en esta situación en donde no sabemos lo que hicimos para romper las pruebas es volver inmediatamente a un estado verde conocido, y volver a ejecutar las pruebas. Luego comenzar el refactor otra vez y correr las pruebas a cada paso. Pero, y aquí está la parte irracional, mientras más tiempo llevamos haciendo el refactor, más tentados estamos en seguir. Esta es la Falacia del Costo Irrecuperable en acción.

Mientras más llevo haciendo un refactor, menos recuerdo todos los pasos, más dificil será encontrar el error, mayor el valor de empezar otra vez. Mientras más dificil es comenzar otra vez (emocionalmente), más valioso es comenzar otra vez.

Ya no es mi tiempo. ¿Estuve haciendo un refactor por un minuto? ¿Una hora? ¿Un día? No importa. Ya no es mi tiempo. Se lo di al programa. Se fue. Lo que haga ahora no debería estar influenciado por la magnitud del tiempo que ya invertí. Ya no es mi tiempo.

Y mientras escribo esto me doy cuenta que con JUnit soy culpable de una variación de la Falacia del Costo Irrecuperable. Quienes lleven leyendo mi blog por algún tiempo, me habrán escuchado quejarme por no encontrar un modelo de negocios alrededor del éxito de JUnit para tener ganancias. El razonamiento incorrecto es algo así: JUnit creó un montón de valor en el mundo (miles de millones de dólares según mis cálculos), y no recibí nada de eso.

¿Y qué? Si JUnit no hubiera creado nada de valor pero estuviera en la misma posición, ¿qué debería hacer? Exactamente lo mismo que si hubiera creado millones de dólares o miles de millones. Es la Falacia del Beneficio Irrecuperable. Lo pasado ya fue. No es mi beneficio. Todo lo que importa es la situación actual. Toda la energía o pensamientos que ponga en el pasado tan sólo dificultarán mi pensamiento.

Así que acá está mi resolución. Voy a pensar sobre el estado actual de las pruebas de desarrollo, voy a analizar las tendencias, y me voy a adelantar. Así es como voy a vivir de JUnit. Ah, y me voy a asegurar de contar el mazo de cartas, o mejor aún, no apostar con extraños.

http://www.dosideas.com