Equilibrio entre el integrante y el equipo.

En los equipos de trabajo, el equilibrio entre el integrante y el equipo es como el equilibrio entre el árbol y el bosque. No hay bosque sin árboles y un árbol solo no es bosque. En un equipo de trabajo se da el dilema de pertenecer o ser alguien y de eso quería escribir algunas líneas.

Al ser parte de un equipo, algo de la independencia de cada integrante va a ser sacrificada; sino, no hay equipo.

Por ejemplo, si la mayor parte del tiempo (por ejemplo alrededor de un 80 %) la persona trata de cuidar sus propios intereses y formar su propia identidad, como una asociada a un prestigio o alguna característica sobresaliente o notoria, significa que la persona trata de no estar en el equipo. Y en el caso contrario en que este mayor parte del tiempo tratando de integrarse al equipo (o haciéndolo), significa que no le importan sus intereses individuales y preservar una identidad propia.

O sea que los integrantes viven un conflicto legítimo entre dos objetivos: “pertenecer” y al mismo tiempo “ser alguien”, o en forma inversa “ser alguien” y al mismo tiempo “pertenecer”. Estos objetivos son lógicos y se complementan si están equilibrados, sino uno predomina sobre el otro y dependiendo de la inclinación de la balanza se podrá ver más favorecido el individuo o el equipo.

Por ejemplo, para “ser alguien” (identidad individual) el integrante puede busca apuntar a lo que esta mal en otros o en las cosas y hacerse notar como que él es quien descubrió el problema o la solución; o que por él funciona el equipo y trata de ser un líder dominante. Puede ser alguien que tira una primicia problemática en una reunión sin ningún aviso a responsables para prevenir y así poder figurar. Puede buscar sobresalir por aptitudes y talento propio o usando los de otros. Puede entrar a una red de favores (interno o externos al equipo) para satisfacer intereses de progreso personal (como ascensos o mayor salario). Hay personas que son hábiles en hacerse notar y en lograr ubicarse en el podio junto a los laureles. Esas personas buscan (consciente o inconscientemente)  “ser alguien” y predomina su individualismo. En organizaciones donde se fomenta la competencia y el individualismo, el buscar “ser alguien” es ventajoso para las personas que “son alguien”, pero poco beneficioso para los equipos.

Por otra parte, para “pertenecer” integrado a la identidad del equipo, las posibles tácticas o comportamientos no son las de lucirse, sino la de buscar soluciones a los problemas al margen del crédito que se reciban por ellas. Con este foco se busca estar orientado a las soluciones, al producto y al equipo. En un caso extremo, es quien arregla los problemas sin que lleguen a serlo y sin que nadie se de cuenta de que él es quien los arregló o quien propulsó de alguna manera a su solución. También puede ser una persona que da mucho soporte al equipo y su soporte a veces no es notorio pero si muy útil. No siempre el que más sobresale o quiere sobresalir es el que más aporta al equipo. Y en organizaciones donde se fomenta la cooperación y el trabajo en equipo, el buscar “ser alguien” es perjudicial y el “pertenecer” beneficioso para todos, valioso para los equipos.

Pienso que lo mejor para el trabajo en equipo es el punto medio, logrando un equilibrio entre ambos objetivos; o en todo caso, que prevalezca el “pertenecer” en los integrantes porque potencia al equipo, porque:

“Un equipo es más que la suma de sus integrantes”.

En cambio, cuando se estimula el individualismo, la competencia, el foco en el liderazgo, las “promociones por logros individuales” (ya sea por sistemas de desempeño laboral, sistema de promociones o marketing cultural interno de la org.) y la “tendencia a rotación del personal”, se perjudica la cultura de “trabajo en equipo” y la colaboración que ella necesita. El individualismo atenta contra la identidad de los equipos y su cohesión. La competencia socava el trabajo colaborativo. El foco fuerte en el liderazgo transforma a los “equipos de trabajo” en “grupos de personas conducidas por lideres”. Y las “promociones por logros individuales” fomenta el individualismo, que a su vez genera competencia, y los que sobresalen en ella pujan por ser lideres (y muchos lo logran sin serlo) o por irse cuando no se sienten satisfechos o beneficiados en la org., llevando la organización a grupos de personas ordenadas jerárquicamente-piramidal y dirigida por lideres. Para crear, mantener y desarrollar condiciones organizacionales orientadas a trabajo en equipo es principal abandonar el paradigma sectorial e individualista y tomar uno colaborativo.

El desarrollo ágil (y su manifiesto) hace hincapié en la comunicación entre integrantes del equipo y la comunicación con el cliente en “ambientes colaborativos”. En este sentido cabe recordar las siguientes frases:

