Sin slack time no hay espacio para la mejora

Quienes estamos interesados en la mejora continua, entendemos la importancia de disponer de espacios para reflexionar. En esos espacios identificamos cambios y diseñamos experimentos pero, lamentablemente, no siempre somos capaces de aprender de nuestras experiencias. Muchas veces, resulta necesario también disponer de tiempo para dejar fluir las decisiones ya tomadas, las acciones realizadas, y así permitir que los aprendizajes maduren y las nuevas ideas germinen. Un entorno propicio para que esto suceda es el slack time.

Slack time: Tiempo holgado que habilita realizar actividades no pautadas.

slack-time

Existe la idea de que el tiempo que no estamos “cumpliendo con nuestras tareas” no estamos generando valor al negocio, lo que muchas veces nos hace sentir culpables si hacemos explícitos los momentos slack. Como consecuencia del miedo o vergüenza que nos genera hacerlos visibles, los tomamos sin conciencia, dado que voluntariamente o no, no nos es posible ser productivos todo el tiempo. Así, los espacios slack quedan camuflados e inconscientes y resultan menos efectivos de lo que podrían ser si fueran oficiales.

La propuesta es mantener espacios slack validados, acordados y lícitos, y realizar un esfuerzo por limitar que la vorágine del día los devore. Resulta necesario entonces, disponer de una adecuada gestión del tiempo para poder estar ordenados, y así tener herramientas para proteger con conciencia esos espacios.

img_20161122_155401

Son muchos los beneficios de poder tener espacios slack: empezando por la satisfacción de pasar tiempo realizando una actividad que disfrutamos y que podemos compartir con nuestros compañeros (momentos kairos!), lo que da lugar a que personas y equipos de trabajo fluyan mejor en sus tareas. También propicia la confianza, dado que hay espacio para que los temas ocultos -que en otros contextos no tiene espacio para salir- emerjan. Adicionalmente, cambiar el foco de atención propicia el espacio adecuado para que una serendipia ocurra (descubrimiento o un hallazgo afortunado e inesperado que se produce cuando se está buscando otra cosa). Así, la claridad para resolver un problema en curso podría llegar durante una una caminata al sol. En Kleer, actividades como meditar a medio día, tocar el piano o dedicar unos minutos a una siesta reparadora, son algunos ejemplos de nuestros espacios slack.

Existe el riesgo de hacer un uso engañoso del slack time, utilizándolo como medio de procrastinación (postergar algo que estamos negados a hacer). De esta forma, lejos de aliviarnos, podemos quedar enganchados con “eso otro” que todavía no hicimos, y dado que no estamos plenamente presentes en el espacio de slack, no podemos aprovechar la máximo sus beneficios.

Otro ejemplo de organización que promueve el slack time es la empresa FDV Solutions, con instrumentos musicales y diversidad de variaciones de Cubos Rubik dando vueltas por la oficina, festejos de cumpleaños después del almuerzo el último viernes de cada mes, las siestas en los puff y las gloriosas sesiones de masajes de 15 minutos!

foto-438

Encontrar el mejor momento del día para tener nuestro espacio slack puede convertirse en una búsqueda en sí misma. Una opción es planificarlo para el final del día, con la doble función de servir como motivador para avanzar en las tareas y dar cierre relajado a la jornada laboral. Una alternativa es planificar espacios slack al inicio o durante la jornada, a modo de intervalo de descanso para arrancar renovados el siguiente desafío que nos toque abordar. En algunos casos es una buena opción ya tener planificado qué vamos a hacer en nuestro espacio slack. También puede ser una buena idea simplemente escuchar “qué es lo que nuestro cuerpo y la mente necesitan hacer” (tal vez resultado también de la sincronización con nuestro reloj biológico) que puede resultar en salir a dar una vuelta, tocar algún instrumento, coordinar algún juego en equipos o mirar algún video inspirador.

La invitación es a empezar a tener momentos slack hoy mismo, y explorar los momentos del día y contextos en los que mayores beneficios se perciben!

Enlaces relacionados:

Resistir al abandono de prácticas

