Categorías
Agile Teams

Mi experiencia en la CAS 2015 y el ego

Para los que me conocéis sabréis que el tema de llevar equipos de desarrollo de software es lo mío, para nada me considero un erudito en la materia, más bien al contrario, tengo mucho que aprender y cada día aprendo cosas nuevas pero creo que es algo que se me da bastante bien, disfruto con ello y tengo algún éxito que contar, también fracasos y momentos duros que al fín y al cabo es cuando uno más aprende.

El pasado verano mi compañero Miguel Ángel García me pasaba un link en el que decía que la CAS abría su call for papers para la edición de este año y me animaba a presentar algo. Al principio no le di mucha importancia pero trás decir las palabras mágicas “a que no hay hue***” no pude resistirme a mandar una idea.

No tuve que pensar mucho, en el 2015 viví en mis propias carnes algo que más tarde llamé EDD (Ego Driven Development). No es el objetivo de este post el desarrollar el tema pues para eso habrá otro más detallado, tan solo quisiera transmitir el porqué elegí esa idea. Principalmente es porque en el último año y medio en diferentes equipos he podido vivir como el ego que todos tenemos, bien tratado y dirigido puede llevar a hacer de un equipo normalito o incluso flojo a ser uno de los mejores y el caso contrario, un ego descontrolado, una diva en el equipo mezclada con alguna puñalada por la espalda y una pizca de maquiavelismo puede hacer no solo que un equipo fracase si no que un producto se vaya al traste.

Estoy seguro que todos tenemos en mente casos como estos y no solo en el ámbito del desarrollo de software pues somos humanos y todos tenemos nuestro pequeño orgullo y ego por tanto en cualquier grupo u organización podremos encontrarlos. Debido a que estas situaciones me han tocado personalmente me decidí a hablar sobre ellas.

Trás unos meses de espera mi charla fue seleccionada como “Lightning”, se trataba de un formato corto de unos 15 minutos, no eran los 45 que me hubiera gustado pero me valía para contar mi idea. Como se dice en mi tierra manchega “me puse más contento que unas castañuelas”.

Como siempre me pasa no rematé la presentación hasta la noche anterior, en ese momento justo al terminar vi que mi Keynote no guardaba la copia en iCloud, no le di importancia pues me iba a llevar mi propio Mac, ¿qué podría pasar? Lo llevaba en el sitio más seguro.

image_large

Y por fín comenzó la CAS, abriéndola un magnífico Eugenio Moliní que con sus experiencias vitales y de superación personal nos dejó a todos boquiabiertos, si hubiera tenido un sombrero en ese momento me lo hubiera quitado. Seguí asistiendo a algunas charlas a lo largo de la mañana, la mía era a las 16h.
Entre tanto fui a almorzar con mi mujer que trabaja cerca y mientras iba ocurrió la fatalidad, la correa de la banbdolera donde llevaba el Mac se rompe y cae al suelo, en ese momento no me percaté de la magnitud de la tragedia hasta que a las 15h me metí a otra charla y al abrir el Mac resulta que no enciende, el golpe ha debido de estropear algo. En ese momento podéis imaginar los sudores fríos que me entraron, recordad que mi presentación estabas ahí y solo ahí, ni en la nube ni ningún otro sitio, de nuevo Murphy actuó y de la manera más malévola que podría. En ese momento no entré en pánico, pedí a alguien de la organización de la CAS un portátil para deprisa y corriendo rehacer la presentación teniendo en cuenta tan solo los recuerdos de la que había hecho la noche anterior. Desde aquí agradecerles que me prestaran ese portátil pues me salvaron y al final creo que la presentación me quedó mejor incluso que la original, lo que son las cosas. Consejo: haced siempre siempre copia de seguridad de vuestras presentaciones, en la nube, en un pen drive, en una caja de seguridad de un banco suizo, en pdf, word, wordperfect, todos los formatos que se os ocurran.

