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

Al reiniciar, y ver que aún no estábamos todos, le pido a una persona(previamente identificada) que cuente una broma o una anécdota que sea embarazosa, tenía que poner el ejemplo y lo hice, con la finalidad de poder ofrecer confianza, y simplemente no se atrevió, no por que no supiera, simplemente no era su mejor momento; un miembro del equipo le ayudó, ya existía algo de colaboración ante una falla, fue buena y se reavivaron los ánimos, comenzamos bien…

Sentí esas miradas de molestia y de incomodidad, ¿y como no sentirlas?, todo lo que habían usado por años les estaba cobrando y de la forma más dolorosa, y no sólo eso, lo estábamos demostrando, no era solo decir: “lo que usas es incorrecto”, por que ni siquiera esa era la sentencia correcta, es: “…puede que en esto que estás viendo y te estoy demostrando encuentres esa motivación que te hace falta para cambiar la forma y mejorar lo que haces actualmente…”

Retomemos los temas -les digo-, una situación fuerte: ¿son ustedes capaces?¿técnicamente hablando pueden hacerlo?¿qué esperan ustedes de este trabajo?¿que ofrecerán ustedes a este proyecto?¿están motivados?¿si/no, por que?, si no era suficiente con esa tensión inicial donde todos me veían feo, ahora si acabo de aventarle una bomba molotov a ese proyecto que tiene chispas y mucha probabilidad de quemarse en las manos de un Project Manager; lo tenía que preguntar, este tema no es en vano, enfocarnos, ¿Cómo comenzar?, conocernos a nosotros mismo y a nuestros compañeros, describamos el producto que vamos a hacer.

Sigamos un guión, simplemente describamos lo que estamos haciendo de una forma dirigida y enfocada, que vemos en este curso para ustedes, ¿quiénes debemos estar aquí?, ¿que nos diferencia?; afortunadamente, las respuestas son más agradables de lo que esperaba, mejor aún, todos entendemos de que se trata, es simple y conciso, así deberían ser sus objetivos en el desarrollo de un proyecto…

Siendo así, tomemos lo mejor de lo que acabamos de describir y armemos nuestro producto, ¿cómo queremos que los demás lo vean?, ¿nosotros mismos lo compraríamos?, seamos honestos, si nosotros usáramos este producto entonces ¿pagaríamos por él?, ¿no?, ¿por que? si lo estamos usando nosotros mismos, a nuestro producto le hace falta calidad o no hace todo lo que esperamos…

Tomemos esas ventajas y diferencias de los demás para hacer el diseño de nuestro productos, así los demás lo concebirán de la misma forma en que nosotros lo hacemos, y dejemos en claro una cosa, que NO es nuestro producto o que NO cubriremos en el desarrollo de este software, el método de definirlo, muy simple…una lista.

Nuestro siguiente tema, conocer muy bien a nuestros colegas, con quienes estamos trabajando. seguramente no nos hemos dado cuenta pero hay más gente de la que creemos involucrada en nuestros proyectos de software, incluso en este curso, ¿quiénes son?¿cómo hablamos con ellos?, solo estemos conscientes de ello por el momento.

Identifiquemos en el equipo a un par de líderes de proyectos y arquitectos, y hagamos dos grupos iguales, los desarrolladores serán valorados en su momento, mientras tanto, que tomen un descanso y hagamos trabajar a ‘quienes saben diseñar productos’ en algo simple, la transmisión de una idea que deberán de documentar detalladamente para nuestros desarrolladores. Se nota que hay habilidad para transmitir ideas y para tomar notas de los detalles finos, hay confianza en lo que hacen, es el trabajo de todos los días, ¿como no contar con esas habilidades?, corre el tiempo, las descripciones se vuelven complicadas por el nivel de detalle que se solicita, y se acaba el tiempo, que vengan los desarrolladores. Solamente se les deja un documento con la especificación de lo que se desea, arquitectos y líderes de proyecto se retiran a su merecido descanso, ya han trabajado bastante, además, el proyecto está bien documentado y los desarrolladores son buenos en lo que hacen, cuando regresemos el proyecto estará listo…entonces 1==2…claro que no, lo se de antemano, ellos harán su mejor esfuerzo para terminar el proyecto, darán su vida por él y se sobre-esforzarán, sin embargo, no habrá nadie a quien preguntarle, “asumirán” que es lo que quiso decir ese documento, esa especificación, ese renglón, esa palabra.

