martes, 18 de noviembre de 2014

Controlitis Anónima

Hola,
Soy Rox y me estoy recuperando de Controlitis
Todos: Hooooola Roooox

A veces pienso que tengo un Rol con doble personalidad: por un lado, soy el Coach que invoca cambios, que logra unificar el área de pruebas con desarrollo y cambia la cultura de “hagámoslo como caiga” a “hagámoslo con calidad”.  Pero también son Manager; tengo llevar seguimiento de los proyectos, revisar requerimientos, quitar obstáculos, negociar con otras áreas.  Y sobre todo, es a mí, una de las dos a quienes les exigen los resultados de todo el equipo.

Como buenos agilistas, tenemos el seguimiento del proyecto en un burndown, un tablero de kanban y hasta un niko-niko calendar para saber cómo nos sentimos semana a semana.

Pero eso significa que  esté 100% recuperada del Command y Control, Controlitis en español.  Hace algunos sprints, los mánager (somos 2) definimos algunas cosas que es más natural que haga el equipo, como la duración y distribución del sprint. Además teníamos un equipo grande trabajando en los mismo: 10 personas. Desde la semana 5 o 6 nos dimos cuenta que había problemas con esta forma impuesta de trabajo: revisaba capturas de horas y  poníamos reglas para lograr que hubiera “compromiso”. En resumen: ejercíamos presión. Cada día que abría el burndown y veía cómo nos retrasábamos, moría un poco.

Durante esas semanas, no podía dormir bien y me dolía la espalda. Era infeliz y me sentía todo el tiempo preocupada. Pero tuvieron que pasar otras 5 semanas más para que explotáramos y nos diéramos cuenta que el mayor problema era pasarles la presión que ejercían hacia nosotros.

Entonces nos hicimos a un lado y les dijimos: son dos equipos y queremos esto. ¿Para cuándo lo tienen? Ya saben los lineamientos de calidad que queremos. Los equipos re-estimaron y organizaron sus tableros y se repartieron las tareas.  ¿El resultado? Tenemos Burndowns más saludables e incluso, uno de ellas por debajo de la línea de control. Pero lo mejor es que los equipos se ven más integrados y los chavos tienen menos problemas.

Y por supuesto, ya no me duele la espalda.

No quiero decir que las cosas son perfectas, ni que nos falten cosas por aprender. Lo único que ha pasado es que resolvemos los problemas de una manera más efectiva y nos sentimos mejor.



jueves, 27 de febrero de 2014

De cuando dejamos de programar y nos fuimos a un balneario

Eran casi las 6 de la tarde y el altavoz del balneario nos invitaba a ir alzando nuestros triques. Sin embargo, elegimos echar al asador la segunda ronda de tacos de carne asada. Era jueves, de un día laborable y desde la 1 pm todo el equipo de desarrollo (12 programadores y yo) teníamos permiso de convivir (y conbeber) en un balneario. Por eso cuando L, un programador que tiene 3 o 4 meses en la empresa me preguntó ¿Oye Rox, y cada cuánto hacen esto?, sonreí. Nunca, es la primera vez, contesté.

La idea fue mía. El equipo tenía alrededor de 2 mil pesos ahorrados, producto de cobrar llegadas tardes a la junta diaria. Casi siempre, ese dinero se destinaba en tragaderas inhumanas de carne de pollo, res y puerco, con sus respectivas cervezas en un restaurant brasileño. Pensé que podíamos hacerlo mejor. Darle más valor a nuestro dinero. Por eso, pedí permiso a nuestro subdirector y me aguanté la tentación de organizar dinámicas de integración y de organizar yo todo.

Más que pasar un rato divertido, lo que quería es que hubiera convivencia fuera de un ambiente laboral porque creo que importante que nos conozcamos como personas, más allá de las habilidades ingenieriles. Por supuesto, hay grupos de compas que de pronto se juntan a "echar chela", pero las responsabilidades personales siempre impiden la asistencia de todos. Así que tenía que ser en horario laboral.  La única condición fue no dejar temas laborales abiertos y la asistencia de todos.

Yo no propuse la idea del balneario; sólo les dije que teníamos 4 horas (más 2 de comida) para hacer lo que queramos. En una junta se decidió el balneario y nos asignamos responsabilidades de compras de insumos para carne asada, cerveza y transporte. Me dí cuenta que no consideramos los utensilios para asar la carne: pinzas o cuchillos, pero no dije nada, quería ver cómo lo resolvían. Al final fue L quien llevó una tablita, un tenedor y un cuchillo.

