La sesión pasada terminó con muchas insatisfacciones y frustraciones, pero con ganas de mejorar, vamos bien, sin embargo, siento la confusión, no saben como mejorarlo, no saben por donde empezar, con esto adentramos con un poco de teoría: User Stories, Estimación, Ejecución, Plan de comunicaciones y espacios de trabajo visuales…

Antes de continuar con las actividades, realizamos la retrospectiva de lo que paso la última vez, en esta ocasión utilizaré otra técnica que permitirá sacar a flote todo aquello que salió mal sin que nos ataquemos entre nosotros o se sienta la tensión…

Una línea de tiempo me ayudará en esta ocasión, sólo pasa y escribe, cuán impactante han sido los temas que hemos visto para ti hasta este momento, ¿donde ha sido tu mejor y tu peor momento?,inclusive apoyar el peor momento de los propios compañeros de equipo; vemos como todos participan, están ansiosos de observar a los demás y ver que es lo que opina el equipo de las actividades que hemos realizado, identificamos las cosas que nos han gustado de sobremanera, y aquellas que no nos han parecido buenas, pero sucede algo interesante, tenemos una tendencia en donde muchas de las fallas del sprint pasado han desaparecido y ahora tenemos mucha área de mejora que no sabemos como atacar pero ahí está, al equipo le cuesta trabajo como es que puede conservar lo bueno que ha obtenido y le cuesta aún más determinar la forma en que aprovechará las oportunidades para optimizar su forma de trabajo, sin embargo, estamos satisfechos, inclusive felices, alguien en el equipo comenta:‘tienen razón, no tenía la actitud, disculpenme…’, podría describir este momento que fue emotivo para quién lo aceptó pero prefiero omitirlo por que causó una sensación que en palabras simples yo no puedo detallar, lo que sí puedo comentar es que llegó el momento donde hemos tocado esa fibra tan sensible que nos hacen personas, no somos máquinas….

Continuamos con las actividades, esto aun no termina…

Expongo un caso más apegado a lo real, la creación de una aplicación, clásico tal vez, pero importante el hecho de que tienen que identificar los puntos más importantes; proveo de herramientas para que ellos mismos hagan su dashboard, en este pondrán los PBI que han identificado y les darán una prioridad basada en lo dictado por el cliente; hay muchos nervios, es fácil pero difícil, tienen muy poco tiempo para exponer lo más importante por el cliente ante sus ojos y ante el desarrollo que están a punto de hacer.

Cuando termina el tiempo, vemos varias historias y las analizamos basados en los conceptos que previamente mencionamos: medible, ‘testeable’, intercambiable, y otros más…

Entonces viene algo interesante, nos vamos a subir a una montaña rusa, donde el sentir subirá y bajará para poder hacer nuestra actividad, y realizamos un ejercicio, en esta ocasión será de confianza con un compañero del equipo, en quién más confíes o con quién más trabajes, les proveo de su material que potencialmente podrían perder si fallan el ejercicio(y al fallar me refiero a la confianza depositada en su compañero); les explico la actividad y veo un par de caras de preocupación, no saben si confiar en esa persona con la que siempre han trabajado, es difícil y más si no podemos ver que es lo que hace…pero lo hacemos, confiamos y ejecutamos,y al ver los resultados quedamos sorprendidos, “¿qué fue lo que pasó?”-dicen algunos-, “todos han hecho la actividad correctamente”-les digo- determinen ustedes mismos, y hablemos de lo sucedido, ¿que pensaron?¿que sintieron?, al ver el resultado ¿cuál es su conclusión?, de aquí destacamos dos comentarios, donde alguien dijo textualmente: “…pensé que no podría confiar en él, incluso al cerrar los ojos supe que se aprovecharía de mí, pero cuando vi el resultado sentí bonito al ver que el también me apoyo…”, y alguien más dijo: “…jamás pensé que pudiera contar de esa manera con mi compañero…”, ya estamos casi del otro lado…

Y siguiendo con el plan de actividades llegó la hora de trabajar en equipo, pero, aún no con el proyecto que analizamos, mejor simulemos una pequeña batalla, donde comunicarse, arriesgarse y entrar en colaboración es fundamental, ¿por qué lo hacemos así?, simple, así son los proyectos, a veces no tenemos idea con que nos enfrentamos, habrá alguien que tenga alguna experiencia en lo que vamos a hacer, tenemos que descubrir un camino, pero no tenemos mucho tiempo, de hecho son minutos o segundos con los que contamos pues alguien nos va a atacar y no sabemos como defendernos, hay que distribuir los recursos, tener una estrategia, asumir control de la situación, cualquiera debe de poder atacar/defender de ser necesario, son tantas cosas las que hay que hacer…