Cuando todos estamos de vuelta, mostramos lo que esperábamos de los desarrolladores, líderes y arquitectos con un producto medianamente cercano a lo que querían, desarrolladores diciendo: “si hubiéramos preguntado…”, el hubiera no existe, pero ya existe esa inquietud, hemos progresado, hay una incertidumbre natural al desarrollar algo,  no todos están en ese mismo plano, pero alguien del equipo los guiará por que se ha sembrado esa duda.

Ya conocemos a nuestros colegas y sabemos que necesitamos de todos, que hay más gente involucrada, entonces, hay que entrar en acción…

Se habla de presentar soluciones técnicas, examinar los riesgos, dimensionar las actividades, ser claros en lo que vamos a ofrecer, ser realistas con todos…

¿Cuál es la expectativa de nuestros usuarios/clientes en este proyecto de software?¿cuáles son nuestras hipótesis de la posible solución?, pudimos haber charlado de ello, pero era meramente técnico, confío en su habilidad, mejor ataquemos algo más profundo, ¿que nos quita el sueño?, ¿que riesgos hay en un proyecto?, seamos realistas no todo es color de rosa, Scrum no me quita los problemas sólo me ayuda a identificarlos y mostrarlos ante los demás, el espíritu ágil me provee de la capacidad de exponerlos, de colaborar con el cliente/usuario, el reto esta ahí, ya están casi listos para lo que sigue, tal vez no tengan la habilidad técnica, tal vez no tengan el mejor equipo de cómputo, ni la red más abierta, pero tienen algo mucho más importante que ya comenzamos a entender: la actitud profesional, eso nos ayudará mucho, una breve tarea para todos, “para nuestra siguiente sesión me gustaría que cada uno de ustedes comentará acerca de alguna nueva tecnología, o descubrimiento dentro de sus aplicaciones que crean pueda aportar a su labor” – expresé y di un ejemplo breve…

Habrá retos y problemas sin duda, hay que identificarlos, darlos a conocer y sobrepasarlos, adaptarse al cambio; ya hay un sentimiento en el aire de dolor y aceptación, de eso que lástima pero que nos fortalecerá cuando deje de sentirse, y viene lo que todo cliente/usuario o manager quiere saber, ¿cuánto? dinero y tiempo…

Hablemos simple, pensemos en pequeño y establezcamos expectativas, comentamos un par de casos para que las cosas no se escapen de las manos, veamos que pasaría si variamos el tiempo de entrega, inferimos que si el período es corto tendremos que entregar resultados lo más pronto posible, ¿y que no es eso lo que estamos buscando?, no hay duda todos estamos de acuerdo: siempre habrá más cosas que hacer que el recurso económico y el tiempo del que podemos disponer.

Entonces, ¿que podemos ofrecer?, ¿cuáles son los elementos variables en los que nos podemos apoyar?, hablaremos de ello en su siguiente sesión, debemos de cerrar está sesión con un ejercicio muy amplio…

“Ustedes son muy buenos en lo que hacen”, comenté, por lo tanto les confíe una tarea, una labor: crear un producto complejo…

¿Por que era complejo?, bien, el caso era el siguiente: exponer una temática, un contexto de un cliente distinguido que se diferenciaba de los demás por ciertas características que nadie más tenía, y dicho cliente quiere innovar en la línea de sus productos dejando en claro su identidad, hay que establecer las reglas; adicionalmente tengo historias y comentarios con valor que en su mayoría son ambiguos, no están del todo claro, lo importante es que ellos tienen que identificarlos; y seguido a esto, les proveo de su material, papel, clips, globos, algodón, tijeras, entre otras cosas…

Se forman dos equipos del mismo número de personas para esta actividad y hago entrega de una parte de los requerimientos traducidos en pequeños enunciados que tienen la intención de obtener valor, el tiempo es reducido y lo tienen que realizar con las técnicas y conceptos comentados durante el curso. Sin más damos comienzo al ejercicio…