Apenas llegamos al balneario tuvimos un problema: no nos permitían entrar con los 3 cartones que habíamos comprado. Si bien en el balneario permiten consumir alcohol, esperan que los compremos ahí. Nos arreglamos dejando un cartón en consigna y la promesa de no salir a comprar más. Apenas instalados destapamos las cervezas y un grupo comenzó a encender el fuego y otro directo a la alberca. El siguiente inconveniente, que ahora es un chiste local, fue la pérdida de $50 pesos en cebollitas. 

Después de comer-tragar nos fuimos a la alberca. Bajo la presión de "si no te avientas te aventamos", todos terminamos dentro. Se organizaron carreras y juegos con la pelota entre carrilla y el doble sentido que distinguen a nuestra área. Algunos corrieron para los toboganes y a los minutos les seguimos todos. Yo no quería salirme de la alberca porque cuando me da frío comienzo a estornudar. Aún así estornudé y me aventé algunas veces. Algunos se aventaban de los toboganes gritando fuertísimo y los que estábamos abajo nos reíamos de su bajada. Corrían, se aventaban entre ellos y echaban desmadre. Incluso hubo un par de señores que se unieron a nuestro ambiente. Era tal el relajo que uno me decía "¿Ya ves como andan? Sácanos más seguido Rox". De ahí nos fuimos a la fosa de clavados a medio llenar y después, a volver a comer y a chelear.

De las cosas que me ponen más contenta de esa tarde es que siempre estuvimos todos juntos. No hubo "bolitas" que se apartaran o solitarios que se pusieran a leer. Todos nos olvidamos de los teléfonos y no extrañamos ese cartón consignado. Entre todos se animaban para ir a los toboganes o a las albercas y se ponían de acuerdo para cocinar. 

Sería muy presuntuoso (y mentiroso) de mi parte decir que esa tarde fue un parteaguas en nuestra integración como equipo; eso es un proceso y tiene altas y bajas. Sin embargo, es bueno disfrutar los buenos momentos de la vida, incluso con los compañeros de trabajo.

jueves, 30 de enero de 2014

Crónica de una caída anunciada

Las últimas semanas del 2013 transcurrieron sin contratiempos. Algunos tomamos vacaciones y la oficina estaba muy tranquila. A veces, hasta aburrida. Hasta que partimos la rosca de reyes el equipo volvió a estar completo. Aun no sabíamos bien por dónde arrancar, cuando nos enteramos que ante la ola de facturación electrónica impuesta por el SAT, uno de nuestros productos requería algunos ajustes para soportar el volumen. Nuestras estimaciones de ese incremento se habían quedado muy cortas: había que reaccionar YA. Para esto, hasta el subdirector del área entró a diseñar la nueva arquitectura y hacer las pruebas de conceptos. Los gerentes y dos programadores al desarrollo y yo a probar. Fueron tres intensos días de horas extra y para el cuarto, un flamante cambio de arquitectura estaba listo.

A finales de año, hicimos un reacomodo de lugares, de tal manera que ahora todo el equipo está sentado en un rectángulo y al centro, una mesa para juntarnos a revisar distintos asuntos. Si bien el nuevo acomodo facilita la colaboración, nos hizo quedarnos sin tablero. Entre la vorágine del cambio de arquitectura, los demás equipos no se preocuparon por recuperar ese tablero, aunque sea en alguna herramienta. Otra práctica que se perdió fue el hacer las revisiones de código. Y como algunas tareas eran cortas, hubo gente trabajando sola. 

Escribir esto me pone un poco triste. Pensaba que esas prácticas ya habían comprobado su efectividad y habían sido apropiadas por el equipo. Pero dejaron de hacerse y nadie (ni siquiera yo) dijo "oigan, algo huele mal".

Al final, tuvimos que dar marcha atrás al cambio de arquitectura y volver a empezar. Aunque en este revés no estuvieron involucrados directamente todos, quisimos comprartirlo con el equipo completo. La derrota duele y la nalgada contra el piso nos hizo despertar. Reflexionar. 

Poco a poco, las revisiones se han retomado, armamos equipos de mínimo dos personas y tenemos un tablero en el escritorio un poco diferente.


miércoles, 4 de diciembre de 2013

20 días para navidad