Y damos inicio, de todas las sesiones, en ninguna se habían comunicado tanto como en esta actividad, las voces se alzaban mucho casi a gritos tratando de transmitir sus ideas, dando consejos, pidiendo ayuda, preguntando, y después poco a poco se empiezan a poner de acuerdo, ya conocen un poco más el terreno, ya han explorado, saben que se puede hacer, hay que aprovecharlo, existe un objetivo común y hay que realizar varias tareas para lograrlo, poco a poco la comunicación fluye mejor y justo cuando ya están casi listos, se suspende la actividad(puedo confiar en ellos), y lo hacemos para ver que cosas podemos mejorar, que cosas hicimos mal, ver como atacaremos el problema, veo que hay energía, hay ganas, están ansiosos de seguir; para después continuar con nuestra batalla, los mensajes que se mandan son cada vez menos pero son claros y son muy fáciles de interpretar, ya cada quién sabe que hacer, ellos se han puesto de acuerdo, saben de que son capaces, la justa es pareja pues están al nivel, y por último otra reunión, esta es importante ya que están a punto de conseguir su objetivo, hay muchas mejoras entre lo que deben de hacer y lo que están haciendo, ya casi no hace falta dirigirlos ellos se auto-organizan.

Nuestra batalla termino con resultados que ni ellos mismos se esperaban, se sorprendieron al ver con que facilidad pueden comunicarse, y que tan rápido pueden atacar un problema sin que tengan que planear tanto(claro! no había mucho tiempo…), se apoyaron entre ellos y aportaron ideas, consejos y planes para alcanzar el objetivo…

“¿Qué fue lo que pasó?”-les pregunté-, y un par de ellos contestaron: ”no sé, pero hicimos algo juntos”; claro, ya estaban adoptando los principios ágiles y también los estaban aplicando en algo que no conocíamos pero teníamos que atacar en poco tiempo, y que con ayuda de todos y teniendo muy claro el objetivo pudimos conseguir…

Damos un tiempo de reflexión para que todas esas ideas, conceptos y actividades pasen a un estado consciente, en donde, tomarán forma y por fin aterrizarán en la siguiente y última actividad…

Pasemos al laboratorio, y hagamos la aplicación que analizamos en un principio donde hicimos algunas historias de usuario, tomemos la que tenemos en la prioridad más alta y vamos a desarrollarla, pero ahora con el conjunto de principios que ya conocen, y ahora sí: “¡hagan ágil!”, frase que dejo a la opinión de cada quién…

Lo importante de esto era que llevarán a cabo el conjunto de prácticas que en su momento habíamos mencionado/practicado, es decir, las reuniones que creyeran necesarias, los ajustes y mejoras progresivos, así como los principios mostrados, pero esto no era suficiente, ya que el día a día requiere también de un conjunto de prácticas y pensamientos que permiten a un desarrollador mejorarse, es por eso, que hablamos un poco de TDD y CI, que aunque no lo tocamos a profundidad si resaltamos su importancia, y adicionalmente, coloque en el frente un conjunto de sentencias que mientras estuvieran trabajando deberían leer en cualquier momento, de las cuales comparto algunas de ellas:

¿qué hacemos?

Adelante toma ese atajo, Te ahorrará tiempo, de verdad. Nadie lo sabrá. Puedes terminar esta tarea y seguir rápido. De eso se trata esto, no?

¿qué hacer?

Siempre enfrenta los problemas más difíciles primero, y deja el simple hasta el final

¿qué hacemos?

El primer y más importante paso en el tratamiento de un problema es determinar quién lo causó. Una vez que se haya establecido la culpa, entonces asegúrate de que no vuelva a ocurrir. Nunca.

¿qué hacer?

La culpa no corrige errores. En lugar de dedos apuntando, apunten a posibles soluciones. El resultado positivo es lo que cuenta

¿qué hacemos?

No es necesario entender realmente ese pedazo de código, parece que funciona bien como está. Ah, pero sólo necesita un pequeño ajuste. Solo suma uno al resultado y funciona. Sigue adelante y ponlo, probablemente esta bien.

¿qué hacer?

No caigas en hacks rápidos. Invierte la energía para mantener el código limpio y expuesto.

¿qué hacemos?

Los desarrolladores son creativos e inteligentes y saben más acerca de la aplicación. Por lo tanto, los desarrolladores deben tomar todas las decisiones críticas. Cada vez que la gente de negocios se mete, hacen líos las cosas; no entiende la lógica de la forma en que lo hacemos

¿qué hacer?

Deja que tus clientes decidan. Los desarrolladores, gerentes o analistas de negocio no deben tomar decisiones de negocio críticas. Presenta información a los propietarios de negocios en un idioma que puedan entender, y deja que tomen la decisión.

Entre muchas otras más…

Definitivamente en ese espacio final los chicos trabajaron bastante, algunos de ellos no habían trabajado juntos en algo común, solo en cuestiones relacionadas que podían llevar por separado, ahora pudieron materializar requerimientos transformados en historias de usuario, hubo problemas claro, hubo soluciones claro, pero lo que pudieron ver es que todos estábamos trabajando, y sabíamos que estábamos haciendo, cuál era el status de nuestro producto y cualquiera podría tomar el control, hubo preguntas al cliente, ya no hubo tantas suposiciones, simplemente iniciaron el camino para adoptar métodos ágiles, no se hicieron expertos en ágil, claro que no, ya que también nosotros estamos en el constante sendero de la mejora continua, sólo recibieron de primera mano, los conceptos a través de vivencias que los ayudarían a seguir ese camino…

