Agile pragmático Vs Agile tecnicista

No hace mucho luego de participar de una revisión de un incremento, un Arquitecto manifestó no estar convencido con las estimaciones por Story Points.

Recuerdo, su punto de vista le indicaba que había “descubierto” que podía estimar 50 Puntos de Historia con un equipo experto y tener un Scope realmente desafiante, y un equipo inexperto podría estimar exáctamente los mismo Puntos de Historias pero para un Scope mucho más pobre y esa incongruencia le molestaba. Claro, al final de cuentas lo que importa es cuantas historias por Sprint se finalizan para determinar una velocidad del team.

Allí mimos surgió del Ubber Scrum un análisis que indicó que dado a que tienen enorme cantidades de datos colectados por producto, relacionados con las líneas de código y áreas funcionales modificadas, es posible determinar métricas que indiquen la cantidad de Historias de Usuario y complejidad, desarrollados por Sprint y de ese modo, podrían realizar estimaciones casi de manera automática, es decir a mi entender, prescindiendo del criterio del team o al menos como un fuerte indicador o “driver”.

En mi razonamiento, este enfoque “tecnicista” le quita pragmatismo a cada proyecto y al equipo mismo que disminuye su creatividad, practicidad y pronto el interés en la interacción y así la útilidad del enfoque agilista carecería de espíritu. Por intentar esto, salvaguardar métricas uniformes útiles para todas las “ventanas” de información, me pregunto ¿cuanta interacción estamos dispuesto a relegar?.

Para el ejemplo particular que mencioné antes, creo que con solo medir el valor entregado al cliente, sabrás que tan importante es el trabajo realizado del equipo y con solo este criterio en mente, ¿que importancia puede tener si el equipo A (experto) estimó 50 puntos de historia para algo muy complejo y el equipo B (inexperto) estimó 50 puntos de historias para algo menos complejo?.

Yo mismo he vivio que a la Historia de Usuario más compleja, la hemos tenido que dejar de lado por la historia más sencilla de todas por que de pronto en medio del Sprint, pasó a ser la de mayor valor para nuestro PO.

Un caso típico es cuando los comerciales “enganchan” un nuevo cliente y en cuestión de días deben mostrarle el producto y no podrían mostrar el módulo de reportes si no se modifica el “branding” (headers & footers) que aún menciona al producto con la antigua denominación del proveedor anterior.

  • Entonces, agilizar una organización es algo más que solo agrupar los equipos de una determinada manera para que todos juntos ejecuten sus tareas. En su lugar regáleles principios y valores, donde la confianza y la cooperación primen.
  • Agilizar, nada tiene que ver con permitir que subsista la antigua cultura de aislamiento y comunicación esporádica entre individuos. En su lugar promueva una conversación constante sobre los tópicos del negocio, cara a cara y en una misma jerarquía. Lo que uno no puede, varios podrán.
  • Agilizar una organización es mucho más que brindarles recetas bien acomodadas para que las Historias sean rastreables con requerimientos técnicos, diseños de arquitectura, componentes y funciones. En su lugar ayúdales a conocer la importancia que las historias tienen para representar las necesidades de negocio que el cliente tiene y ayúdales a encontrar una relación con las tareas técnicas sin que ello implique sumergerse en “enfoques tecnicistas”.
  • Agilizar, es mejor que solo permitirle a los equipos realizar estimaciones por puntos para que finalmente éstas deban rigurosamente, ser congruentes con cantidad de horas por tareas y para el colmo, uniformes a lo largo de todos los equipos de la organización. En su lugar permite que todos sientan orgullo por sus estimaciones y permite que ellos las expongan sus avances con monitores omnipresentes.
  • Agilizar es más que ofrecerle a los equipos, un juego de herramientas ostentosas que soporten extensas WBS trackeables (auditables) desde todos los niveles. En su lugar, permítale a su equipo colaborar en cada tarea que vaya surgiendo sin tener que anticipar el detalle de su existencia, tal vez las estimaciones por puntos en las historias ya es suficiente como para también tener que estimar horas por tareas.

Desde que conocí el agilismo, entendí que cuando más fractales son los equipos, más cohesivo es el funcionamiento orgánico y más flexible, capáz de adaptarse a los cambios.

