Stress Agile

En los últimos tiempos he visto como algunos miembros de equipos Agiles se expresan negativamente a cerca de las reuniones típicas, como la de iniciación y planificación, reuniones diarías de sincronización de trabajo (Stand Up), revisión final de los incrementos (demo), considerándolas de algún modo una gran pérdida de tiempo y mera actividades modales.
Me he puesto a observar el carácter de estas personas en particular y básicamente ellas tienen un patrón de comportamiento uniforme.
Tienden a evitar discusiones de consenso, expresan su punto de vista con bastante irreflexión y son inflexibles, planifican por su cuenta sin consenso, suelen no abarcar a otros involucrados, evitan la comunicación efectiva cara-a-cara, son en extremos desconfiados, alimentan un estilo de crítica destructiva, son extremadamente detallistas.
Este conjunto de características en definitiva los torna por lo general, en personas de un humor cambiante (bastante acorde al estado de avance de sus actividades), suelen frustrarse si hay una gran incertidumbre, por lo que al principio de cualquier proyecto Agile, sufren por no tener una documentación en extremo detallada, justifican sus retrazos y fallos en la falta de información disponible y evitan reconocer que no se han dedicado a hacer preguntas adecuadas para obtener data.
Técnicamente son personas muy capaces, seguramente lograrán los objetivos, pero se esfuerzan demasiado y sufren el estress de una manera dañina, quizás por que no usan el soporte de otros.
Si les preguntas, se sienten invadidos y suelen confundir reportar con transferir información colaborativamente. También consideran que el término de autogestión se aplica al individuo en lugar de al team.
Bueno, no es de extrañar que haya personas así, cuando en realidad hay toda una cultura educativa y empresaria que las concibe, alimenta y fomenta su existencia profesionalmente.
Lo que si es extraño, es que logren filtrarse en equipos Agiles.

Esto me recuerda que no solo estoy hablando de personas en el área operativa,  sino por supuesto también de quienes son parte de las altas gerencias y es obvio, por que Agile suele causar dolor.

Advertisements

Informática OpenSpace

Algo interesante está ocurriendo en el mundo y es lo que se conoce como “Espacios Abiertos”, donde los profesionales, idóneos o interesados en una temática en particular pueden PARTICIPAR (con todas las letras en mayúscula) en la discución, información, recomendación y conclusión de aspectos y conceptos estratégicos para definir el rumbo de ese asunto.
En Córdoba, Argentina se llevará a cabo en la Universidad Tecnológica Nacional, en el Salón de Actos el miércoles 12 de Noviembre a partir de las 18:30hs, el primer evento con características OpenSpace, dondeen el inicio del evento se plantean las bases del mismo, para que las personas que no conocen o no saben de la modalidad puedan ponerse al tanto.

Luego de 15 minutos introductorios, los asistentes deben dirigirse a un pizarrón, o tablón, que contiene una grilla de vacantes y horarios. O sea, algo similar a esto:

Pizarron

En esa grilla, cada persona asistente puede proponer un tema. Cada tema propuesto compite con otros en el caso de que existan más temas que los horarios y vacantes posibles. Los demás asistentes votan, si así lo desean, por alguno de los temas ya propuestos o simplemente proponen aquellos temas que les interesan.

Al finalizar esa etapa las charlas con mayores votaciones son las que se llevan a cabo.

La idea general es que, en cada charla se colocan 4 sillas. Cada persona que quiere opinar sobre el tema en cuestión debe sentarse en una de las sillas y solo recién emitir su opinión. Siempre debe quedar una silla disponible (para que se siente quien quiere opinar). Si las 4 estuvieran ocupadas, la persona que ya no tiene más que decir, o que ha estado más tiempo, o aquella que simplemente tiene la voluntad de pararse y volver a la “zona” de escuchas lo hace.

Los asistentes pueden ir pasando por diferentes grupos, y no necesariamente deben quedarse en una charla, o en la charla inicialmente elegida. La persona que propuso el tema de la charla es la que inicia la misma, y al mismo tiempo puede o debería, preferentemente, actuar como moderador.

Hay que destacar que no es necesario conocer un tema para proponerlo. Puede, por ejemplo, proponerse un tema del cual una persona quisiera obtener conocimientos ya que es posible que dentro de los asistentes se encuentren personas que sepan del mismo.

En esta oportunidad, cada charla debería tomar alrededor de 45 minutos. Si el mismo se agota antes de tiempo, este se disuelve y las personas pueden ir a observar o participar de otras charlas. Es posible llevar computadoras, y mostrar código y/o presentaciones, bajo la idea de que los asistentes deberán asomarse a la pantalla y tratar de ver algo.

Si se cuenta con algún medio de proyección, también es posible usarlo, aunque esto dependerá directamente de las instalaciones. Que temas tratar: Los temas son de informática, y no necesariamente de código. Tampoco están relacionados a una empresa, industria, propietario o modalidades de distribución. Simplemente es informática. Se podría hablar de generación automática de código, software factories, test unitarios, análisis estático de código, cloud computing, pair programming vs. revisión de código, test automation, herramientas de productividad, estimaciones, secure programming, XSS y SQL injection, domain specific languages, CMMi vs Agile, store procedures vs SQL inline, web client vs smart clients, lenguajes funcionales, hasta XNA o el mercado del desarrollo de juegos, o lo que sea.

Extraído de Preguntale al Experto