lunes, 31 de diciembre de 2012

Concejo Municipal

Hace tiempo formamos un concejo municipal / terapia gerencial. Somos cuatro y aunque cada quien tiene un puesto, en esas sesiones hacemos bolita el organigrama y discutimos sin pelos en la lengua.  Dos veces por semana, además de un rápido checkup proyectil, desahogamos frustraciones, comentamos ideas y nos damos palmaditas en la espalda o zapes.


Es bueno tener a ese equipo.  Todos somos relativamente novatos en esto de estar a cargo de gente.  Por eso, estar en un grupo de iguales que saben y comprenden por lo que estás pasando es importante para seguir intentándolo.  Hacemos pair-management si queremos hablar en Agile.  Los cuatro tenemos personalidad y habilidades diferentes y a veces, puntos de vista opuestos.  Sin embargo, respetamos la inteligencia y habilidades de los demás y aprendemos a trabajar juntos, explotando lo mejor de cada quien ("magia", le dicen) por el bien de toda el área.


Estos meses han sido difíciles. La organización ha pasado por cambios fuertes y hasta tristes.  Aun así, hemos tenido éxito mejorando nuestras coberturas de junit, equipos auto-organizados y seguimiento del proyecto.  El crédito es sin duda, de los chavos.  Pero sin ese concejo municipal, todo eso no se hubiera dado.

Esto, entre muchas otras cosas, hace tener grandes expectativas laborales en el 2013.

jueves, 22 de noviembre de 2012

¿Quién quiere ser gerente?

Ayer, en el cumpleaños-despedida de un Big-Padawan, el festejado hizo un comentario más o menos así: “capaz que cuando vuelva, me encuentro a todos como gerentes”.  Mi cerebro lo procesó un poco lento debido a que los niveles de alcohol lo estaban afectando.

¿Quién demonios quiere ser gerente?

La gente que hace software, pero que REALMENTE nos apasiona hacer software no se puede separar del código mucho tiempo.  Con cada proyecto intentamos volver a sentir ese mind-blow de la primera vez que programamos: creador todopoderoso, genio y poseedor de uno de los secretos del universo que son vedados para los mortales.

Por eso, vemos gerentes y líderes de proyecto que a la primera oportunidad se meten a hacer código (o pruebas, ja).  No hay definiciones de puesto lo suficientemente rígidas que alejen a un “mando superior” de “ensuciarse las manos”.

¿Por qué queremos ser gerentes?

Existe la presión social de escalar.  En las tarjetitas de presentación se llaman Developer Jr y Senior.  Líder, Gerente, Subdirector, CEO, Presidente Mundial.  Nos han enseñado que si queremos ganar más dinero, prestigio o simplemente, poder decidir e influir, necesitas tener un puesto de mando.

Nos cuadramos ante el título y aplicamos el organigrama para presionar a otras áreas.  Eso es tristísimo.  Eso quiere decir que no sabemos trabajar en equipo, que aplicamos el CYA (cover your ass) y no aprendemos.  Ser gerente y servir sólo para eso es, desde mi punto de vista, un trabajo horrible y sucio. Cuando trabajamos así, tenemos unas enormes anteojeras que nos impiden ver más allá de nuestro mundito.

No se necesita ser gerente para ser líder, para proponer nuevas formas de trabajo, para influir en la gente.  Sólo se necesita un ambiente en el que te sientes feliz trabajando.  Que te permite equivocarte y ser creativo.  En el que todos son escuchados y se sienten seguros.  En el que tenemos oportunidad para aprender cosas nuevas.

Ése es mi sueño.  Creo firmemente que es la única manera en la que la gente dará todo su potencial.  Pero es muy, muy difícil.  Espero que cuando volvamos a ver al Big Padawan, no seamos gerentes.

martes, 6 de noviembre de 2012

Aprendizaje y retroalimentación

Alguna vez leí que para comprender e interiorizar un concepto nuevo, es necesario que te lo digan siete veces. No estoy segura que sólo decirlo sea suficiente. Hoy me di cuenta que la retroalimentación es parte importante en el proceso.

Siempre he tenido el sentimiento que el programador no tiene idea de cómo va el release o el sprint. Y no es su culpa; durante mucho tiempo, hemos instruido sólo a líderes de proyecto sobre gráficas y seguimiento de proyecto y les decimos que afinen su puntería para atinarle a los programadores que necesitan latigazos.

Con el equipo auto-organizado, este seguimiento recae en todos. Todos deben tener visibilidad de cómo va el equipo (no sólo sobre su trabajo) y si van a terminar a tiempo. A veces se piensa que con la junta diaria se tiene esta visibilidad. Falso: ahí te enteras, si es que el programador lo dice, los problemas que hay. El impacto de esos problemas en el equipo completo, puede no verse con claridad.

Si a siete veces nos vamos, en cuestiones de seguimiento del sprint / release, llevo apenas 1) Explicación 2) Juego de serpientes y escaleras 3) Explicación del dashboard a los pocos días de avance. 

Ayer les mandé por mail, el dashboard para el seguimiento. El mail lo ignoraron la mitad de los integrantes; el resto que sí lo leyó, ninguno entendió de qué se trataba. Y por supuesto, nadie me comunicó lo que les pasaba por la mente.

Aunque no tenía intención de revisar el dashboard en equipo, el contarles la técnica pomodoro para mantener el WIP (Work in Progress) bajo, nos hizo revisar las actividades planeadas. Entonces ocurrió la magia que sólo pasa en equipo. Los que no saben preguntan, los que saben contestan con su experiencia. Yo apenas intervengo.