Registrar esfuerzo en horas, meditar, confeccionar cronogramas, separar los residuos, hacer reuniones de retrospectiva, comer más frutas y verduras, escribir para el blog… todas, todas excelentes prácticas, de las cuales entendemos perfectamente la importancia y el retorno de inversión, pero en general nos resulta imposible mantener…

Somos perfectamente conscientes del instante en el que decidimos implementar una práctica, pero generalmente no tenemos registro alguno del momento que las abandonamos y en la mayoría de los casos, tampoco conocemos las razones. Si bien somos expertos en construir múltiples y diversas explicaciones  ad-hoc que justifican la desatención, en muchos de los casos, se acercan más a ser excusas que razones auténticas.

Creo que el primer paso para la adecuada implementación de una práctica, es ser capaces de resistir al abandono, al menos tomando la decisión responsable de dejar nosotros a la práctica, en lugar de permitir que se vaya sin ofrecer resistencia

Para poder evitar descuidar las prácticas, quizás sea importante primero revisar las razones por las que solemos desatenderlas

  • –      Nos son difíciles, no nos es natural realizarlas, entonces nos olvidamos
  • –      No logramos incluirlas orgánicamente en nuestro día a día, entonces nunca nos podemos hacer el tiempo para implementarlas
  • –      Perdemos de vista la necesidad original que vienen a resolver, entonces las postergamos indefinidamente (procrastinamos)

Algunas posibles estrategias para responder a estos descuidos podrían ser respectivamente

  • –      Evitar ser ambiciosos con la implementación y en los primeros pasos tratar de simplificar al máximo la actividad, para que la dificultad de realizarla no nos genere resistencia.
  • –      “Pegar” la práctica a alguna otra actividad que ya tenemos incorporada (meter yoga antes del almuerzo) o bien establecerla en días y horarios fijos (hacer las reuniones a las 10.30 de la mañana)
  • –      Definir un período específico y acotado de implementación de la práctica (piloto) que nos permita enfocarnos en mantenerla en ese período, medir los resultados, y tomar decisiones en función de éstos.

Y si a estas tácticas, le sumamos el compromiso de la declaración pública, TIENEN que funcionar!!

Foto: Sebastián Parodi

Medir

Medir es una actividad muy-bien-vista por los altos directivos de muchas organizaciones. Ni hablar cuan alentada es si el resultado de la medición es expuesto utilizando un montón de amontonados y diminutos numeritos representados por extravagantes gráficos.

La primera distinción que se me ocurre respecto este punto está asociada a diferenciar datos de información. Wikipedia define a información como un conjunto organizado de datos procesados, que constituyen un mensaje que cambia el estado de conocimiento del sujeto o sistema que recibe dicho mensaje. Personalmente, los datos descriptos en el párrafo anterior no generan en mi ninguna de estas cosas.

Luego, ¿Cual es la estrategia que debiera poner en práctica para que sea posible presentar información en lugar de datos?  Una primera respuesta podría desprenderse de revisar algunas definiciones básicas del universo de las métricas.

  • –      Atributo: Característica mensurable. Por ejemplo el tamaño del sistema o su calidad.
  • –      Medida: Asignación de un valor resultante de una medición a un atributo. Para el atributo tamaño del sistema las posibles medidas podrían ser 5.754 líneas de código, 213 páginas de especificación o 659 horas de desarrollo. Para el atributo calidad de un sistema una posible medida podría ser 27 bugs identificados, 177 casos de prueba ejecutados o 879 horas de testing.
  • –     Métrica: Referencia cuantitativa del modo en que un objeto de medición posee un atributo dado.  Siguiendo con los ejemplos anteriores, la métrica para evaluar la calidad de un sistema podría ser  cantidad de bugs por líneas de código.
  • –    Indicador: Es la interpretación de la métrica. Se construye en función del interés del observador. Por ejemplo, un indicador podría ser nivel de calidad de un sistema que pueda tomar lo los valores: muy buena, buena, media y nula (valores que se definen en en función de la interpretación del resultado de la métrica).

Las métricas e indicadores proveen un alto nivel de visibilidad sobre procesos, proyectos y productos. En particular, si lo que se pretende es exposición de información, el indicador es, sin dudas, la estrella protagónica.

