"Visual Management" Misional

Hace diez años atrás, entre los años 2001 y 2003, me encontraba en la ciudad de Buenos Aires, Argentina, como misionero de La Iglesia de Jesucristo de los Santos de los Últimos Días, predicando nuestras creencias a la gente de dicha ciudad, muy aparte de las grandiosas experiencias que tuve durante los dos años que duró mi actividad misional, hubieron algunas cosas que durante ese tiempo realicé y con el tiempo las volví a encontrar dentro del mundo Agile.

La que deseo comentar en esta ocasión es nuestro "Tablero de seguimiento" (no tenía un nombre en particular, asi que lo denominaré así). Es similar a nuestro taskboard o panel de tarea que usamos en los proyectos, solo que en lugar de "tareas" hablamos de "personas". Un poco de visual management. A continuación, les haré mención de la información que colocábamos en dicho tablero.

Nombre del Área: de la misma forma que en un panel de tareas en el que colocas el nombre del proyecto en curso, en nuestro caso colocábamos el nombre del área que estaba bajo nuestra responsabilidad.

Lista de reglas/normas del equipo: en esta lista se encontraban las instrucciones sobre el manejo del tablero y demás información como la hora en la que hacíamos las reuniones diarias de planeamiento, alguien mencionó daily meeting? Sí, teníamos reuniones diarias todas las noches a las 9:45pm (al volver al deparamento).

Para el flujo de la búsqueda de nuevos conversos, contábamos con varios cuadrantes o secciones en nuestro tablero y que listaré a continuación:

1. Encontrar: Durante el tiempo en el área podíamos encontrar personas de dos maneras que eran claramente diferenciadas en el tablero. Una de ellas era la denominada "Iniciativa Propia" o como solíamos decirle meramente "IP" (nada que ver con internet protocol). El "IP" podía incluir cualquier esfuerzo del equipo para contactar personas interesadas en escuchar acerca de nuestro mensaje, esto podía ser mediante "toque de puertas", conversaciones en la calle, entrega de folletos, actividades de servicio, etc. La otra forma era a través de los mismos miembros de la iglesia quienes podían presentarnos a un amigo o conocido de ellos.

Los nombres de las personas encontradas por IP se colocaban en un post-it y se ubicaban en la parte superior de esta zona, mientras que aquellas que provenían de referencia de miembros de la iglesia se ubicaban en la parte inferior.

2. Enseñar: El siguiente paso luego de encontrar a la gente es tratar de enseñarles el mensaje que teníamos, podían suceder dos cosas: una es que no lográramos contactar con la persona, la otra es que lográramos contactar a la persona y le enseñáramos alguno de los mensajes que teníamos preparados. Cuando pasaba esto pasábamos el post-it al cuadrante de "Enseñar" y poníamos una marca por cada lección que le enseñábamos.

3. Bautizar: Por fin! Encontramos a una persona buenísima, aceptó recibirnos, le enseñamos las lecciones y ahora quiere bautizarse! Es lo máximo para un misionero! Bueno, cuando esto sucede pasamos el post-it de la persona al cuadrante "Bautizar" y anotamos la fecha de bautismo en él, habitualmente con un color que se diferencie, tal como lo muestro a continuación:

4. Conversos nuevos: Y llegamos a la meta! La persona se bautizó, cuando eso pasa, movemos el post-it a este cuadrante. Si me preguntan, ¿qué pasa con las personas que llegan hasta acá?, pues les comentaré que pasan a ser visitados por los miembros y el seguimiento a su progreso pasa a ser responsabilidad de la unidad local. En un taskboard tradicional este cuadrante sería el equivalente a Done o Listo.

Nuestro "Tablero de seguimiento" contaba con dos cuadrantes más...

5. Gigantes dormidos: acá se colocan los nombres de aquellas personas que estuvieron en el cuadrante "Enseñar" y que por alguna razón dejaron de recibirnos. Estos nombres luego los registrábamos para que en un tiempo futuro otros misioneros pudieran visitarlos.

6. Reactivación: acá se anotaban los nombres de aquellos miembros menos activos, que necesitan ayuda y a los que nos hemos comprometido visitar.

Pues bueno, he aquí un poco del visual management que empleaba en la misión, ¿qué les parece? Si tienen algún comentario o consulta no duden en hacérmela llegar.

Be Agile! / Se Ágil (una reflexión)

 