“El desarrollo de software no es solo una tarea intelectual. Más bien, es una tarea colaborativa, social que requiere mucho de comunicación.”
………………….(Pete McBreen, Software Craftsmanship)
“Los proyectos dependen de individuos talentosos y sus interacciones en vez de prescripciones de actividades y artefactos con documentación precisa.”
………………….(Highsmith 2000b).
“La colaboración implica participación unida en producir un producto, o conjuntamente tomar una decisión —es la participación activa en vez del intercambio pasivo.”
………………….(Jim Highsmith, Agile Software Development Ecosystems, 2002)
“los procesos son tan buenos como las personas que los realizan. Las personas calificadas operando en un marco de trabajo colaborativo efectivo es el factor crítico de éxito; El proceso sólo puede ser un soporte.”
………………….(Jim Highsmith, Agile Software Development Ecosystems, 2002)
“Creemos que el equipo verdaderamente comprometido es la prestancia más  productiva…”
………………….(Jon Katzenbach and Douglas Smith in their popular book The Wisdom of Teams,1993)

Todas estas sentencias son políticamente correctas para cualquier grupo de trabajo, sin la necesaria injerencia de metodologías ágiles. O sea que, puede ser totalmente demagógico el enunciarlas como condición única y necesaria de colaboración. Entonces ¿Cuál es la diferencia con otras metodologías? ¿En que radica más concretamente la colaboración? Pues, pienso que la colaboración radica en las “organizaciones abiertas”, donde existe el “aprendizaje abierto” y el “conocimiento abierto”. Para trabajar en forma “colaborativa” es necesario abrir los procesos cerrados.

Recordemos las siguientes frases:

“…si tú tienes una idea y yo tengo una idea e intercambiamos ideas, entonces ambos tenemos dos ideas”
………………….(Gerorges Bernard Shaw)
______________[…en este caso pienso que tenemos más que dos ideas.]
“Enseñanza Flexible, Aprendizaje Abierto. Las redes como herramientas para la formación” ………………….(Jesús Salinas)
“Cuesta demasiado diseñar productos a partir de grupos cerrados. La mayoría de las veces la gente no sabe lo que quiere hasta que se lo enseñas.”
………………….(Steve Jobs, Presidente de Mac)

Pienso que, la Filosofía Ágil Colaborativa en las organizaciones se refiere a modelos y filosofías organizativas centradas en los integrantes en contra de la centrada en las instituciones o líderes. La colaboración implica participación de todos en el control sobre los contenidos y sobre las estructuras; y en la elección del sistema de distribución de información. La colaboración necesita de la accesibilidad a la información y de la flexibilidad de los procesos. Para todo ésto es necesario procesos abiertos con aprendizaje y conocimiento compartido.
Cuanto se esté dispuesto a abrir a las organizaciones y el conocimiento depende de decisiones de negocio, de la filosofía personal en este sentido, de factores de seguridad, etcétera.

El método y proceso de desarrollo “OpenUp” es un ejemplo de metodología ágil con un grado grande de apertura. Los procesos y productos “Open source”, la filosofía “Free Software” y el tipo patentamiento “copyleft” también son ejemplos de “colaboratividad” con apertura amplia. Cada organización decide el grado y alcance de apertura, pero la colaboración no se puede dar en organizaciones y procesos cerrados.

Referencias:
-Jim Highsmith, Agile Software Development Ecosystems, 2002.
-EDUTEC, revista electronica de tecnologia educativa – enseñanza flexible, aprendizaje abierto.

En relación a la organización y al trabajo en equipo las metodologías ágiles permiten lograr el aumento del potencial sinérgico de los equipos de trabajo, la disminución del grado de imprescindibilidad de las personas individualmente, el opacamiento del heroísmo profesional, el fortalecimiento del sistema de trabajo y de la organización en conjunto. En este sentido Deming dice lo siguiente:

“Lo que tenemos que hacer es aprender a trabajar en el sistema, por lo que me refiero a que todo el mundo, todos los equipos, cada plataforma, cada división, cada componente no existe para el beneficio individual o el reconocimiento de la competencia individual, sino por su contribución al sistema en su conjunto sobre una base de ganar-ganar.” (W. Edwards Deming) [1]

O sea que, al usar metodologías ágiles no solo es necesario el uso de herramientas conceptuales de sistemas y pensar sistémicamente sino que además se es parte de un equipo de trabajo que busca ser un sistema de trabajo inteligente, consistente y sostenible como un todo.

REFERENCIAS:
<-Entrada anterior: Metodologías ágiles (2), Filosofía Ágil Empírica.
[1]-DEAN LEFFINGWELL, Agile Software Requirements, Lean Requirements Practices for teams, Programs, and the enterprise.
[2]-CRAIG LARMAN, BAS VODDE, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum.
[3]- Martin Fowler, La Nueva Metodología.
PALABRAS CLAVE: Procesos de Software, Metodologías Ágiles, Desarrollo ágil.