Llegó mi turno, la sala llena y aunque al principio estuve algo nervioso pero me vine arriba enseguida, fueron solo 15 minutos de charla, lo sé, pero los viví como si hubieran sido muchos más. Tampoco es que haya sido mi primera charla, he tenido muchas pero quizás porque el momento en lo personal era cuando más necesitaba un empujón, el caso es que salí de allí con el ánimo por las nubes, super orgulloso, a la gente le había encantado y al parecer el tema del ego en los equipos de desarrollo de software es un mal endémico, espero que haya servido un poco de ayuda mis palabras aunque sea para que sepáis que no estáis solos.

Por lo demás de la CAS me llevé la agradable sensación de encontrarme con un antiguo compañero de trabajo, Jorge Moratilla, un profesional como la copa de un pino y mejor persona que llevábamos tiempo sin vernos y pudimos ponernos al día. Gracias Jorge.

Os dejo el link a la presentación por si queréis echarle un vistazo y publicaré el video cuando lo suba la organización de la CAS.

Slideshare

Categorías
Agile Teams

Evangelizando Scrum

Uno de los retos más complicados a los que se suelen enfrentar todos los que forman parte de algún equipo que abrace las metodologías ágiles es contar en qué consiste su forma de trabajar a los a los civiles (aquellas personas ajenas al mundo tecnológico/del software y que no tienen porque entender nuestra jerga y tecnicismos). Esta labor es aún más complicada cuando tu jefe o algún superior al que reportas es un civil. Normalmente esta ardua y peligrosa tarea recae sobre los Scrum Masters, pues entre otras, su función evangelizar en las bondades y también defectos de las metodologías ágiles, en concreto Scrum aunque también hay cabida para otras como Kanban.

Voy a profundizar un poco en algunas aseveraciones que he hecho pues si bien algún profesional del mundo Agile sabe de lo que hablo, lo más probable es que el resto no.

Quisiera empezar por la necesidad casi imperiosa que tienen todos los Scrum Masters de evangelizar a todo bicho viviente con el que se cruza. La razón de este comportamiento no es porque de repente se les hayan abierto las puertas del cielo y se hayan convertido en profetas si no porque si bien Scrum puertas adentro se perciben todos sus beneficios, se viven las liturgia y se impregna el sentimiento de equipo; de puertas hacia fuera estas sensaciones son difícilmente perceptibles por lo que es casi obligatorio el ir por ahí contando las maravillas y detalles de la metodología con la que trabajas.

Aunque no te lo creas pero tu jefe o responsable no tiene porqué saber de Scrum y lo mismo ni le importa. Está bien, no pasa nada, estas situaciones se dan muy a menudo, cuando reportas a un mando no técnico, bien de negocio, o miembros del board de la compañía. Este escenario no tiene porque causarnos respeto o miedo, aquí os comparto algunos consejos sobre como abordar esta situación:

  • Desde el día uno tu responsable tiene que ser consciente del trabajo que vas a realizar y como vas a hacerlo.
  • Hazle un breve resumen de lo que consiste la metodología, no se trata de hacerle un curso si no que sepa los aspectos básicos de los procesos que vas a seguir.
  • Avísale de que habrá situaciones que no entienda pero que cuando eso ocurra ahí estarás tú para explicárselas.
  • Invítale a las liturgias, sobre todo al principio, si participa algún daily meeting, planning o retrospectiva seguro que le es mucho más encillo entender todos los conceptos. Desde luego no es lo mismo que te lo cuenten a vivirlo tu mismo.
  • Se transparente, cuando haya problemas (y en mundo del software siempre los hay) trata de contar todo como realmente es, no maquillar la realidad por muy dura que sea. Siempre será preferible esto a que se te pueda acusar de ocultar los problemas, ya que aunque los del equipo saben que no es así pero desde fuera es difícil de entender que, por ejemplo, se les diga que no a una petición que hacen en medio de un sprint.