La historia se repite todos los años. La navidad que no se mueve del 24 y el SAT que saca reformas fiscales en diciembre para iniciar con el año. Dichas reformas significan trabajo, lo cual es bueno. Sin embargo, la presión por lidiar con las constantes de tiempo y complejidad del requerimiento se vuelve más crítica esta temporada. Las leyes y el time-to-market nos imponen un dead-line crítico. No cumplirlo significa quedarle mal a nuestros clientes y estar fuera del negocio. Y como buena empresa queretana, el 70% de las personas venimos de otra parte del país y queremos ver a nuestra familia en las fiestas. El objetivo es comenzar el año con los cambios de ley en productivos.

¿Cómo manejar la presión sin que esto signifique quedarle mal a nuestros clientes o a nuestra familia? Sin duda necesitamos mucha creatividad y concentración. Trabajo en equipo y habilidades técnicas. Esta es la historia de cada uno de esos días.

miércoles, 4 de diciembre.

Con el requerimiento un 80% definido y las tareas pegadas en el taskboard comenzamos el desarrollo de 3 de nuestros productos. Las tareas de más riesgo tienen un separador de hojas y decidimos reorganizar otra vez el desarrollo: comenzamos por el corazón del producto y sin aún decidir cómo lo alimentaremos. Para ayudar a decidir la forma de alimentación, nuestro gerente entra a programar. Si para el lunes medio-termina un front end, seguimos por ahí. Aún falta decidir cómo haremos el swich de año-funcionalidad y coordinarnos con otras áreas para encender el auto y garantizar que arranque a la primera.

jueves, 5 de diciembre

Un integrante del equipo encuentra que hay incongruencias en la definición del requerimiento, justo en el corazón del mismo. Se toma una decisión al respecto aunque el cliente no haya contestado. Esto debido a que necesitamos comenzar a probar la integración con terceros. Se establece la fecha del lunes para entregar los componentes necesarios para integrar.

viernes, 6 de diciembre

Este día sólo se trabaja hasta las 2:00 ya que por la tarde es la fiesta de fin de año que casi siempre termina en after hasta el día siguiente. Nuestros compañeros del DF llegan a medio día y los pasillos se vuelven un jolgorio. 

Sábado, 7 de diciembre y domingo, 8 de diciembre

No se trabaja y no se trabajó.

Lunes, 9 de diciembre

Los taskboards se empezaron a llenar de postits en la columna DONE. Uno de los equipos había prometido tener el corazón del desarrollo listo para pruebas de integración con terceros a las 2PM. El mail con los cambios a los ambientes de pruebas se mandaron a la 1:30. Los malabares por tener un requierimiento medio definido, un sistema pre-liberado y 3 productos relacionados comienzan.

Martes, 10 de diciembre

Nuestro gerente hizo un gran avance en el front-end y decidimos tomar esta alternativa con el objetivo de lograr el time to market. El equipo se siente un poco frustrado por el cambio de importación a front end. La realidad es que somos más hábiles en backend y la presión aumenta. Se comienza un prototipo de los reportes. Se integran 2 compañeros más a uno de los equipos. 

Miércoles, 11 de diciembre

Se planea la integración front-end / back-end para el viernes, para uno de los componentes. Los Product Owners no están muy felices con el front-end y nos informan que quieren revisarlo y ver cuánto más nos tardamos añadiendo algunos cambios.

Jueves, 12 de diciembre

Llegan nuevos cambios de ley que aclaran el requerimiento y lo hacen más complicado. Rediseñamos una vez más el prototipo -en papel-, buscando que el front-end sea más usable. Al final del día vemos humo blanco.

Viernes, 13 de diciembre

Al presentar el prototipo al equipo de desarrollo nos proponen una manera diferente de hacerlo. Así también se ve la viabilidad de persistir más información de la requerida para posteriores requerimientos. No se logra la integración front/back-end, pero se acepta el cambio presentado por el equipo.

Sábado 14 y domingo 15

No se trabaja y no se trabajó.

Lunes 16 de diciembre

Uno de los dos equipos se organiza y vuelven a planear en el taskboard. Dan como fecha de finalización el viernes 20. Me siento orgullosa que lo hayan hecho por iniciativa propia. Me doy cuenta que las tareas no están dadas de alta en el sistema de seguimiento, sin embargo, ese equipo está motivado y organizado. Decido no intervenir con absurdo micromanagement. El otro equipo decide que la aplazada integración será mañana y se vuelven a asignar tareas de acuerdo al nuevo prototipo. 

Martes, 17 de diciembre