Las Metodologías ágiles deberían desarrollarse en un marco empírico-objetivo[4]*. Si bien algunos métodos particulares de desarrollo ágil extremos ponen excesivo énfasis en la comunicación “cara a cara”, en los resultados inmediatos más que en la generación de documentación y en procesos prácticamente sin herramientas, en general el desarrollo ágil se basa en un conjunto de valores que apoyan y alientan a la metodología ágil basada en herramientas y procesos de ingeniería concretos. En este sentido, podemos leer en el Manifiesto ágil dos valores importantes:

A) “El desarrollo de software debe realizarse basado en lo funcional mas que sobre una documentación excesiva”. [2]
B) “El desarrollo de software debe focalizarse en las interacciones de los individuos más que en procesos y herramientas”. [2]

Aunque a veces se niegue, la práctica de estos dos valores forma una base empírica de trabajo. Una mala interpretación es suponer que no se debe documentar ni usar herramientas y procesos. El desarrollo ágil se lleva a cabo en base de procesos de ingeniería con métodos científicos. Por ejemplo, usar metodologías ágiles no significa dejar de hacer “Ingeniería de Requerimientos” como creen algunos, sino que la “Ingeniería de Requerimientos” se realiza dentro de procesos ágiles. Algunas organizaciones tienden a prestar mucha importancia y recursos a los procesos formales y a las áreas de la organización de soporte en vez de a los procesos ejes, los procesos de producción. También existe una tendencia a la complicación burocrática y excesiva documentación. De esto es de lo que se quiere desenfocar el desarrollo ágil. Pero, si bien se valoran las prácticas cara a cara y se tratan de evadir las prácticas burocráticas siempre se debe tratar de trabajar sobre una base empírica dada por herramientas de software, conceptuales y metodológicas, ya sean de de administración, documentación, diagramación, gestión de contenidos, evidencia, seguimiento, etcétera.

Por ejemplo, la diagramación es una herramienta metodológica fundamental del proceder empírico en la filosofía Ágil. Los diagramas habitualmente usados en la ingeniería de sistemas son: diagramas de flujo, diagramas de ciclos causales, mapas mentales, diagramas conceptuales, diagramas UML, etcétera. ¿Para qué sirven los diagramas? La diagramación es una herramienta del proceder empírico por lo siguiente:

“El principal valor de los diagramas es en el debate mientras diagramamos –modelamos para mantener una conversación. (…) el valor principal es la conversación y la comprensión compartida al crear el modelo. Su visualización como un diagrama fácil de ver es importante para hacer concretas y sin ambigüedades a las ideas, los modelos mentales de las personas, porque las palabras solas pueden ser borrosas y mal entendidas.” (CRAIG LARMAN, BAS VODDE) [1]

En resumen, usar metodologías ágiles no significa el desorden y la subjetividad, sino mas bien otra forma de ser empírico. Se es empírico cuando se privilegia mas la evidencia empírica, lo real objetivo, el consenso concreto asentado en un medio físico, lo que sucede, el producto funcional en vez del sentido común, la subjetividad racional, la especulación de un desarrollador, un líder o una persona particular, el protocolo, una estimación subjetiva, la redundancia explicativa y los subproductos o subprocesos estériles.

REFERENCIAS:
<- Entrada anterior: “Metodologías ágiles (1), Filosofía Ágil“.
[1]- CRAIG LARMAN, BAS VODDE, Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum.
[2]- DEAN LEFFINGWELL, Agile Software Requirements, Lean Requirements Practices for teams, Programs, and the enterprise.
[3]- Martin Fowler, La Nueva Metodología.
[4]* Cuando me refiero a empírico-objetivo estoy indicando que se prepondera a los hechos como hechos empíricos, independientemente de las subjetividades, pasiones, sentimientos, deseos, esperanzas o miedos de las personas.
PALABRAS CLAVE: Procesos de Software, Metodologías Ágiles, Desarrollo ágil.

Introducción

El “desarrollo ágil” de software es un marco de trabajo conceptual de la “Ingeniería de software” comúnmente llamado “metodología ágil” y promovido por la organización sin fines de lucro llamada “alianza ágil”. Las “metodologías ágiles” promueven el desarrollo de proyectos y su gestión en procesos con ciclos de lapsos cortos de tiempo y por organizaciones mas flexibles y adaptables que permitan incorporar cambios con rapidez y en cualquier fase del proyecto. También abogan para lograr mayor fluidez con los clientes en cuanto a negociación, requerimientos y entregables. Este marco de trabajo lleva a la des-jerarquización piramidal de las organizaciones conformando organizaciones distribuidas en equipos poco numerosos y con pocas jerarquías.

El Justo medio del desarrollo ágil