Un par de horas después de la junta, el gap entre la fecha esperada y la planeada se ha cerrado en la gráfica de burn-down. Pero más importante: aprendí que ignorar el ser ignorada es una piedrota para dar una efectiva retroalimentación.

martes, 23 de octubre de 2012

Serpientes y Escaleras Burn-up&down

Estoy entrenando a uno de los equipos para ser auto-organizado. Es decir, no hay un líder formal que asigne tareas, vigile la calidad y atienda a los jefes quejosos. El equipo organiza sus propias actividades y lo importante es que cada uno encuentre cuál es su magia y cómo ésta le da valor al equipo.

Aunque suena muy bonito, lo más probable es que pasarán varios pleitos y regadas para que lo logren. En lo que esperamos los madrazos, todas las mañanas, me dedico media hora a evangelizarlos en varios temas de Agile. 

Por experiencias evangelizadoras previas, sé que cuando el jefe se para al frente, pone voz grave y cara seria al decir “ahora vamos a trabajar así”, la primera reacción de la gente es torcer los ojos y pensar “pos ya qué, a ver con qué nueva “superidea” nos sale”. Por eso, sólo es media hora, contra reloj. Si la riego, no perdimos más que media hora de nuestras vidas. Y sí: yo también la puedo regar.

Una de las estrategias para que esa media hora sea al menos entretenida, es jugar. El tema era seguimiento del desarrollo con gráficas burn-down y burn-up. En la sesión anterior, les expliqué la teoría y les mande unas ligas para leer. El equipo dijo que había entendido y se fueron a comprar tacos. Por la tarde, me puse a buscar un juego para poner en práctica las grafiquitas. Pasaron una hora, dos horas, tres horas. No existía en internet un juego para hacer gráficas de burn-down-up. Ni en tasty cup cakes o el grupo de agile games de google. Llegó la hora de ir a casa y no tenía la dinámica para el día siguiente.

Entonces San Google salió a mi rescate. En uno de esos algoritmos macabros, me salió un tablero de serpientes y escaleras. Y en 15 minutos inventé mi juego.

Comenzamos el juego usando dados de Android. Al principio, nos hicimos bolas, no me supe explicar bien. Conforme pasaron los turnos, comenzó la carrilla, las risas y por supuesto, los puntitos en las gráficas. A veces, la emoción por jugar hacía que lanzaran los dados sin ver cómo el otro dibujaba su gráfica. Yo los detenía y entre todos discutían cómo deberían poner el punto “quemado”.

Al final de la sesión, revisamos cada una de las gráficas y les hice preguntas para reflexionar sobre la elaboración, uso y diferencias de cada una de las gráficas. Aún tengo que ajustar algunas reglas del juego, pero en general, creo estuvo muy bien.

Haz clic aquí para descargar el juego.

domingo, 30 de septiembre de 2012

¿Por qué este blog?

Tengo nueve años bloggeando y casi nunca escribo de mi trabajo. ¿Por qué? Pensaba que esas letras no aportaban nada interesante o entretenido a la Blogósfera. Había mucha gente que ya lo hacía mucho mejor que yo.  Además, pasaba ocho horas al día sentada frente a una computadora; escribir durante dos horas de lo que hacía en esas ocho me iba a volver loca. Cuando escribía sobre mi trabajo, era sólo un recuento de los daños (o ganancias).
 
Eso cambió hace dos años cuando volví a trabajar en Desarrollo de Software.  Aunque no escribí un Blog, sí me volví un poco loca.  Obsesionada.  Soñadora. La historia es un poco larga y en este momento no viene mucho al caso.  La cuestión es que ahora leo, vivo y sueño con desarrollo ágil y couching.

Mi recibo de nómina dice “Gerente de Soluciones”. Esto quiere decir que soy la responsable productos base de la empresa. Sin embargo, pienso que la palabra “Gerente” es una definición bastante chafa porque soy Scrum Master y tengo a Crispin - Hendrickson, Cohn y Cyment como guía laboral.  Me apasiona el Couching y aún quiero ser Agile Tester.

Hace unas semanas mi vida laboral tuvo un terremoto: perdí gente valiosa.  Justo cuando me sentía más orgullosa de lo que juntos habíamos logrado... ¿Y todo para qué?.  Cuando me quité de encima las emociones vicerales,  me dí cuenta que me faltó mucho por hacer.  Dejé lo importante por los urgente y tuve miedo.

Hoy algunos ya no están, pero otros nos quedamos.  Así que decidí abrir este blog. Para recordarme que tengo que volver a intentarlo.  Todos los días, por mí y por los que me han acompañado en este camino.

martes, 18 de septiembre de 2012

Los individuos


Hace tiempo que quería escribir este blog.  Supongo que en este primer post debía presentarlo; hablar de porque no lo había comenzado antes; decir quién soy, que hago y por qué se llama integración contínua y tamales.

Debería decir muchas cosas, pero no las diré.  Hoy es un día triste.  Quizá el más triste de mi vida laboral.  Es uno de esos días en que me cuesta más concentrarme y ordenar las ideas.  Es de esos días en los que me siento vencida y con las manos atadas.

Y todo por los individuos.  El manifiesto ágil debería tener esta advertencia sobre los individuos: no será sencillo; no todos piensan como tú y puedes no tener tiempo de convencerlos.

Hoy no hubo integración contínua. Y con la tristeza, se me quita el hambre de tamales.