Entonces… usar indicadores resulta una herramienta –muy potente- para presentar información sobre el estado de procesos, proyectos y productos. De ahí a las acciones que se tomen en función de los resultados obtenidos, es un tema muy-mucho-mas-difícil que no faltará oportunidad de discutir en futuros posts.

Ciclo de Deming

También conocido como PDCA (Plan.Do.Check.Act) el ciclo de Deming puede definirse como el circuito canónico para la mejora de procesos. Luego, si lo que se desea es proyectarse hacia el universo en donde mejora continua está a la orden del día, la ejecución sistemática de los cuatro pasos de este ciclo constituye una herramienta poderosa para cumplir ese objetivo.

Los cuatro pasos:

  • Plan: Planificación del proceso. En esta etapa se deben definir los objetivos y la estrategia para cumplirlos. También se confecciona la lista de actividades a realizar y los tiempos asignados para éstas.
  • Do: Llevar a cabo el proceso.  Es muy importante tener visibilidad sobre la ejecución (cómo resulta la experiencia de seguir el plan y cuales son los desvíos identificados, entre otras posibles observaciones)
  • Check: Verificar el proceso. Una vez finalizada su ejecución, es necesario realizar la evaluación del mismo;  comparar los resultados esperados con los obtenidos e identificar oportunidades de mejora.
  • Act: Adaptar el proceso en función del conocimiento adquirido en los pasos anteriores.

Para aquellos que tengan intención de reconsiderar sus procesos apuntando a  una próspera mejora continua para el año que viene, tal vez poner en práctica las sugerencias propuestas por el ciclo de Deming no sea una mala idea. Éxitos -en cualquiera las formas que los deseen- y feliz, muy feliz 2011!

Administración del tiempo

Insustituible, inexorable, indispensable, inelástico y equitativo. No es posible comprarlo, acumularlo, reemplazarlo ni por supuesto, dejar de consumirlo. Estamos hablando de tiempo, claro.

El  universo de tópicos relacionados con la gestión del tiempo es realmente grande. Asociado a las actividades de calidad, hay un tema en particular que se caracteriza por presentarse una y otra vez: la desmesurada asignación de prioridad a lo urgente sobre lo importante. En general, las impunes cuestiones urgentes siempre, pero siempre –con esa intempestividad que las caracteriza- irrumpen sobre las inofensivas, bondadosas y fructíferas actividades de calidad, tan importantes que son.

Una solución concreta y efectiva que previene la fuga de la tortuga que encamina los temas importantes, es comprometer –COMPROMETER- algunas horas (del día, de la semana o del mes) a realizar actividades asociadas a los temas importantes sin dejarse avasallar por las urgencias que imprevisiblemente surgen. Aunque suene fácil, es todo un desafío poder mantener esta práctica a lo largo del tiempo.

Pero las irrespetuosas cuestiones urgentes no se llevan solas todas las medallas. Hay –muchos, muchos- otros  factores que interfieren con la adecuada administración del tiempo; entre ellos podemos distinguir la  procrastinación, la parálisis por análisis y las reuniones no-efectivas entre otros muchos ladrones del tiempo.

Una estrategia sugerida por los ágiles es conocida con el nombre de Time boxing, la cual está fundamentada en una ley conocida como la Ley de Parkinson que dice que  “el trabajo se expande hasta llenar el tiempo disponible para que se termine”. Está relacionada con evitar extender los tiempos inicialmente definidos para realizar actividades. Es decir, una vez cumplido el tiempo asignado para una actividad, ésta debe darse por finalizada esté o no completa. Este tipo de práctica ayuda a entrenar a los integrantes de un equipo en realizar las actividades en el tiempo definido para estas.

El video  “Deadline” -en formato stop motion con post-it- ilustra varias de estas cuestiones.

Juegos para aprender

Juegos Para aprender es el nombre de un encuentro al que asistí hace un tiempo, organizado por Ágiles@BsAs en modalidad Open Space.