La cuestión natural en Agile es que los equipos deben ser permanentes y ganar experiencia en cada proyecto, mejorar en cada proyecto, optimizarse en cada proyectos. Por otro lado, el problema natural es que cuando los equipos no adoptaron los principios, aún comprendiendo las prácticas, es muy fácil que cualquier opinión contrarie y debilite el verdadero sentido y utilidad de éstas prácticas.

Advertisements

Cambiar o morir

La encargada de limpieza en las oficinas de una Software Factory puso carteles en el baño y en la cocina, llamando a la colaboración para mantener el orden y la limpieza. El resultado directo fue el enojo y reacción de las personas, los comentarios por lo bajo y los email masivos mostrando el descontento de quienes se vieron afectados por las notas.
Del mismo modo sucede cuando se envía una circular indicando la necesidad de mejoras en los comentarios de códigos, cuando se levantan “no conformidades” en revisiones de especificaciones del software, o documentación de arquitectura y diseño, cuando se pide aumento de detalle o modificaciones drásticas o simples en las definiciones de los Casos de Usos o User Story, cuando se pide ampliación de pruebas unitarias para garantizar la construcción, cuando se pide limpieza en la utilización de juegos de datos en pruebas de integración para garantizar la reutilización del ambiente, cuando se pide modificar o aumentar caminos de pruebas para mejorar la cobertura de las pruebas de sistemas, cuando se solicita la involucración temprana de los líderes de proyecto para hacer seguimiento de los proyectos, cuando se piden planes de despliegue que incluyan pruebas de campo, o inclusive cuando se pide considerar incluir estimación de riesgos, análisis post mortem, lecciones aprendidas, repositorio de clases, comentarios en actualizaciones del repositorio o se introduce y notifica cualquier modificación en el proceso, aún luego de haberse convenido tales cambios.

¿Será que nuestra naturaleza no nos permite ser reflexivos y por el contrario somo fuertemente reactivos a cualquier situación que indique que debemos cambiar y modificar nuestras actitudes más íntimas?

¿ Será que no nos damos cuenta que hasta para las cosas más simple es mejor cambiar para vivir y convivir?

Quizás debamos ser drásticos e interpretar que debemos “Cambiar o Morir”.

Agile. La evolución de las metodologías tradicionales?

“Agile se ha vuelto tan popular entre los profesionales del software, que muchos se abstienen de criticarlo por miedo a ser etiquetados como “retrazados”, “de la vieja escuela”, o incluso “estúpido”.
Afortunadamente los profesionales IT con experiencia saben mejor y reconocen las limitaciones de Agile”

Así rezan las las declaraciones en un blog de Project Management, bastante conocido TheProjectManagmenteHut

Agile fue creado en gran parte en reacción al modelo predominante, WATERFALL, y en menor medida al resto de las tradicionales metodologías y aunque está en boca de todos y en manos de muchos, Agile hasta el día de hoy no ha demostrado ser superior a estas metodologías que le dieron razón y motivo para su existencia.
De hecho existe amplia y variada información que puede avalar tanto el éxito como el fracaso de las metodologías tradicionales, más su acoplamiento con los modelos y estándares de calidad reconocidos mundialmente y las culturas organizacionales más importantes del mundo, inclusive hablando de la industria del software.

Aunque no prentendo ser defensor de lo indefendible, ni “abogado del diablo” de Agile, es conveniente hacernos las siguientes preguntas:

  • cuando Agile es comparable con metodologías tradicionales?
  • cómo podemos combinar Agile con procesos tradicionales para abordar mejor una situación concreta?

Para responder a estas preguntas, es mejor reconocer las limitaciones de Agile

Un equipo de estrellas

Agile ha sido diseñado por experimentados y para experimentados.
Este es un aspecto a considerarse si se ha de intentar una incursión en las metodologías Agile, no como regla general, sino como un ítem de peso, sobre todo si se debe sostener el concepto de “equipo autogestionado”.

En lo personal y por la experiencia de participación en equipos Waterfall y en equipos en búsqueda de la agilidad, puedo decir que es mucho más dificil adaptarse a procesos Agile que a los procesos Waterfall, inclusive si se sigue un modelo de calidad como CMMI.