En ambos lados leen las historias, y comienza el desorden, me siento a observar… el desenfoque es total, los esfuerzos están mal dirigidos, primer error: no escucharon. Pero algo bueno sucede, de un lado del equipo se acercan a preguntarme al respecto, y me niego a hablar a propósito, del otro lado sucede lo mismo y soy justo en este momento, al negarle mi atención; de repente sucede: “¿puedo regresar en otro momento?” -me preguntan- “claro” -respondí-…las inquietudes se hacen llegar al respecto de los enunciados, pero la idea principal no es vista aún, les tomo su tiempo, ellos trabajan duro en completar el mayor número de requerimientos, no hay prioridad en las tareas,  hacen las que consideran más simples y sencillas, está claro, parte del gran dolor se acerca, y no obstante, para hacerles más dura su labor agrego más requerimientos…

Medio tiempo, después de un par de ciclos dictados por el marco de trabajo, debemos de mostrar algo, comencemos con el primer equipo, y les digo: “El cliente es diferenciado por una característica muy grande y notoria que es parte de la marca, ¿su producto cuenta con ella?”, por inercia y debería decir incluso inocencia su respuesta es: NO, y sin dejarlos hablar digo: “no me sirve”. Repito la pregunta con el otro equipo, misma inercia, menos inocencia, sin embargo, hay quién alcanza a decir: “aunque tenemos muchas otras características desarrolladas”, y yo afirmo diciendo: “La marca del cliente dice que esta característica debe estar en todos sus productos, ¿este producto la tiene?”, la respuesta del equipo: “NO”, y confirmo: “entonces no me sirve…”, ¿golpe al orgullo?, tal vez, ¿frustración?, seguramente, su entendimiento acerca de lo que esta sucediendo poco a poco va fluyendo, y por fin veo lo que esperaba: prioridad en las tareas, colaboración, aunque temo que en una pequeña parte había influencia del jefe del área, las cosas iban saliendo, se dieron cuenta del valioso tiempo que habían perdido al no atacar los verdaderos problemas; en medio del siguiente ciclo de acciones les hago entrega de más requerimientos, “no lo puedo creer…” -dice alguien-, los comentarios en el salón: “como los proyectos que tenemos…”, claro!, lo que está sucediendo no dista en nada de la realidad, la diferencia es nuestro producto y las herramientas…

Un hecho interesante sucedió cuando les di sus últimas tareas, un par de miembros del equipo se acercó y preguntó: ¿Qué es?¿Qué entró nuevo?, y la persona encargada de filtrar el requerimiento(PO) les dijo: “Yo lo atiendo, ustedes concéntrese…”, ¡Bien! -dije entre mí-

Además casi al final, me acerque y pregunté a cada uno de los equipos: ¿cómo van?, en ambos casos me respondieron: “Llevamos todo esto”, lo observé y solo pude decir:’oh eso se ve bien…’, sin embargo, dentro de mí al leer lo que tenían hecho vi que asumieron muchas cosas, no preguntaron ni se acercaron…lo iban a lamentar seguramente…

Se terminó el tiempo, llego la hora de demostrar que sus productos tienen valor y que cumplieron con la expectativa del cliente. Vamos con el primer equipo, su producto se ve interesante, sus miembros han llamado mi atención por la forma en que trabajaron, muy desenfocados y esparcidos de inicio.

Nuevamente, “el cliente requiere que su marca se vea reflejada en este producto por la característica que los hace únicos ¿su producto cuenta con ella?”-dije-, y una respuesta que los hace respirar: SI, y continuamos, “¿que valor están aportando a su proyecto?”, se ven ambiciosos y comienzan con las tarjetas mejor valuadas, y hay que demostrarlo; inicia la lectura de nuestro requerimiento, y lo cuestiono en cantidad y calidad, se ven entre ellos asustados, “eso no lo preguntamos…”-dice uno de ellos-, su éxito se ve frágil, ahora han probado un poco de ese sentimiento de frustración y de incapacidad pues el tiempo ha terminado, su habilidad se está poniendo a prueba, y al seguir con cada requerimiento viene detrás un cuestionamiento, algunos son cumplidos, algunos no, se ven endebles, con el pensamiento de: ‘hubiera…’, es insuficiente.