Para finalizar, nuestra última retrospectiva, ahora usaré la técnica de radar, aquí podremos ver que cosas nos harán falta de aquí en adelante, y de modo personal atacar esas áreas donde hay una potencial oportunidad, la actividad de esta retrospectiva es simple, con tarjetas, un sistema basado en puntos, lo importante son las conclusiones a las que cada uno de ellos puede llegar, pero destaco los 3 aspectos en el orden en el cuál aprendieron/sintieron/gustaron durante el curso:

1. frustración
2. felicidad
3. agilidad

Indudablemente, nuestro objetivo como transmisores de los conceptos y principios ágiles ha sido cumplido…

Para finalizar me atrevo a poner algunas opiniones de los chicos, que muy amablemente me escribieron en una tarjeta cada uno de ellos:

“A manera personal me dejó una gran satisfacción puesto que no tenía idea de que trataría y que sólo era un curso más de algún lenguaje de desarrollo que no entendería.

Me gusto mucho la forma de exposición, algunas cosas no las comprendí pero a futuro y con experiencia me quedarán más claras.

También me cayó el 20 de que está pasando conmigo, cambiando mi visión personal, despertando un gran interés por continuar capacitándome, buscar la forma de ayudarme para poder ayudar…” Anónimo

“Este curso me enseño mucho cómo poder trabajar con cosas sencillas y de manera más rápida…

El curso tuvo muchas dinámicas interesantes que sacaron de mi una frustración que tenía en la mente. Hay una persona del equipo a la cuál no le quería hablar y por lo tanto se me hacía difícil externar lo que sentía, pero una vez que pude en la dinámica de fortalezas no pude dejar de participar de manera continua…

El implementar la técnica con cosas reales me dio la pauta para volver a tomar el gusto y el interés en programar con calidad y en menor tiempo.

Quiero comprometerme pero el que no me tengan confianza me frustra, pero trataré, por que quiero ser ágil por mí y por los demás

Gracias por ponernos el ejemplo…” Anónimo

“Estoy muy satisfecho con el curso desde varios puntos de vista:

- Por la forma de llevar el curso, realmente es un curso para desarrolladores dando la importancia y relevancia de lo que implica considerarse un desarrollador

• El contenido del curso de muy buena calidad
• Los conceptos técnicos también muy bien explicados
• La actitud del instructor
• En general muy bueno”

Anónimo

• Evidencie el avance del curso, los participantes se dan cuenta de que es lo que tenemos que hacer, que es lo que hemos hecho, incluso se resalto cuando no terminaríamos los temas que se tienen que cubrir en el ‘sprint’.
• Mejoramos y continuamos mejorando la forma de impartición y el material que damos en el curso, gracias a las retrospectivas realizadas al final de cada sprint, punto que me agrado demasiado, por que siempre tendremos algo que mejorar.
• Comunicamos los problemas que tuvimos, las resoluciones, los acuerdos a los que llegamos, nuestras inquietudes, además de las cosas que no nos gustaron de las sesiones de curso(importante).

¿Cómo pudimos hacer esto?, con post-it’s, pero principalmente con el significado que le damos con SCRUM, evidencie con las tareas del dashboard, y frente al mismo, comunicamos nuestros problemas y propuestas, los objetivos y cosas que tenemos en común, y también, con los post-it’s(y SCRUM claro está) pudimos realizar nuestras retrospectivas de cada sprint…

Ahora bien el uso de los colores fue intencionado, y al final mi bloque de post-it’s quedó con colores más gruesos entre ellos, ¿qué significa eso… hablando de tareas y hablando de retrospectivas ?…

No quiero sacar conclusiones propias al respecto sobre el tamaño del bloque, no sería objetivo para este caso, sin embargo, dejo a criterio de los lectores la conclusión, lo que si quiero comentar es que en definitiva me ayudo a percatarme de todas las mejoras que podemos hacer en la realización de nuestras tareas y en los servicios que ofrecemos, me percaté de las cosas en las cuales debo de hacer enfásis para resaltar justo lo que quiero dar a notar, en simple, podemos mejorar mucho nuestros servicios para con los clientes.

Y mucho más en corto, SCRUM sirve, me sirvió a mí y también a los que participaron en el curso…

El grado de satisfacción de todos los que estuvimos poco más de 32 horas en ese salón fue gratificante y no me quedá más que agradecerles su preferencia, y comprometernos a mejorarnos continuamente para que ellos, cualquier persona recomendada por ellos y los nuevos interesados encuentren por lo menos que hemos mejorado desde la última vez que ofrecimos un curso similar.