Dos de los juegos para aprender me resultaron particularmente interesantes; uno presentado por Fernando Claverino -amigo, coach para el desarrollo de este blog y ferviente impulsor de las metodologías ágiles- y otro por Claudio Juan Bidau (ambos miembros de Banquito). El primero consistió en una experiencia de dibujo de a pares conocido como Pair drwaing, y el segundo fue una actividad de diseño, construcción y trabajo en equipo bautizada  el  desafío del marshmallow.

Haciendo Pair drwaing es posible identificar con claridad los beneficios del trabajo de a pares:

  • –      Entusiasmo: Trabajar en parejas es más divertido y da mayor seguridad a las partes
  • –      Aprendizaje: Trabajar en parejas es una forma amena de compartir conocimientos
  • –      Cohesión de equipo: La gente se familiariza más rápidamente con la actividad
  • –      Visión unificada: Cuando las actividades de un proyecto se realizan en parejas, y las parejas se rotan con frecuencia, las buenas prácticas se van “mezclado” y pasan a formar parte del conocimiento común

El desafío del  marshmallow permite identificar con claridad los típicos errores de diseño (aplicables perfectamente al proceso de desarrollo de software) al proponer la competencia -en equipos- de construir la torre más alta en 18 minutos (utilizando fideos crudos, cinta adhesiva, un piolín, y la estrella: el marshmallow). El desafío consiste en construir la torre más alta, que tenga el marshmallow en la punta superior. Una experiencia realmente divertida que ilustra con claridad cuanta facilidad tenemos para cometer errores.

Visibilidad

La falta de visibilidad sobre los proyectos de una organización podría considerarse un escenario equivalente a no disponer de iluminación para inspeccionar como se está cocinando el Volcán de Chocolate en el interior del horno.

En el contexto de desarrollo de software, es posible dirigir la visiblidad sobre un proyecto en tres sentidos; hacia el cliente, hacia la organización y hacia los miembros del equipo.