Muchos requerimientos fueron descartados, casi más de la mitad que hubieran aportado un gran valor, pero en la demostración de uno de ellos, el de menos valor, en ese se llevaron más esfuerzo, “reflexionen…”-les digo-, “¿cuánto tiempo gastaron en cumplir este de menor valor y cuantas personas ocuparon que bien pudieron aprovechar?”…

Al final de la demostración del primer equipo hacen malabares, improvisan, se ponen nerviosos, “¿no es sencillo verdad?”-les digo-, contemos cuanto valor aportaron para tenerlo presente; continuemos con el segundo equipo y sin decirles una sola palabra dicen “estos requerimientos no los vamos a cumplir mejor no los consideremos”, han visto su proyecto caer antes de tiempo, no hicieron las preguntas difíciles en su momento, que pena por ellos, pero lo han entendido, ese es el punto, han visto que todo va más allá que unos simples documentos: “colaboración con el cliente sobre negociación contractual”.

Comienza su showcase, ya saben que hacer, leen las tarjetas y hacen las pruebas necesarias(pruebas…interesante palabra que examinaremos en lo que restará del curso), ellos saben que hacer y que descartar, menos malabares, menos improvisación, más realidad, simplemente se dan cuenta de lo que ha sucedido, y cuentan los puntos que han acumulado, la diferencia es muy pequeña entre ambos equipos.

Están casi listos, sus sentimientos están expuestos, han fracasado y han entendido, están frustrados, será interesante saber que piensan en la retrospectiva, que les ha gustado, que no, que están haciendo bien y que están haciendo mal, que pueden mejorar, que quitar, que deben de des-aprender…

En Enero(2011), tuvimos la oportunidad de impartir un curso denominado “Creación de grupos ágiles para el desarrollo de software”, en donde mucha de la temática circulaba alrededor de un marco de trabajo como Scrum y algunos conceptos breves de Kanban, pero más allá de dicha temática meramente teórica, pudimos hacerles llegar a los asistentes la experiencia de trabajar con métodos ágiles y compararlos con las técnicas que han venido usando, esto a través de diferentes actividades tangibles que podrían considerarse el 70% del contenido de un curso con duración de 24 horas.

Me llamó mucho la atención varios aspectos en los que seguramente muchos de nosotros hemos caído ( y no dudo que sigamos cayendo, lo importante es salir de ellos lo antes posible ): la comodidad, la apatía, la indiferencia, la falta de expectativa, la incertidumbre, la presión, la dignidad de tu trabajo, la confianza(mucha o nula), la concepción de un proyecto, la impuntualidad, entre algunas otras. Sin embargo, hubo quién quiso darse la oportunidad de mejorar la forma en que el equipo de trabajo hace las cosas, las personas indicadas, un director de sistemas y un líder de proyecto, personas que querían ofrecerles a su equipo de trabajo una mejora en su trabajo, lo que ellos no sabían era hasta que punto podrían llegar.

Podría describirles estas actividades, pero prefiero escribirles acerca de los sentimientos y percepciones que pude notar de los asistentes…

Un salón vacío, preparando lo necesario para las actividades del día, el espacio muy amplio, justo como lo necesitaba, sillas y mesas acomodadas en ‘U’ de tal forma que podrían rodearme y vernos todos las caras, acomodo un cuadernillo y una pluma en los lugares más cercanos a mí y la gente comienza a llegar, son sólo 3 personas que al ver su material adoptan su lugar, de a poco empiezan a llegar un par más, y comenzamos la actividad, exceso de comodidad, veo como se desempeñan y se sienten a gusto “cómodos” con lo que hacen, nadie siquiera se levanta de su lugar, todos están sentados, llega otra persona y es muy curioso se sienta lo más lejos posible, le invito a que se acerque y se una a la actividad, dándole la indicación a sus compañeros que le expliquen de que trata; al finalizar la actividad cuestiono a los asistentes acerca de lo que pasó, ¿por que no pudieron hacer más?, las respuestas, las que esperaba: “por culpa de X”, “¿cómo podemos hacer más?”, “Hicimos bastantes…”, “No se nos ocurrió otra forma…”, “No nos hablamos…”, etc., los veo diciendo a sí mismos: “si sabemos en que estamos mal”, pero no discerniendo: “¿y que podría hacer para mejorarlo?”, su ventaja y desventaja al mismo tiempo: “Todos se conocen muy bien”, pero no tan bien como creen…