El Gerente de Producto manda la primera versión de pruebas para integración con terceros de uno de los productos. Se sigue adelante con el nuevo prototipo y se pone de fecha límite el viernes 20 para el lunes comenzar las pruebas de regresión.

Jueves, 19 de diciembre

Tenemos juntas diarias por la tarde para revisar cómo vamos. La siguiente semana comienzan a irse de vacaciones y hay que asegurarse que no queden desarrollos a la mitad o que se tome mucho tiempo retomar. Comienzo a enfermarme de ese virus que contagió a toda la oficina.

Viernes, 20 de diciembre

Hoy toca horario corrido y mudanza. Acondiciono 2 salas de juntas para irnos a trabajar después de las 3 de la tarde. La presión se incrementa para uno de los equipos ya se está a punto de terminar el front-end en base al nuevo prototipo, sin embargo no se ha probado todo junto. Para las 6 de la tarde se logra la funcionalidad base.

Sábado 21 y domingo 22

No se trabaja y no se trabajó.

Lunes 23 de diciembre

Sin 3 de nuestros compañeros, continúa el desarrollo. Al final del día una versión prácticamente completa se vuelve a mandar para pruebas de integración con terceros. Comienzo con las pruebas y reporto los bugs por email. Decidimos no comenzar a resolverlos hasta terminar las tareas, lo cual ocurrirá probablemente mañana. Sólo 2 bugs fueron críticos y se resolvieron para continuar con la regresión.

Martes, 24 de diciembre

Las pruebas continúan y encuentro algunos otros bugs que mando por email. Redacto un mail del status al gerente ya que estos dos días estuvo de vacaciones y regresa el jueves. Yo tomé jueves y viernes de vacaciones. Sólo trabajamos medio día.

Miércoles, 25 de diciembre

Día festivo, nadie trabajó

Jueves 26 y viernes 27 de diciembre

Yo estuve de vacaciones, pero el lunes me enteré que todos los pendientes se terminaron (incluso algunos requerimientos de otras áreas) y estábamos listos para entregar el lunes 30.

Sábado 28 y domingo 29

No se trabaja y no se trabajó.

Lunes 30 de diciembre

Hago algunas pruebas con las resoluciones de monitor más usadas por nuestros clientes y se hace el demo con Product Owners y Stakeholders. Nos felicitan por el desarrollo y se plantean otras mejoras. Algunos detalles de la demo se atenderán durante la tarde. Nos comprometemos a entregarlo mañana para pruebas en preproducción. Creo que éste fue la primera ocasión que trabajamos más allá de la hora de salida, hasta las 9pm.

Martes 31 de diciembre

Se hacen las entregas finales y hacemos smoke test en preproducción. Ya es decisión de otras áreas el paso a productivo.

Conclusión

Estoy planeando para el lunes la retrospectiva, cuando todos los vacacionistas se reintegren al equipo. Son ellos más que yo, quienes tendrán una evaluación más certera de todos estos días. Por lo pronto, lo que se ve huele bien: clientes satisfechos, entrega a tiempo y pocas horas extra sin sacrificio de vacaciones. Sin duda, estoy orgullosa de los avances que hemos hecho en cuanto a la adaptación al cambio.

We rock!

miércoles, 24 de abril de 2013

Hace un par de años el departamento de desarrollo en el que trabajo tenía una fuerte estructura vertical. Aunque el ambiente era relajado, era muy claro que el líder del producto era responsable del buen funcionamiento, productividad y problemas del equipo. Los límites gerente - líder - programador estaban bien delimitadas por lo que decisiones y culpas caían directamente en los primeros dos. Hace un año, los líderes decidieron partir. Reorganizamos el área y como gerente quedé a cargo de dos equipos que atienden cinco productos. Tan sólo un equipo de seis programadores (de los que ahora son cinco) atienden cuatro productos. Hoy hablaré de este equipo al que llamaré TEI.

Los cuatro productos de TEI podrían considerarse primos hermanos. Manejan algunos conceptos comunes y están relacionados entre ellos. Sin embargo las entrañas y el objetivo de negocio son diferentes. Y lo más importante: todos eran expertos en sólo uno de esos cuatro productos. Hace un año, cuando decidimos juntarlos y dejarlos sin líder les dije: ahora deben ser un equipo auto-organizado. Por supuesto, decirlo está muy lejos a serlo.

La semana pasada tuvimos su retrospectiva. Esta vez, utilicé la técnica de Appreciative Retrospective. En esta técnica sólo se habla de lo que el equipo hizo bien. Un cambio de enfoque muy fuerte cuando lo que comúnmente se hace es buscar solución a nuestros problemas. Elegir una acción más allá de "sigamos así, somos los mejores" es mucho más complicado que buscar una solución a un problema claro.