Planteados los distintos destinatarios, es común que se presentarse una pequeña pero no por eso poco importante dicotomía:

  • Dar el mismo nivel de visiblidad en las tres direcciones
  • Ajustar la información en función del grupo al que está dirigida
  • Las prácticas de Scrum están fuertemente alineadas con la primera de las opciones, defendiendo la transparencia sobre estado del proyecto. Por otro lado, la segunda de las opciones tiene sus incuestionables beneficios, pero se le asocia la desventaja de tener que sumar a la inversión de esfuerzo que requiere generar los informes, el trabajo de adaptarlos.

    Las métricas automáticas proveen una solución cuantitativa concreta para obtener clara visiblidad sobre variables significativas de un proyecto…  Pero claro, una solución tan maravillosa no puede menos que ser cara, difícil de mantener y requerir mucha disciplina por parte todos los miembros del proyecto…

    Una práctica que maximiza la relación costo beneficio en este plano es realizar reuniones de avance periódicas. En dichos encuentros es posible presentar el estado del proyecto, los desvíos respecto a la planificación y la lista de riesgos.  Adicionalmente, reuniones complementarias a las de avance, como el kickoff y el postmortem (o restrospective -como le dicen los ágiles-) también proveen un montón de visibilidad sobre los proyectos y los procesos de la organización.

    Como conclusión,  podríamos decir que resulta central para la salud de nuestros proyectos que los involucrados puedan advertir con claridad el estado actual, hacia donde se dirigen, y cuán bien -o mal- encaminados están. Y en definitiva, lo que cueste esta práctica siempre va a ser un precio menor al costo asociado a que los involucrados en un proyecto no sepan en donde están ni hacia donde  van.

    Enseñando ágilmente

    Enseñando ágilmente es un trabajo que llevamos adelante con Fernando Waisman -Amigo, Colega y compañero de aventuras- en la Cátedra de Calidad de Software de la Carrera de Analistas Sistemas de Computación del Instituto de Tecnología ORT.

    La propuesta plantea un cambio al modelo docente tradicional -la clase magistral- aumentando el nivel de compromiso y participación de los alumnos. La idea se basa en otorgar a quienes participan en las clases un mayor protagonismo en la definición de los contenidos de la materia. Este cambio se asocia principalmente en la incorporación de algunas de las prácticas propuestas por el conocido y siempre bien ponderado marco de gestión Scrum.

    El trabajo fue presentado en la 39 jaiio y la versión completa del paper se encuentra disponible en http://www.39jaiio.org.ar/sites/default/files/39jaiio-asse-03.pdf.

    El cultivo de las buenas prácticas

    Se dice que la confianza se construye durante años y se derrumba en un instante… Con el ejercicio de las buenas prácticas, sucede algo parecido.

    Una buena práctica es aquella que de alguna manera, en alguno de los planos posibles, contribuye con la mejora…  lo cual no necesariamente significa que tenga que estar definida en un modelo de madurez o en un marco de desarrollo de gestión de proyectos (ni la recíproca, es decir,  una práctica propuesta por los distintos modelos no tiene por que ser útil para toda organización) El arte: tener la sensibilidad para identificar, en un contexto determinado,  las que sirven de las que no…

    En el marco del desarrollo de software, resulta muy difícil implementar actividades que favorezcan el proceso de mejora (y esa es la parte fácil). El real desafío -archiReContraSuperDifficile- es mantenerlas. Desde mi percepción, algunas de las razones por las que el ejercicio de las buenas prácticas se va disipando están relacionadas con:

    • –      Si no son adecuadamente implementadas, pueden convertirse en actividades exclusivamente burocráticas
    • –      El retorno de la inversión del tiempo invertido no es claramente perceptible (y mucho  menos en el corto plazo)
    • –      En algunas organizaciones está implantada la idea que se puede ser ágil (dinámico, pro, canchero, alineado con las metodologías de moda) ignorando la metodología tradicional…  sin implementar tampoco prácticas de las metodologías ágiles!

    Entonces… ¿Cuáles son las posibles acciones que se pueden tomar para evitar que las buenas prácticas se vayan diluyendo?

    • –      Elegir, en primer lugar, el subconjunto de actividades con el mayor retorno de inversión, y hacer foco en logar institucionalizarlas
    • –      Institucionalizarlas implica: Capacitar, coachear, seguir, controlar, evaluar, adaptar…
    • –      Identificar con claridad el beneficio para cada una de las personas que participan en la implementación de las distintas prácticas, y comunicárselos…

    Y como dice Antón Pirulero… Que cada cual atienda su juego… y en particular cada organización, sus buenas prácticas!

    Repostería y desarrollo de software

    La receta para preparar un rico volcán de chocolate, es la siguiente:
    Ingredientes: 200 g de chocolate, 40 g de manteca, 4 yemas, 50 g de azúcar, 2 claras. Preparación: Derretir el chocolate con la manteca por un lado, batir las claras a punto nieve (con la pisca de sal) por otro y batir las yemas con el azúcar a punto blanco. Luego mezclar claras con las yemas y finalmente integrar el chocolate. En moldes enmatecados llevar 10 minutos al horno.

    Si la calidad del volcán se gestionara con criterios equivalentes a los que se utilizan para desarrollar software…

    • –      No hubiéramos validado que los huevos estuviesen en buen estado
    • –      El equipo que prepara las claras hubiera pensado que el azúcar se lo ponía el equipo que preparaba las yemas, y el de las yemas, que el azúcar era responsabilidad del otro grupo.
    • –      Batir a blanco las yemas lo hubiéramos considerado un improvement y lo hubiéramos postergado para otra iteración.
    • –      Las claras a nieve las prepararíamos en la licuadora
    • –      Nos daríamos cuenta que es necesario sacar el  volcán del horno al empezar a  sentir el olor a quemado

    Una vez  listo el volcán, al probarlo consideraríamos bugs

    • –     Que tiene un dejo de gusto a rancio
    • –     Que le falta azúcar
    • –     Que se quemó un poco

    Para resolverlo…

    • –     Le rasparíamos los sectores quemados
    • –     Lo espolvorearíamos con azúcar impalpable
    • –     Y le agregaríamos dulce de leche para disimular el sabor rancio del huevo en mal estado.

    El desafío de este blog es arrojar algo de claridad sobre el universo de posibilidades que nos permitirán mejorar la forma en que desarrollamos software.