Seguido de esto, su primer acuerdo, ¿a que venimos a este curso?, el objetivo de cada uno de ellos muy diferente, no sabían que esperar de este curso, tenía que hacerlo con discreción, ahí estaba tanto el líder de proyecto como el director de sistemas, su opinión podía estar influenciada, un objetivo no muy claro, era natural al no comunicarles la intención de nuestra presencia.

“Conozcamos un poco de nosotros” – dije -, de forma profesional, técnica y personal, veamos cuales son nuestros intereses; caminamos juntos y poco a poco se empiezan a integrar, ya hablan, ya no les es indiferente lo que pasa, pero hay temor, “puede que diga algo que no sea correcto” -debe ser su pensamiento- , todos están de acuerdo con lo que dice el líder y el director, no podemos equivocarnos, nos van a marcar, – veo en sus expresiones -, rompo la tensión con un comentario tonto, demostrando que lo que diga en este momento no es trascendente, solo quiero la confianza, la integración y alejar la indiferencia. Poco a poco va fluyendo…

Les expreso mi objetivo para con ellos, y les hago un par de advertencias: “se van a entretener y en algunos casos sentirán frustración”.

Comenzamos bien, ya estamos despiertos y atentos, veamos algunos conceptos: predictibilidad y desarrollo iterativo incremental, demostremos de que se trata cada uno de ellos.

Ya basta de teoría, había que ver si estamos listos para este curso, tratemos de cambiar nuestra mentalidad, ¡un ejercicio!, las instrucciones son simples y claras, incluso afirmo con una pregunta -¿sencillo, no?-, todos asienten; nos levantamos y comenzamos, hay problemas al ejecutar la tarea, no lo hacen conforme las instrucciones, en realidad tardan un poco en comprender que es lo que pasa, están confundidos, les pido se detengan y vuelvo a explicar conmigo mismo como ejemplo, empiezan bien, fluye de a poco, existió un momento donde lograron sincronía y de repente, vuelven a tropezarse, les pido se detengan y comiencen de nuevo,  y como en todos los grupos, existen quienes lo comprenden y quienes no saben por que no lo pueden hacer, la respuesta es simple: no escuchamos y nos falta humildad, termina el ejercicio y pregunto ¿qué pasó?, los comentarios muy acertados pero también la confusión, -pero si era muy simple- exclamó alguien, y conjugo -¿donde está el problema entonces?-, reflexión que tienen que hacer para sí mismos…

Seguimos con algunos otros conceptos, desarrollo en cascada, en espiral e iterativo, después, ¿qué es Scrum?, sus bases y más allá, es fácil pero también es difícil; los documentos lo dicen tiene artefactos, roles y reuniones, sigue un flujo, expliquemos de que trata cada uno, el mundo ideal de Scrum, todos es felicidad si tu sigues estas reglas, pinta bien seguirlo, no se parece en nada a lo que han venido usando, pero lo importante es identificar al equipo, ¿quién de ustedes esta comprometido?

Con un paréntesis hacemos otro ejercicio, y nuevamente notamos que aún no escuchamos, y mejor aún, se nota como “el desarrollador sabe lo que hace y sabe que es lo mejor para el cliente”, aunque no haya sido lo que el cliente pidió, pero para el desarrollador es algo que funciona y se puede usar.

Veamos la realidad, ¿que son los equipos ágiles?, no son ni cercanamente ideales como lo dice la teoría, pero debemos de estar conscientes de que podemos aprovechar las habilidades de cada uno de los miembros y tender a la mejora continua con el paso del tiempo, ¿como mejoramos continuamente?, bueno, hay muchas maneras solo hay que encontrar la indicada, y para ello hay que saber con que tipos de personas tratamos, ¿quienes estamos en esta sala? -pregunto yo- y realizo un cuestionario, lo doblamos y lo aventamos de forma simbólica, cada uno deberá recoger un cuestionario que no sea el propio y leerlo ante los demás, con el paso de cada pregunta y respuesta, el asombro se hace presente, mejor aún, a pesar de todo están motivados pero mal enfocados, es evidente, el director de sistemas y el líder de proyecto saben que algo anda muy mal, ¿cómo es posible tener gente con toda la actitud profesional y no poder sacar un proyecto?