Pero antes de la acción, hicimos la recopilación de información. Se comentaron éxitos como las juntas diarias, el uso del tablero de Kanban, la asignación de las tareas sin importar la experiencia y los lineamientos de junit. Estas prácticas se fueron madurando en varias retrospectivas y sprints. Entonces les pregunté: ¿A qué se debe ese éxito? Palabras como comunicación, respeto, confianza, libertad y compromiso quedaron escritas con rojo en el pintarrón. 


Entonces me cayó el veinte. Los valores más que explicarlos, se viven. El equipo de TEI no sólo es auto-organizado, sus integrantes se han transformado como personas a través de esos valores.

Como Scrum Master lo que hice fue darles espacio, respetar sus decisiones y moderar sus discusiones (¡son bien buenos para discutir!). He leído mucho sobre cómo el dejar de protejer, de vigilar y de mandar los hace crecer. Ahora sé que es cierto. No sólo ellos se han fortalecido, los resultados hacia la empresa también son consistentemente buenos.

La última parte de la retrospectiva, en la que se decide qué acción seguir les pregunté: De todo esto que hacemos bien, ¿qué queremos crecer? ellos eligieron la parte de innovación en tecnologías y procesos. Incorporar conocimientos nuevos a su trabajo diario. Sin embargo, el cómo hacerlo nos metió en un bache. Se mencionó autoestudio, cursos, clases organizadas entre todos. Soluciones comunes que no convencían a nadie. Y es que ellos ya han programado el tiempo suficiente para saber que sólo se aprende ensuciándose las manos. La cosa es, ¿cómo te ensucias sin meter riesgo al sprint? Les expliqué que es un Hackathon. Nadie había oído de ello y ahora lo estamos planeando.

Ese día volví a mi casa como una gallina feliz hinchada de orgullo. Hace un año, los mismos integrantes que temían por su falta de conocimiento de otros productos ahora saben cómo enfrentarlo. En las retrospectivas ya no se "culpa" a la estimación o a terceros, ahora se plantean lineamientos comunes para junits y Definitons of Done (DoD) más robustas.

Volviendo a leer a Lyssa Adkins me doy cuenta que el valor de Enfocarse (Focus) es el que menos se ha logrado y que es mi responsabilidad proveerlo. Aún nos queda camino por andar. Pero los frutos ya los estamos recogiendo.

miércoles, 17 de abril de 2013

Perdiendo el equilibrio

Últimamente me he sentido un cansancio mayor al acostumbrado. De lunes a viernes caigo rendida y me quedo dormida leyendo o viendo TV. Duermo mal y a veces me despierto por la noche. Los fines de semana puedo dormir hasta 4 horas seguidas durante el día. Además, me cuesta trabajo poner atención y concentrarme en otras actividades fuera del trabajo como leer, escribir y hasta conversar. Lo que más me molesta de todo esto es que el 85% de mis sueños son sobre problemas en el trabajo.

Sobresaturada, hiperexpuesta fueron palabras que escuché de mi doctor / couch de estilo de vida. El overflow laboral me impide estar bien y rendir como se debe no sólo en el trabajo, sino también en mi vida.

Culpar al trabajo, renunciar o bajarle a mis responsabilidades no son una opción. Son una salida fácil que no resuelve el problema de fondo.

Entiendo que lo que debo hacer es encontrar un equilibrio que me permita ser creativa y disfrutar todos esos momentos. Necesito más rutina y menos autocompasión. Necesito relajarme y plantear mi visión, entender mis habilidades y sobre todo, relajarme para poder enfrentar los retos que se vienen.

Hoy tuve un sueño extraño. Como todos los sueños, no lo recuerdo bien pero iba más o menos así: estaba en la recepción de un gran hotel. La recepción era de mármol y estaba llena de helechos y floreros con rosas. Al fondo, se veía un jardín con muchos árboles y flores. Yo esperaba impaciente a que la gente de la recepción arreglara sus problemas con las reservaciones. Cuando me tocó mi turno en recepción, resultó que uno de nuestros desarrollos podía resolverles el problema. Me acuerdo perfecto que dije el nombre de la solución. Lo curioso una vez que me desperté, fue que la solución que resolvía el problema del hotel no era el que yo mencioné, sino la que a mí me trae con overflow.