Estas son solo algunas de las situaciones en las que un Scrum Master o cualquier miembro del equipo tiene que poner un especial esfuerzo en evangelizar al personal. ¿Y tú? ¿has tenido que lidiar con una situación similar?, compártela con el resto en los comentarios.

Categorías
Agile Teams

Mi equipo es mejor que el tuyo

Las personas tendemos a compararnos con nuestros semejantes en todo momento. Desde que somos niños nos encanta fijarnos en lo que tiene nuestro hermano/a y lo deseamos con todas nuestras fuerzas, no importa lo que tengamos nosotros. En la cultura occidental en la que vivimos todo se ha convertido en una competición, el tener que llegar más arriba que el compañero, el ser mejor y si no se puede al menos el parecerlo. Estos son comportamientos inherentes a la persona (en algunos más que en otros obviamente) y que aunque no lo sabemos nos influyen en nuestro día a día.

Este post no tiene la intención de hablar de la psicología humana, ni de lo “envidiosos” que somos o dejamos de ser. A lo que quiero apuntar es a como en empresas o departamentos de software donde hay más de un equipo trabajando con metodologías ágiles se tiende a comparar unos con otros, bien sea por el comportamiento natural de medirse entre compañeros como cuando los responsables necesitan métricas para tomar algún tipo de decisión.

No comparemos peras con manzanas

El primer punto que aunque parece obvio en la práctica se comete muy a menudo el error de comparar equipos que lo único que tienen que ver entre ellos son que están compuesto por personas de carne y hueso, nada más.

Si tienes equipos distintos, en proyectos distintos, con responsables distintos, disciplinas distintas y roadmaps distintos. ¿Por qué comparar uno con otro? No tiene ningún sentido. En este caso lo que recomiendo es que si necesitamos tomar alguna decisión sobre movimientos o ajustes se haga sobre las personas en concreto basándonos meramente en criterios personales y no de equipos.

La velocidad no es un KPI

La velocidad de un equipo ágil es una métrica que nos indica el número de puntos que ha conseguido un equipo en un sprint. Este valor es muy irregular sobre todo cuando un equipo está en una fase inmadura, acaba de cambiar o comienza un proyecto nuevo. A lo largo de los sprints se va estabilizando.

La principal utilidad de esta medida es servir como herramienta al propio equipo a la hora de estimar a lo que puede llegar en un sprint. Si durante los últimos cinco sprints se han conseguido 40 puntos, al estimar para el siguiente cuando se han metido ya unos 38-40 el equipo sabe que su límite está cerca y no debe arriesgarse a coger más historias porque corre el riesgo de no poder terminarlas.

La velocidad ayuda a conseguir el objetivo último de usar metodologías ágiles: ser predecible.

¿Por qué la velocidad no es en absoluto un KPI para comparar equipos?

  • La medida de estimación de cada equipo es distinta, lo que para uno supone cinco puntos para otro son ocho.
  • La velocidad es una herramienta de apoyo a la estimación interna.
  • Es muy sensible a factores externos como pueden ser sprints más cortos, absentismo de sus miembros, situaciones inesperadas, etc.

Cada equipo tiene su propia historia

Incluso siendo equipos distintos que trabajan bajo el paraguas del mismo proyecto tienen historias y casuística distintas. Cada uno de ellos ha pasado por problemas y situaciones que en muchas ocasiones no se parecerán los unos a los otros, las decisiones tomadas ante estas situaciones por sus respectivos Scrum Masters o Product Owners (si fuera distinto) de seguro que han marcado el resultado de lo que se intenta comparar.

Sería muy irresponsable juzgar a un equipo o compararlo con otro sin tener en cuenta por todo lo que ha pasado.

Mi equipo ha llegado a su objetivo y el tuyo no

Volvemos otra vez a las peras y las manzanas, he visto en muchas ocasiones hacer comparaciones entre equipos bajo el pretexto de “El equipo X ha llegado a su objetivo y el equipo Y aún no”.

Si eran objetivos distintos, con roadmaps distintos, productos distintos e integrantes distintos. ¿Por qué compararlos?