Antes de tocar el tema de “Inicio de un proyecto ágil”, hacemos otra actividad, se les presenta un problema común y lo tienen que resolver técnicamente, mostrar la solución(diagrama) con el conjunto de herramientas que van a usar y describirlo ante mí. Solo necesitan un pizarrón, plumones, sus ideas y la habilidad técnica, nuevamente se hace presente el peso del líder de proyecto y del director de sistemas, afortunadamente tengo el remedio para ello, veo que hay quien le interesa, quien no, hay quién observa pero no sabe que decir, quien no dice absolutamente nada, y empiezan a “matar moscas a cañonazos”, y justo cuando me lo presentan, me venden una solución que solo le faltaría hacerme un café para ser perfecta, pero…no es lo que pedí…

“Trabajen nuevamente en ello” – les digo -, la siguiente solución es mucho más simple, pero demasiado simple de hecho no se puede crecer y debe estar pensado para ello como todas las arquitecturas, bueno, última oportunidad, la confusión total, no saben que presentar, también es evidente: hay una brecha técnica incluso entre ellos.

Y entonces, ¿como iniciamos un proyecto ágil?, un poco de charla entre nosotros, meramente la experiencia y el conocimiento que deben de considerar previo a hacerlo de verdad, introduzco algunos de los principios derivados del manifiesto ágil.

Veamos si ya han concebido un poco de esto, aunque de antemano se que no, estamos en el proceso… formamos 2 equipos y les proporciono un material muy delicado; la labor es levantar una torre lo más alto posible en 18 minutos, explico las reglas y comienza a correr el tiempo, transcurren 5 minutos y aún están examinando el plan y el diseño, a los 8-9 minutos comienzan a construir, hay problemas en cada uno de los equipos, la torre no se puede levantar, la levantan y se cae, el plan no está funcionando, veo sus expresiones de frustración, no es posible -exclama alguien- al ver que la torre se cae y ya casi acaba el tiempo, prácticamente no tienen nada, el otro equipo logra levantar algo, termina el tiempo y les hago notar que mentalidad usaron: la cascada…hemos dado el primer paso, sabemos que estamos usando y estamos muy conscientes de ello; y alguien dice: “pero nosotros si logramos la torre e incluso antes de que acabara el tiempo…”, es correcto -dije-, pero la comodidad no les permitió hacer más(la torre más alta) en dado caso de que el otro equipo también levantara una, simplemente se conformaron, ¿donde está la calidad que pueden ofrecer a su trabajo si nos limitamos nosotros mismos?

Fin del primer período, y es tiempo de dirigir una retrospectiva, ya vimos teóricamente ¿qué es y de qué trata una retrospectiva?, y les mencionó la importancia que estas tienen, pido se me preste atención por que todos en algún momento tenemos que hacerlo; y comienzo, “esto nos va a servir para identificar ¿qué hicimos bien?, ¿que hicimos mal?, ¿que debemos agregar o quitar?, y les mostrare una técnica para hacerlo …”, ya había aplicado esta técnica antes, capté su sentir a través de sus propias palabras: “con ganas”,”interesado”, “emocionado”, “algo nuevo”, fueron algunas de sus expresiones; era la primera iteración del curso, ahora es cuando podemos mejorar, seguido capturamos los datos…

Comentarios fuertes, tensión en el ambiente, la temperatura de la comunicación cara a cara se hace presente, sin embargo, no había nada que no se pudiera mejorar, el balance fue bueno para ser su propia instalación y no saber a que me enfrentaba de principio, el grupo aún con miedo de decir ciertas cosas que puedan hacerlos ver mal, aún con eso, pudieron darse la oportunidad de comentar que era lo que les agrado de los temas vistos y actividades hechas y que fue lo que no les agrado y podríamos mejorar, tenía que hacer algunos ajustes para la siguiente sesión…

• UPAEP(Universidad Popular Autónoma del Estado de Puebla)
  • En donde con ayuda de Jaime Castillo y María del Rocío Gpe. Morales, presentamos el tema de:
    • “Lenguajes dinámicos para la JVM” por @neodevelop