En los procesos Waterfall, el atributo de “equipos autogestionado” no es remarcable y aunque puede existir mucho trabajo individual, se hace bajo las premisas estrictas de la planificación, siguiendo los métodos y técnicas sugeridas y aceptadas por la organización. No se hace de otro modo o no lo estarías haciendo correctamente.

En estos procesos tradicionales, es cierto que existe también una gran carga administrativa pero en realidad no todos están afectados por ella y solo lleva una porción pequeña de tiempo y a muy baja complejidad realizarlas, principalmente para quienes no lideran los proyectos y solo rinden su progreso del día.

En los equipos Ágile, es un tanto más complicado la adaptación de las personas, siempre hablando de aquellas que no tienen la experiencia suficiente y el tren de trabajo disciplinado sin controles estrictos.
Aquí las entradas de algunos son fuertemente dependiente de las salidas de otros, no existe un trabajo individual o “individualista”, o no debería existir.

Las técnicas de gestión de tareas tradicionales pueden perder por completo su sentido y también debe existir una readaptación del mecanismo de estimación, de equilibrio de carga y del seguimiento. Los controles aunque parecieran ser menores, en realidad se incrementan por que el ciclo de vida en si mismo es mucho más corto y los cambios se presentan con mayor velocidad, pero parecieran ser de otra naturaleza y los resultados deben ser inmediatos, como también deben ser inmediatas las correcciones y a gran velocidad para que en la misma jornada laboral se tenga una aproximación del resultado, cuando no el resultado en si mismo.

El cáos está siempre al acecho…pero en que proyecto no lo está? La diferencia es la velocidad de detección de los inconvenientes, el análisis del problema y las soluciones, más su implementación, verificación y/o validación.
Entonces, preguntas simples pueden ser:

  • Tiene tu equipo el potencial para Agile?
  • Tienes el potencial para Agile?
  • Tienes la materia prima en las personas, para formar un equipo Agile?

Si la respuesta es “no” a algunas de estas preguntas, no significa que no puede transformase en Agile, solo quiere decir que puede haber algunos pasos intermedios a tomar antes de llegar allí.

Estos pasos suelen incluir la adaptación de la cultura del trabajo por equipos y la progresiva potenciación de los individuos, la formación y la contratación de las personas adecuadas.

Encaje con la cultura organizacional (los procesos son secundarios a la gente)

Habilitar el comportamiento Agile requiere de una gran dosis de libertad individual (no individualismo) y de equipo, que se traduce en una cruz funcional en constante adaptación del trabajo y funciones de conmutación, según sea necesario.

Se trata también de ajustar continuamente los procesos a fin de reflejar la situación actual. Más que nada, significa que los procesos son secundarios a la gente.

Otras organizaciones hacen incapié con estrechéz en los roles y responsabilidades, políticas y procesos, y han sido la clave de la supervivencia las mismas.

Aunque estas empresas estén bastante alejada de las dogmas de la agilidad, no es imposible que algunas unidades puedan realizar un trabajo diferenciado para experimentar, conocer y adaptar el nuevo paradigma.

Dado que la innovación es parte de la cultura de cualquier organización exitosa, entonces las personas que la integran tienen buenas habilidades y potencial para realizar “adaptaciones situacionales” y saltar de un modelo a otro.