Hoy quise escribir un poco respecto a la onda Ágil o Agile, que se anda escuchando mucho últimamente y de lo que significa para mi. Durante el tiempo que llevo como desarrollador he tenido la oportunidad de participar en cierto número de proyectos con diferentes resultados. Si me pidieran realizar una lista de observaciones a todos estos, tal vez la lista sería como la que sigue:

• Proyectarse a realizar un proyecto de larga duración con fases secuenciales muy marcadas (Análisis, Desarrollo, Pruebas y Despliegue) no siempre es un buen ídea, es más por lo general no lo es porque bajo ciertas circunstancias el coste de los cambios (que siempre suelen ocurrir) es elevado.
• El verdadero valor de un proyecto como el mencionado en el punto anterior no se conoce sino hasta el final, lo cual puede ser muy costoso y frustrante cuando el cliente se da cuenta que las cosas han cambiado y aquello que se hizo ya no tiene razón de ser.
• En muchas ocasiones se quiere dar solución a situaciones utópicas en lugar de atacar los puntos críticos del proyecto.
• En ocasiones quien realizaba la estimación o bien no tenía idea de lo que se tenía que hacer o bien no tenía los suficientes skills técnicos para comprender cabalmente lo que involucra el desarrollo de una solución.
• En muchas ocasiones tener a alguien detrás preguntando a cada rato "¿Cómo vamos?" es incómodo y tendía a hacernos perder la concentración en lo que veníamos realizando y no está de más, nos aumentaba la presión y la tensión.
• No suele tenerse en claro el concepto de mejora continua, tras los errores de un proyecto, por lo general, se olvidan y se vuelven a repetir en el siguiente.
• Los desarrolladores y más los jefes de proyecto, deberían tener en claro que es OBLIGATORIO escribir pruebas unitarias o en general todo desarrollo debería estar en la capacidad de testearse de forma constante.

Y podría seguir alargando más la lista pero ese no es el objetivo de este post. En fin, hace ya 3 años, tuve mi primer acercamiento al mundo ágil, a través de Scrum, en un proyecto para una reconocida compañía de seguros; nunca olvidaré la sensación que tuve al experimentar lo que significa estar en un "equipo auto-organizado", contar con una relación de "colaboración" más estrecha con el cliente, encontrar oportunidades de mejora durante las "retrospectivas" e incluso, la organización del tiempo del proyecto en tramos cortos que se conocen como "sprints". Podría decir que nunca antes me había sentido tan productivo, nunca antes había disfrutado tanto con realizar mi trabajo de una forma distinta.

Al principio, aprendí sobre Scrum, sobre XP, sobre Kanban, y otros frameworks ágiles. Supuse que aprendiendolos conseguiría ser feliz en mi trabajo, pero la realidad a veces no suele ser la ideal; aquí entra una frase que oí en repetidas ocasiones a Alan Cyment: "pragmatismo a corto plazo, idealismo a largo plazo"; no se trata de aplicar violentamente todo un framework, en ocasiones uno se debe "adaptar" y generar el cambio de a pocos. Hubieron ocasiones en las que el entorno era tan hostil, que suponía un alejamiento de las prácticas ágiles, bueno, cuando sucedió esto no perdía la esperanza y siempre buscaba oportunidades para enseñar lo que había aprendido hasta el momento.

Pero "ser ágil", por lo que entiendo ahora, no es solo una manera de trabajar o de hacer diferente el trabajo, sino que va más allá... es un cambio en el pensar y en la forma en la que realizas las cosas en tu diario vivir. Recuerdo una ocasión en la que hablando con uno de mis "mentores", le contaba sobre algunos problemas que había tenido con un par de personas; lamentablemente, con la primera las cosas terminaron mal; sin embargo, para la segunda, cuya riña aun no llegaba a un desenlace, mi mentor me dijo: "Armando, tu eres un chico ágil, aplica la agilidad!". Salí de aquella sesión con la plena intención de mejorar los canales de comunicación mediante una conversación "cara a cara", estableciendo "un objetivo" y "una visión", antes de analizar los problemas... el resultado fue, por creces, muy satisfactorio. Y así podría mencionar algunas otras ocasiones en el que valores y principios ágiles también podrían aplicarse en la vida cotidiana.

Esta es una pequeña reflexión sobre lo que significa el "ser ágil" para mi, sabiendo que el término "ágil" es solo una etiqueta para muchas ideas, conceptos y prácticas; que no son nuevas, pero que están cobrando relevancia últimamente.