Lo que SÍ se podría usar para hacer alguna comparación

Está claro en algunos momentos es necesario tener una visión global de todos los equipos sobre lo que se tiene una responsabilidad y cuando hay que tomar decisiones hacerlo en base a criterios objetivos, homogéneos, veraces y verificables.

Tener en cuenta el camino recorrido y los obstáculos que se han encontrado es importante a la hora de hacer una valoración, no sería justo juzgar a un corredor por hacer los 100 metros en veinte segundos teniendo que saltar vallas que otro que lo ha hecho en diez con el camino llano.

Actitud ante los problemas, todos los equipos y proyectos tienen situaciones difíciles a las que deben enfrentarse, ya que cada uno será distinta no podemos compararlos por la situación en sí ni si han tenido éxito o no resolviéndolas ya que puede haber factores externos que interfieran pero sí se puede analizar la actitud que ha tenido el equipo a la hora de enfrentarse a los problemas y los procesos que han seguido para la toma de decisiones.

Recolecta toda la información posible antes de tomar alguna decisión, seguramente cada miembro del equipo tiene una visión particular que te aporta información complementaria y tener sobre la mesa todos los puntos de vista te va a ayudar a la hora de decidir.

Seguro que os habéis visto reflejados en alguna de estas situaciones o habéis caído en la tentación de utilizar algunos de los elementos arriba descritos para mirar al equipo de al lado por el rabillo del ojo, yo también lo he hecho y por eso la experiencia me ha enseñado que hay que cambiar el filtro con el que nos miramos.

Categorías
Agile Teams

¿Es un pájaro?, ¿es un avión?, ¡es un Scrum Master!

En este post quiero comentar las peculiaridades, aventuras y desventuras, virtudes y defectos de un rol al que le tengo especial cariño, no sólo por haber tenido la suerte de trabajar en él si no porque realmente pienso que una figura así es necesaria en todas las profesiones. A estas alturas ya sabréis a quien me refiero, así es, ¡hablo del Scrum Master!