Agile está restringido a equipos pequeños

  • Los equipos deben ser autogestionados, lo cual implica un orden eficiente emergente de un caos temporal. Este tipo de adopción del orden será mucho más prolongado en equipos grandes y perdería efectividad.
  • Los miembros del equipo de trabajo deben estar habilitados para comunicarse entre ellos espontáneamente, e inclusive con clientes y otros interesados en los proyectos.
  • La gestión diaria del equipo depende por completo de todo el equipo y no está centralizada en una sola persona. Es necesario el reconocimiento y visualización por parte de todo los miembros del equipo, de los cronogramas, tareas, cambios, impedimentos, etc.
  • Los miembros del equipo deben conocer exactamente que es lo que otros miembros están realizando, ayudar a otros que el proceso de su trabajo sea fácil, en forma colaborativa y sin un control centralizado.
  • Los miembros del equipo deben trabajar en la misma locación, facilitando el trabajo cara-a-cara y fortaleciendo los canales de comunicación inmediatos, sin tener las limitaciones típicas de las distancias, diferentes horarios e inclusive herramientas de gestión.

    Lo que se quiere expresar con estos puntos, es que equipos que superan un cierto límite en el número de integrantes (típicamente ocho) pierden eficiencia en las habilidades comunicacionales requeridas para equipos Agile. Así mismo la tarea de un Scrum Marster, se vería dificultada si tuviera que gestionar tareas, avances e inconvenientes de más cantidad de miembros y otros atributos como conocer las tareas y actividades entre todos los miembros se verían cada vez más en merma.

    Una forma de adaptación de equipos mucho más grandes, sería la división del mismo en equipos cross-funcionales más chicos y dinámicos.

    En este sentido necesariamente se deberá contar con un “nivel de gestión superior” que permita centralizar la información de todo el proyecto. Sin duda esto está lejos de ser puramente Agile, sino más bien una combinación de metodologías tradiciones y agilísmo.

    Hay que tener en cuenta también que si se divide un proyecto grande, se minimiza la dependencia arquitectónica del proyecto, para pasar de una medición del avance típicamente medido por su avances arquitectónicos, a una medición basada en la entrega de características funcionales. Esto da como resultado que la definición de “progreso” de Agile, deba ser adaptada a un nuevo contexto con un nivel de gestión superior.
    De nuevo la adaptación situacional “es un buen jugador”.

    Una gran limitación tiene que ver justamente con el especto comunicacional, dado que Agile promueve la comunicación cara-a-cara, con resoluciones dinámicas y proactivas, sin documentación más que la que oriente al desarrollo.

    El trámite comunicacional con otrás áreas es un trastorno que Agile debe aprender a dominar, puesto a que los modelos agilístas actuales exigen que otros interesados del proyecto deban siempre estar en la misma locación de trabajo, inclusive evitandose el traslado desde una oficina a otra para realizar simples consultas.

    La tecnología colaborativa y de multimedios, permiten actualmente realizar trabajos perfectamente coordinados y con esquemas de reuniones cara-a-cara, aunque virtualizadas, muy eficientes. Sin embargo esto no está bien aceptado en el mundo actual del agilísmo.

    Donde está mi metodología?

    Metodologías de desarrollo de software, tradicionalmente incluyen procesos como, Análisis, Arquitectura, Implementación, Gestión de Proyecto, Gestión de la Configuración, Gestión de Riesgos, Gestión de Cambios y una larga lista de procesos dependientes de Áreas de Procesos y Grupos de Procesos. Sin embargo, las metodologías

    Agile no promueven estos grupos de procesos y de hecho no los definen para sus marcos de trabajo, como tampoco definen un marco de gestión de proyectos.

    Esto puede verse justificado por el hecho de que las metodologías Agile tienen como insignia, que lo que demuestra y garantiza el proceso es el producto entregado y no la documentación que puedas presentarle a tu cliente.

    Las metodologías Agile delinean un marco conceptual, pero no explicitan de ninguna manera la exclusión de alguna de las prácticas tradicionales, aunque se asume que solo sobrevivirá lo estrictamente necesario para la obtención de los incrementos (entregables de software)

    Metodologías Agile completas parecen estar emergiendo y el soporte a la organización podrías ser total con adaptaciones sencillas de ambos metodologías, donde la substracción de las buenas prácticas de ambas, de como resultado el éxito y calidad total de la organización.

    Dado el contexto planteado es que me hago las siguientes preguntas para reflexionar:

    • ¿Existe la evolución de las metodologías Agiles?
    • ¿Surgieron por si solas o son adquiridas y formadas en reacción a la complejidad propuesta por las metodologías tradicionales?
    • ¿Las metodologías Agiles de alguna nueva generación no serán en si mismas las adaptaciones y evoluciones de metodologías tradicionales?

    LOGS de errores reflejan el funcionamiento del nucleo de nuestras aplicaciones

    Algunas estrategias de detección de errores en nuestras aplicaciones pueden parecer demasiado sencillas o desactualizadas, sobre todo con el auge y advenimiento de herramientas potentes, con cientos de reportes, gráficas y métricas para analizar.

    Sin embargo prácticamente ninguna herramienta permite a desarrolladores, analistas funcionales y testers de aplicaciones, reconocer la causa raíz de los problemas que aquejan a nuestros desarrollos.

    Una técnica sencilla y pronta a aplicar, es la generación de logs de errores en formato TXT. A partir de allí mejorar el proceso de construcción en base a información obtenida del núcleo de funcionamiento de nuestras aplicaciones, es cuestión de solo dejar volar la imaginación.

    Aunque un conjunto de nuevas herramientas podrían ser la solución para el ahorro de tiempo y dinero en la resolución de defectos, estas herramientas principalmente deben tener la capacidad de generar reportes que permitan aislar los problemas raíces, haciendo mucho más sencillo el diagnóstico y resolución, sin tener que invertir en costosos ambientes de aislamiento ni tiempos de reproducción.

    Estas soluciones no están del todo presente en las actuales herramientas disponibles, ni diseñadas para el comportamiento dinámico de los defectos y solo se permite un análisis estático basado en la mayoría de los casos, en pruebas orientadas de “caja negra”.

    Pero tal vez la productividad se vería acelerada exponencialmente si no solo pudiéramos introducir herramientas con estas características dinámicas, sino que a su vez tuviéramos la capacidad de darle a nuestras aplicaciones la capacidad de resguardo y notificación de errores.

    Desde el análisis y diseño y bajo un planteo de pruebas que orienten la construcción de los componentes, es posible introducir ciertos niveles de detalles que serían plasmados en “logs de errores”, los cuales pudieran ser de gran utilidad para el diagnóstico de problemas raíces y resolución temprana, es decir en fases de pruebas tempranas.

    Al finalizar cada ciclo de prueba, testers y desarrolladores pueden interactuar con mejor foco en las causas raíces de los bugs, errores de construcción e inclusive errores de interpretación de requisitos o detección de requisitos mal formados.

    La verdadera potencia de tales “logs de errores” se manifestarán solo si esta solución es diseñada y aplicada en forma armonizadas para que no se entorpezca el trabajo y los resultados sean positivos y bien significativos.

    Un beneficio central es que los “tiempo ventana” demasiados cortos para la resolución de defectos, sean mejor aprovechados y el proceso se optimice significativamente.

    Hay quienes opinan que se deben modificar significativamente los requerimientos para incorporar estos elementos a los procesos de desarrollo, pero yo creo que el esfuerzo no es tan grande como para evitarlo y los beneficios son tremendos como para dejar de hacerlo.

    No piensen en tecnificar demasiado ni en agregar complejidad, orienten esta solución a la simplicidad y facilidad de lectura y comprensión y bastará con utilizar un notepad o archivo tabulado para comenzar a obtener resultados que mejoren la visibilidad del comportamiento erróneo de nuestras aplicaciones.

    Potenciar la solución  es cuestión de imaginación.

    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

    OpenSpace

    Durante los últimos 15 años, claramente se ha ido percibiendo como el Espacio Abierto puede crear organizaciones inspiradas, donde personas normales trabajan juntas para crear resultados extraordinarios con regularidad.

    face to face meeting

    ¿Qué es?

    La Tecnología de Espacio Abierto es una forma de permitir a toda clase de personas, en cualquier tipo de organización, crear reuniones y eventos que inspiran.

    En reuniones, eventos y organizaciones, de Espacio Abierto, los participantes crean y manejan su propia agenda, de trabajos y sesiones simultáneas, en torno a un tema principal de relevancia estratégica, tal como: ¿Cuál es la estrategia, el grupo, la organización o la comunidad que los “stakeholders” pueden apoyar y trabajar en conjunto, para crear?
    El resultado es poderoso y efectivo a la hora de implementarlo y ayuda a apoyar lo que ya está sucediendo en la organización, no sólo planeando sino actuando, aprendiendo y enseñando, con pasión y responsabilidad, siendo no sólo participantes sino ejecutores.

    ¿Cuándo y Por Qué?

    El Espacio Abierto funciona mejor cuando el trabajo que se debe realizar es complicado, las personas y las ideas que están involucradas son diversas, la pasión por resolverlo (y potencial para conflictos) es enorme, y el tiempo para realizarlo “era ayer”.

    Es llamado “pasión limitada por la responsabilidad”, “la energía de un buen coffee break”, “auto-organización intencional”, “espíritu en el trabajo”, “caos y creatividad”, “evolución en la organización”, y una forma poderosa y sencilla de hacer a las personas y a las organizaciones moverse cuando y donde es más necesario.

    Y mientras que el Espacio Abierto es conocido por su falta de estructuración y abierto a sorpresas, resulta ser que los eventos u organizaciones de Espacio Abierto son, de hecho, muy estructuradas, pero esa estructura es tan perfectamente diseñada para las personas y para el trabajo diario, que pasa desapercibida en sus roles de dar apoyo (no obstaculizar) a un trabajo mejor realizado.

    Aún más, las historias y trabajos que se realizaron en Espacio Abierto son generalmente más complejos, más fuertes, más duraderos, y se pueden mover de manera más rápida y ágil que trabajos realizados por expertos o bajo los diseños administrativos convencionales.

    .

    ¿Cómo se estructura?

    Cuando se abre un Espacio Abierto para un grupo de personas, para que realicen su trabajo más importante, se debe garantizar estos resultados:

    1. Todos los puntos considerados como los MÁS importantes para los participantes, serán tratados;

    2. Todos los puntos que surjan serán sugeridos por los participantes más calificados y capaces de lograr algo en cada uno de esos puntos;

    3. En un período tan corto como uno o dos días, todas las ideas, discusiones, informaciones, recomendaciones, conclusiones, preguntas para discutir y planeamientos más importantes, serán documentados en un reporte muy fácil de entender, impreso y entregado en las manos de los participantes en el preciso momento que ellos se marchan;

    4. Cuando el momento sea apropiado para esto, el contenido de este reporte puede priorizarse en pocas horas, aunque se esté trabajando con grupos grandes (100);

    5. Después de un evento, todos estos resultados pueden ponerse a disposición de toda la organización o toda la comunidad, sin necesidad de realizar el evento, ya que conversando se puede invitar a los “stakeholders” en la implementación, justo en el mismo momento;

    6. Y resultados como estos pueden ser planeados e implementados más rápido que cualquier otro tipo de “intervención para grupos grandes”. Es literalmente posible obtener en días y semanas lo que cualquier otro tipo de técnica dura meses y años.

    Las buenas y malas noticias es lo que funciona. Buenas noticias porque hace que las personas y el trabajo se muevan, malas noticias porque puede significar que muchas cosas pueden llegar a cambiar. Cosas que uno desea, aparecerán y cosas que uno no desea, desaparecerán, y en algunas ocasiones vice-versa-pero así es como la vida funciona. En resumen, el Espacio Abierto trae vida a la organización y trae a las organizaciones de vuelta a la vida.

    Estráido de OpenSpaceWork

    TALENTO E INDIVIDUALIDAD O LIDERAZGO Y TRABAJO EN EQUIPO?

    En las puntas de sus dedos vive la magia, en cada segmento de sus manos hay sinergia mental y espiritual, en los movimientos de sus cuerpos está la más sublime expresión de sincronización de talento y esfuerzo fluyendo entre notas de una música que muta en los límites de dioses y serés paganos.
    Compenetrados en sus roles cada uno ejecuta con cuidado su parte atómica “preparando la exploción” que inicia con sigilo. Lentamente desde sus inicios devora todo lo que existe en el ambiente.
    Elige su objetivo y nuevas explosiones de sintonía dan cabida al caos plenamente organizado en elementos que viajan raudos hacia un fin único.
    Mareados presenciamos poco a poco la entrega mágica que se eterniza y se recicla en nuestra percepción.
    El ambiente se sostiene mientras Dios habla con nosotros. Los maestros no se abandonan y cada uno sostiene al otro. El conjunto es perfecto, con imperceptibles señales ensayadas cientos de veces. No hay salidas imperfectas y el final es algo que se orquesta desde un principio.

    Dios hace su aparición y perdura para siempre.