El desarrollo ágil se encuentra entre “codificar y corregir sin proceso definido” de una forma caótica- artesanal o “seguir estructuradamente (a rajatabla) un proceso monumental formal, definido y disciplinado por estrictas metodologías que es impuesto organizacionalmente” de una forma mecánico-industrial. En vez de “no seguir procesos definidos” en un extremo y de “regirse por procesos impuestos y poco flexibles” de planificación predictiva y detallada a largo plazo, se opta por aceptar procesos adaptativos de planificación a corto plazo, sin excesivo detalle. Este es el justo medio de las metodologías ágiles.

La Filosofía Ágil

En los siguientes apartados no voy a hablar de cuestiones exclusivamente técnicas, que abundan en libros, sino que me centraré en el espíritu del desarrollo ágil o lo que se puede percibir como la filosofía de las metodologías ágiles. Hay quienes son adeptos de este tipo de metodologías por su sentido práctico, su utilidad y hasta por moda y otros que se comprometen con esta forma de trabajo porque están de acuerdo con su filosofía. Pero ¿Cuál es la filosofía del desarrollo ágil? Considero que el núcleo de la filosofía de las metodologías Ágiles es un núcleo empírico, sistémico, emergentista y colaborativo. En siguientes entradas comentaré el significado esencial de estas partes de la filosofía ágil en el siguiente orden:
- Filosofía Ágil Empírica.
- Filosofía Ágil Sistémica.
- Filosofía Ágil Emergentista.
- Filosofía Ágil Colaborativa.

REFERENCIAS:
- Martin Fowler, La Nueva Metodología.

PALABRAS CLAVE: Procesos de Software, Metodologías Ágiles, Desarrollo ágil.

Las redes abiertas, las libertades digitales, los mecanismos democráticos y la divulgación del conocimiento que Internet ofrecía hasta el momento, entre otras cosas, se ven en peligro por la necesidad de regulación. El problema de regulación de Internet es bastante complejo como para ser resuelto por abogados o por políticos. Se deberá generar un nuevo pacto social en el mundo virtual de forma multidisciplinaria y democrática que garantice la apertura de la información.

Quiero compartir esta interesante disertación de Marcos Salt sobre ciberespacio y delito (Derecho Informático) en donde explica los cambios que se avecinan en la sociedad e Internet y propone una forma de cambio:

Referencias:
-Youtube: TEDxBuenosAires – Marcos Salt – 04/08/10.
-TED Argentina: Marcos Salt: Ciberespacio y delito.

Humor geek 4: Los informaticos y el caos

Este chiste es una versión resumida del que me contara un profesor en una ocasión en mención al caos y que dice así:

«Un medico, un ingeniero y un informático están charlando sobre cual de sus profesiones es la mas antigua.
Empieza el médico diciendo:
-Pues mira, la Biblia dice que Dios creo a Eva de una costilla de Adán, esto obviamente requiere cirugía, y por lo tanto la medicina es la profesión más antigua.
El ingeniero replica:
-Si, bueno, pero antes de eso, la Biblia dice que Dios separo el orden del CAOS, esta fue obviamente una obra de ingeniería.
El informático se echa para atrás en la silla y dice sonriendo tranquilamente porque sabe que ha ganado esa mano:
-Si, pero ¿quién te crees que creó el CAOS?»

En aquella oportunidad no comprendía realmente el significado de Caos y sus implicancias propuestas por la “Teoría del Caos”. De la “Teoría del Caos” se desprenden ideas como la del “efecto mariposa”, la que “sistemas sencillos hacen cosas complejas” y que del “caos surge el orden”. Fue Edward Lorenz quien mostró con el llamado “efecto mariposa” cómo las pequeñas acciones pueden provocar grandes cambios (“el batir de las alas de una mariposa en Brasil provoca un tornado en Texas”). La idea de que del “caos surge el orden” es aseverada por Stuart kauffman y es una idea que intenta explicar, entre otras tantas cosas, el origen de la vida y cierta dinámica en los procesos evolutivos.

Referencias:
-Tecnologia hecha palabra: Teoría del Caos.
-La computación desentraña el caos y la complejidad.
-Mirar el CIELO Blog: teoria del caos.
-La obra de stuart kauffman. el problema del orden complejo y sus implicaciones filosóficas.

Humor geek 2: Entrevista laboral a GOD

Hay quienes se atan a un lenguaje o se especializan en alguna tecnología, pero para GOD el lenguaje de programación y la tecnología no importan en si mismos gracias a “papa google”.

Humor geek 1: Estimación

(Atención: solo para informáticos, geeks, ñoños y relacionados.)

En una reunión de estimación siempre se puede identificar a quien modera, al optimista, al pesimista, al lógico que saca a relucir alguna fórmula (como la de PERT) y a quien se lamenta o rie por la cruda realidad.

Enlaces relacionados:
-Chiste de Martin Galnares: Estimacion de un proyecto.