Si has continuado leyendo hasta aquí seguramente estés en uno de los siguientes grupos: 1: eres un gran conocedor de este rol; 2: no tienes ni idea de lo que es un Scrum Master y te pica la curiosidad 3: no tienes nada mejor que hacer y estás matando unos minutos. A los de los grupos 2 y 3, lo siento pero este no es un post para contar la qué es un Scrum Master, hay multitud de libros que van a contar la teoría mucho mejor que yo, personalmente recomiendo Succeeding with Agile de Mike Cohn (http://www.succeedingwithagile.com/); este es un post para hablar de la parte del trabajo de SM que no cuentan en los libros, y eventualmente los sentimientos que lo rodean, en este caso subjetivamente hablando desde mi experiencia.

  • El primer rasgo que quiero destacar es un Scrum Master es el hecho de que NO ES UN JEFE, es un líder, pero un líder con una peculiaridad, es un líder que sirve al equipo, se dice que el trabajo del SM ha terminado cuando el equipo puede operar perfectamente sin él. Esta figura es una parte esencial en los equipos porque hace que el resto del equipo pueda trabajar, resuelve problemas, les quita distracciones, engrasa la máquina y está a su disposición. Como bien dice mi gran amigo Ismael Arroyo (fantástico SM por cierto) cuando le preguntan en qué consiste su trabajo: “Simplemente quito palos de las ruedas, y no pocos”.
  • Es alguien social y comunicativo, ¡como no!, esta es una cualidad clave para el SM, gran parte de su tiempo se lo pasa tratando de convencer a los demás de las bondades de las metodologías ágiles y no solo al equipo (que se convence prácticamente solo) si no lo que tiene por encima, ¡esos son los verdaderos huesos a roer!. Los beneficios de esta cultura suelen ser poco tangibles si no es está dispuestos a ello y sus bondades tardan un tiempo en llegar, por eso es esencia hacer una gran pedagogía. Creedme cuando os digo que he visto grandes SM hacer de equipos verdaderas máquinas del “agilismo" y sacar productos estupendos y fallar en este aspecto.
  • Facilitador, todos los que andéis en este mundillo del software sabéis que siempre ha sido, es y será un caos, el software es probablemente una de las ingenierías más complejas debido a la infinita casuística, si a esto le sumas que las personas a veces sacamos a relucir nuestro orgullo torero por encima de todo pues hace falta una figura facilitadora que ayude a alcanzar acuerdos. Por el bien del SM estos momentos mejor que sean pocos por de tanto facilitar al final uno se resiente.
  • Energy & Empowerment, a veces pienso que los SM desayunan un tazón de Pharmaton todas las mañana porque no os imagináis la cantidad de energía y positivismo que desprenden, es la única manera de contagiarlo a los demás.
  • Mejora continua, cuando era pequeño quería ser médico, hasta que alguien que me quería quitar la idea de la cabeza me dijo que éstos se pasan la vida estudiando porque siempre salen nuevos medicamentos y técnicas, me asusté y me tiré por la informática, que iluso… Pues eso, un SM debe de tener un gran background técnico, programe o no, debe de estar al día de las últimas tecnologías y procesos para así, poder anticiparse a los problemas, que os aseguro llegarán.
  • Grano y paja, una de las tareas más complicadas a las que se va a enfrentar un SM es a saber distinguir cuando hay un problema, si de verdad lo hay, y ser transparente y reportarlo. Recordemos que el SM no es un representante de los trabajadores, tampoco es un jefe al uso, por tanto su mejor herramienta es la transparencia, mostrar las situaciones tal y como son para poder buscar la mejor solución.
  • El valor de la entrega, debe transmitir cuan importante es que cada sprint se entregue algo, por pequeño y minúsculo que sea, da igual, pero siempre debe de haber un incremento de funcionalidad, siempre se debe mostrar algo nuevo y este principio se lo debe trasladar a todos los miembros del equipo.

Si después de leer estas cualidades sigues queriendo ser un superhéroe llamado Scrum Master, ¡enhorabuena! este va a ser un trabajo para ti, si tienes tus dudas o no te crees un carajo todo esto del “agilismo”, no te culpo, es normal, por eso es necesaria tanta pedagogía que comento antes.

Como esto no es un artículo técnico ni una entrada de Wikipedia sobre lo que es un SM voy a mojarme y contar algunas de mis experiencias que he tenido en este rol que he desempeñado durante años. Os puedo decir sinceramente que para mi ha sido muy gratificante trabajar como SM, es un trabajo bonito y apasionante, sobre todo en el ámbito humano pues tienes mucho trato con los equipos.

Como decía Diego Rojas (@drobur), profesor de uno de los cursos de Scrum a los que asistí “El trabajo del SM es tomarse cafés con la gente” y vaya si tenía razón, tuve que empezar a tomarlos descafeinados si no quería sufrir ataques de nervios; ¿por qué los cafés? es el momento en el que entablas más relación con los compañeros, tienes que ser su consejero, ganarte su confianza, tienes que saber cuando tienen un mal día, uno bueno, las cosas que les preocupan, las que les gustan, las que les molestan…

Por otro lado no os voy a engañar, el trabajo de Scrum Master es agotador, sobre todo cuando tienes que lidiar con equipos o parte de la organización que no creen en los principios ágiles, ni quieren creer por mucha pedagogía o psicología que despliegues, eso es todo un reto, creedme; es difícil, sí, pero no imposible.
En resumen, os animo a que si os sentís atraídos por esta figura lo intentéis, que probéis porque realmente os enganchará y aunque hay momentos no tan buenos (como en todos los trabajos), merece la pena estar ahí.

Mientras tanto me tenéis a vuestra disposición tanto en los comentarios de este post como en mi contacto al que os invito a que me escribáis si tenéis alguna duda o consulta sobre este superhéroe llamado Scrum Master.