miércoles, 3 de abril de 2013

Palmaditas en la espalda 1: Agile Mindset, Cultura y Familia autoorganizada

A veces las cosas no salen como espero. Otras veces, encuentro más dificultades de las que esperaba. Entonces necesito unas palmaditas en la espalda, un rayito de luz y sobre todo, ideas para volverlo a intentar. En esta sección compartiré cosas que he encontrado en internet y que me han ayudado. 

Linda Rising y el Agile mindset 

Linda es una señora que ha trabajado la mayor parte de sus setenta años en el "tech world". Ella misma admite que cae en estereotipos negativos; sabe que la gente puede pensar: ¿Y ella que va a saber, si es anciana? ¡Y además mujer! y encima, seguro white trash. Quizá por el mismo estereotipo es que sus palabras sobre el pensamiento ágil (agile mindset) me reconfortaron. Podemos estereotipar, equivocarnos, admitir nuestras limitaciones. Pero siempre podemos aprender, adaptarnos y crecer. Eso, es ser ágil. Aunque en la charla casi no habla de su libro "Fearless change patterns", 20 minutos después estaba comprando en Amazon. El libro habla de patrones que se pueden seguir cuando se quiere introducir el cambio, cómo la gente reacciona ante él y cómo debemos actuar ante ciertas situaciones. Aunque está enfocado a la empresa, el cambio aplica para todos los ámbitos de la vida. Aquí la charla para Infoq 

¿Alguien lo logra alguna vez? 

El primer día de mi maestría (en Ingeniería de software), además de hacer el ritual de Miss Mundo en el que dices tu nombre, nacionalidad y experiencia ingenieril, nos preguntaron porqué estábamos ahí. Colombianos, españoles, peruanos, venezolanos y mexicanos dijimos más o menos lo mismo: queremos hacer software de calidad y sin que nos duela. No importaba dónde habíamos estudiado o trabajado. Nuestra personalidad o tamaño de la empresa. Todos habíamos sufrido por la baja calidad de nuestros productos, horas extra y hasta demandas. Entonces, cada vez que aparece una empresa como Velve o HubSpot pienso... ¿Por qué no?

 


Agile programming para tu familia 

Durante nuestro curso de Scrum Master, Alan nos comentó que recién había instruido al SCM más joven. Un violinista de 16 años. La esencia de Agile (autoorganización, confianza y empowerment, capacidad de adaptación) sumada a algunas buenas prácticas (Big Visible Charts, DoD, Checklists) funcionan perfecto en otros ambientes, como la familia. Este tipo de cosas son las que me hacen sonreir :)

 

miércoles, 6 de marzo de 2013

Agile y la vida "real"


Mi esposo es escritor y recientemente estuvo escribiendo cuentos para un concurso. La fecha de entrega estaba a un par de días y aún le faltaban 3 cuartillas para llegar al mínimo establecido en las bases. Las hago en una tarde, me decía y seguía revisando obsesivamente las cuartillas ya terminadas. Entonces le dije: 


-¿De dónde sacaste eso?, me dijo. 
-Agile –contesté. 
-Me lo imaginaba.

No es la primera vez que hablo en Agile para cosas comunes y corrientes. En otra ocasión, mientras veía un reality de un chef que ayuda a diferentes restaurantes que son un caos, descubrí que su método para cubrir los pedidos de las mesas incluía un WIP=1 (Work In Progress). Cubrir platillo a platillo y mesa a mesa con los comensales, era más eficiente que cocinar muchas cosas al mismo tiempo. Mi corazón brincó de alegría. 

Esto lo escribo porque leí a Adam Weisbart siendo mejor scrum master, digo novio. Un salón de clase de primaria autoorganizado y un Kanban para que los niños hagan lo que les toca. Agile transforma tu vida, les digo.

Por cierto, mi marido entregó a tiempo y completo lo que se necesitaba. Buena scrum master, buena. *palmaditas en la espalda*

viernes, 11 de enero de 2013

Scrum Master, muppets & rugby

De los aspectos que más me gustan de Scrum es la creatividad y la mezcla de disciplinas.  Si te gusta el teatro, cine o la escritura, lo puedes utilizar.  

Además, el espíritu de comunidad y compartir hace que no sea necesario estar en Europa o EU para disfrutarlo e inspirarse.  Por eso, ahora tengo dos objetivos más en mi vida:

1. Hacer "high five" con Kenneth:

 

 2. Subir de peso para utilizar estas técnicas de Scrum Master

 

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.