• FLISOL(Esime Culhuacán)
  • Enrique Díaz(@nRikeDiaz) fue organizador de este evento en esta universidad y junto con él pudimos participar en dos charlas:
    • “10 años en la industria, ¿Que esperar de la universidad?” por @domix
    • “Introducción a Groovy” por mí(@neodevelop)
    • “Introducción a Grails” por @domix y yo(@neodevelop)
• GULEV(Grupo de Usuarios Linux del Estado de Veracruz)
  • Con lugar en el WTC de Veracruz y organizada por Miguel Angel López (@GulevSL), presentamos las ponencias de:
    • “Estrategias ágiles para incrementar calidad al construir y probar software” por @domix
    • “Groovy: el lenguaje dinámico para la JVM” por @neodevelop
    • “Desarrollo políglota en la plataforma Java” por @domix

De cada uno de estos nos hemos llevado muy buenas experiencias, y precisamente esa es una de las tantas cosas que me da el pertenecer a una comunidad como springhispano.org y grails.org.mx: la posibilidad de conocer a más personas interesadas en el uso de tecnologías similares, de darle rostro al timeline, de tener charlas fluidas y amenas, de conocer los intereses e inquietudes de alumnos, maestros, empresarios, desarrolladores…

La comunidad me ha dado conocimiento, ya que cada vez que se realiza una reunión los ponentes despiertan la inquietud del uso de herramientas que no conocía o simplemente había escuchado de ellas…

La comunidad me permite expresarme, exponer mis dudas, tener otro punto de vista diferente, ampliar mi abanico de posibilidades para resolver un problema…

Inclusive, me dió la capacidad de darles a los miembros la posibilidad de asistir a un curso de certificación a través del proyecto #PCJ…

En realidad, hay demasiadas cosas que puedo mencionar que considero aportación mutua; la actividad dentro de las comunidades es algo que me da identidad y que le da un verdadero significado al concepto ‘social’

Espero que al igual que yo, los lectores y desarrolladores encuentren un interés en ser parte de comunidades, y por supuesto, en springhispano.org y grails.org.mx serán siempre bienvenidos…

Fuimos invitamos Jose Juan Reyes y yo a dar unas conferencias, Jose Juan dio un taller de introducción a Groovy, yo por mi parte di una conferencia que desde hace mucho tiempo quería dar, es la primer ocasión que hablo de algo no técnico, fue un poco de reto para mi.

Hable de mi experiencia en la industria, que va desde 1999, cuando aún era estudiante, y empezaba en esto de la programada. Durante estos casi 11 años de trabajo, me ha tocado trabajar en diversos sectores y con muchísimas personas, bastantes experiencias y sobre todo cosas comunes.

La charla me gusto mucho, hable mis expectativas antes de la universidad, como me había ido mientras estudiaba y como me había desenvuelto en la industria. Recibí mucho feeedback por twitter.

Aquí les dejo las laminas, una reseña del Flisol y el audio que alguien amablemente grabo, espero les agrade

SynergyJ como empresa tiene la visión de proveer las buenas practicas en lugar de las mejores practicas. Punto.

No somos gurues, ni pretendemos serlo, estamos 100% conscientes de que todo es relativo y siempre hay requerimientos/experiencia y sobre todo el factor tiempo que alteraran sin contemplación lo que ahora se denominan como Mejores Practicas.

En este momento algo puede ser considerado como una Mejor Practica, pero dentro de algunos años/meses/dias puede cambiar ese estado. Como he mencionado antes, eso lo tenemos sumamente claro.

Por otro lado, es común ver que las empresas que ofrecen algún tipo de servicio, el que sea; siempre dicen dar lo mejor, lo ultimo, lo definitivo, lo “mejor”. Falso. Nadie puede decir eso a ciencia cierta. Son solo frases de mercadotecnia que en realidad engañam para beneficio de la empresa prestadora del servicio.

Nosotros sabemos que tenemos mucho valor como empresa, yo mismo estoy muy contento y seguro que los 4 que formamos SynergyJ somos muy valiosos como personas y sobre todo como profesionales. Somos un grupo excelente.

Mas sin embargo, estoy cayendo en un discurso que puede prestarse a una interpretación que he criticado en párrafos anteriores, que es la de una mercadotecnia basada en el engaño. Pero algo es seguro, en SynergyJ no engañamos, demostramos.

Hay muchas cosas por comentar por aquí, así que pues a darle.