Entrenadores - ¿Liderar o no liderar?

He encontrado esta entrada en el blog http://www.bigvisible.com/gschlitz/coach-to-lead-or-not/ y me ha parecido interesante su contenido, de manera que lo he traducido para ponerlo a disposición de la comunidad hispana. No sé qué opinais sobre el liderazgo en el sentido clásico de las metodologías tradicionales y el liderazgo en las metodologías ágiles. Yo creo que la lectura de este texto puede ser útil, y además abrir un debate sobre el papel del coaching en las empresas que comienzan a utilizar scrum.

Mi opinión es contraria a este texto, yo creo que el coaching debe ayudar pero no interferir en el proceso de integración de técnicas ágiles en un equipo. Debe facilitar el trabajo, orientar, pero no liderar, porque se corre el riesgo de malinterpretar los papeles de cada personaje dentro del equipo. De acuerdo que al principio puede ser complejo el llevar a cabo todas las actividades por la inexperiencia, pero con el erro se aprende y sobre todo se mejora en una evolución constante de los equipos de trabajo. También creo que de forma natural aparecerán las personas con más capacidad para el liderazgo...saber lo que hay que hacer no implica liderar al equipo. Yo puedo saber aplicar scrum y trabajar con ello, pero puede que mi personalidad esté muy distante de lo que se espera de un lider como referencia o punto de apoyo en un momento dado.

A menudo oigo diferentes opiniones sobre lo que los entrenadores pueden o no pueden hacer: Un ejemplo es si pueden o no liderar. Una opinión común es que los entrenadores no son líderes.

Mi opinión puede ser un poco controvertida.

Creo que un entrenador es lo que él/ella necesite ser para ayudar a sus equipos a avanzar de nivel. Creo que buenos entrenadores son también buenos líderes, aunque no cumplan papeles de liderazgo sobre aquellos a los que entrenan.

Algunas organizaciones están en tal estado que necesitan alguien para demostrar liderazgo para comenzar a entender lo que un lider hace en su contesto y en ese caso no hay nadie disponible para realizarlo. En ese momento, ninguna cantidad de preguntas Socráticas, diálogo, facilitar recursos, u otras técnicas de ayuda les llegará en un tiempo razonable. En ese momento, imagino a aquellos con un papel estricto de entrenador declarando "no están preparados para <afrontar x>". Yo realizaría una aproximación diferente - Yo temporalmente me haría cargo del papel de líder para demostrar cómo hacerlo y entonces dejar el papel a un miembro del equipo

Consideraciones importantes cuando asumes el liderazgo siendo un entrenador

Cuando haces esto, te quitas tu sombrero de entrenador y te pones un sombrerlo de liderazgo prestado. Fija las expectativas claramente:

• esta es una situación temporal, breve, con objetivos especificos incluidos la demostración y nombramiento posterior
• un objetivo principal de este esfuerzo es entregar el liderazgo tan rápido como sea posible a un miembro del equipo
• un objetivo principal es recuperar el gorro de entrenador tan pronto como sea posible y romper las dependencias del entrenador como lider

Si eres un entrenador, puedes haber actuado como lider anteriormente

¿Facilitas reuniones pronto en un compromiso, tales como descubrir talleres u otras cosas? Estás actuando como un líder en ese momento. Como describo más abajo, es un esfuerzo con un tiempo límite con expectativas muy claras. Pero esto es liderar. Cuanto más explícito y responsable sea el papel de liderazgo que estás tomando, más resbaladiza es la pendiente que sigue, pero con una gestión cuidadosa de las expectativas y un plan claro para la transición del papel a un miembro del equipo, los equipos se pueden beneficiar de tu experiencia y liderazgo.

¿Hacerles cambiar?

Algunos creen que el papel de entrenador es muy explícito y que hay límites muy claros, y esas personas no están "preparadas para ser ayudadas".  Yo no lo creo. Yo creo que "trabajo sobre /con la persona que está enfrente de mi", entre los problemas que tienen y esass reglas a veces necesitan ser cambiadas para ayudarles de la mejor manera. Si quieren cambiar y mejorar, haré lo que sea necesario para ayudarles.

Un ejemplo

Un equipo era el primero en su empresa (una gran empresa) en probar scrum. El equipo es uno de cuatro que trabajan en un gran proyecto. Nadie en los cuatro equipos tienen experiencia con scrum, y la cultura hasta ahora era la de multi tareas, diversos jefes ("tengo cinco jefes, Bob, cinco"), y miedo de estrellarse contra las rocas o exponer información. Hay un liderazgo poco claro.

Una aproximación que funcionó verdaderamente bien en esta situación en diversas empresas para mi fue tomar el papel de lider durante un periodo de tiempo fijado, con objetivos explícitos de transferir el papel a un miembro del equipo tan rápido como fuera posible. Tomando el papel de scrum manager para unos pocos sprints me permitieron - alguien con la pequeña necesidad de romper con la tradición - facilitar decisiones, reglas de desafío, exponer elefantes y demás. Los miembreos del equipo vieron que todas aquellas cosas acabaron de manera exitosa, y un scrum manager natural emergió y tomó el papel, permitiendome centrar en el entrenamiento puro.

Mientras muchos equipos empezaron a probar scrum, apareció un nuevo salto de liderazgo - a nivel de programa. Asumí de nuevo el papel de scrum master- otra vez por un periodo breve de tiempo con objetivos expecíficos de transferir el papel a alguien del equipo tan pronto como fuera posible. Los resultados se repitieron - esta vez a nivel de programación - y los resultados fueron equipos que funcionaron de manera efectiva como un programa agil.

Asumir estos papeles fue un riesgo...es un terreno resbaladizo comenzar a asumir papeles de liderazgo responsable. Sin embrago, en algunos lugares, debe tener lugar un aprendizaje drástico, y en esos sitios, alcanzar algunas respuestas a través del cuestionamiento y facilitación podría llevar una cantidad de tiempo cuestionable. En esto sitios, demostración y tutelaje pueen ser combinados con entrenamiento para encontrar la luz. Más sobre este asunto en mi post coaching courag.

Agile Open Spain en Madrid - 23-24 octubre 2009

Hace tiempo que no actualizo el blog y algunas personas ya me lo han hecho notar, de manera que aquí va mi pequeña actualización.
El tema es sobre metodologías agiles que es un tema que últimamente me está llamando la atención. Quizás sea otra "moda" más sobre la forma de abordar los proyectos / trabajos de nuestra profesión, pero que tiene un fondo que con el paso de años me doy cuenta que es una verdad como un puño: lo importante es el producto final, es algo que interesa tanto a cliente como a desarrolladores. Y en esto radica que se haga frente a todos los problemas que conocemos cuando se hacen las cosas mal, no se tiene la información necesaria, el cliente espere algo distinto a lo que entregamos por no haberse especificado correctamente. Y antes de lamentarnos mejor solucionarlo.
El hecho de que el cliente, o propietario del producto esté involucrado en el desarrollo me parece esencial. Es tan responsable como nosotros de la finalización y entrega de un producto perfectamente validado por él. Nosotros por nuestra parte debemos conocer toda la informacion posible de lo que quiere el cliente y tenemos que irle ofreciendo nuestro trabajo en peridoso coros de tiempo para poder validar nuestro trabajo con el y sobre todo: poder solucionarlo a tiempo. No hace falta malas planificaciones ni mala coordinación, no hay que hacer horas de más en la medida de lo posible.

Para aprender un poco más y empezar a ver lo viable que puede ser en el equipo en que trabajo voy a asistir al Agile Open Spain (siempre y cuando me acepten, jejeje...a ver si puedo aportar algo). En la página comentan esto:

Con los objetivos de difundir las metodologías ágiles en España (Scrum, eXtreme Programming. Lean Software Development) y compartir experiencias, el viernes 23 de octubre por la tarde y el sábado completo tendrá lugar el primer Agile Open Spain en las instalaciones de la Escuela Universitaria de Informática en el Campus Sur de la Universidad Politécnica de Madrid. Ctra Valencia Km.7. 28031 Madrid (Localización Google Maps)

El Agile Open Spain es un evento sin ánimo de lucro organizado de manera muy participativa. Esta diseñado para compartir entre los asistentes sus experiencias, ideas, experimentos y retos sobre metodologías ágiles (despliegue, planificación ágil, retrospectivas, ingeniería, herramientas, gestión de producto, calidad, etc.), basándonos en el formato de Open Space, para promover la colaboración y que la conferencia se convierta en aquello que sus asistentes deseen. No existe una agenda fijada, sino que entre todos crearemos la conferencia, elegiendo temas y participando. Contaremos con algunas de las personas que más saben de metodologías ágiles en España, así que ten por seguro que la conversación será interesante.

Si quieres:

• Compartir tus experiencias como experto o principiante en el uso de prácticas Ágiles.
• Escuchar a algunas de las personas que más saben de metodologías ágiles en España.
• Encontrar el futuro antes de que éste te encuentre a ti.

entonces, inscríbete aquí (notar que el evento es gratuito pero las plazas son limitadas).

Agenda

Viernes

18:00 – 18:30: Bienvenida con aperitivo y networking.
18:30 – 19:15: Presentación del agilismo, de Agile-Spain y del Open Space.
19:15 – 20:00: Identificación y selección de sesiones por parte de los asistentes para crear la agenda del sábado.

Sábado

09:00 – 18:00: Open Space.

Cada sesión tendrá 1 hora de duración. Habrá un espacio de 15 minutos entre sesiones y una hora para comer (coste a cargo de patrocinadores). En total podrán haber hasta 30 sesiones. Se podrá proponer una sesion de 2 horas que ocupe dos bloques de tiempo.

Aunque me tendré que poner al día para saber de qué hablan estos chicos y no ir de paleto por allá.

Agile, Scrum

10 trucos de Subversion para controlar tu código

1. Usa status para encontrar tu...estado

Con Subversion, si quieres encontrar lo que has modificado ejecutas svn status. Este comando compara los ficheros en tu copia de trabajo (working copy) con aquellos en las areas administradas por Subversion (esos molestos directorios .svn), evitando así la necesidad de un acceso a la red de ida y vuelta:

$ svn status
D fish.c
A shrimp.c
M anemone.c


Ten en cuenta que fish.c está previsto que sea borrado, shrimp.c está previsto que sea añadido, y anemone.c ha sido modificado.

Ahora, por defecto, svn status sólo muestra los ficheros que son interesantes (como aquellos que han sido añadidos, modificados o borrados). Si quieres ver la información de todos los ficheros de tu copia de trabajo, utiliza la opción --verbose

  $ svn status --verbose

                44        23    sally     README

                44        30    sally     INSTALL

                44        35    harry     trout.c

D               44        19    ira       fish.c

A                0         ?     ?        shrimp.c

M                0         ?     ?        anemone.c

                44        36    harry     things/rocks.txt

La primera columna representa lo mismo, pero la segunda muestra la revisión de trabajo del elemento. Las tercera y cuarta columnas muestran la revisión del último cambio del elemento y quién la realizó.

Si quieres saber qué ficheros se actualizarán la próxima vez que ejecutes svn update, utiliza la opción --show-updates en el comando svn status

  $ svn status --show-updates --verbose
        *        44        23    sally     README
                 44        30    sally     INSTALL
        *        44        35    harry     trout.c
 D               44        19    ira       fish.c
 A                0         ?     ?        shrimp.c
 M      *        44        32    sally     anemone.c
                 44        36    harry     things/rocks.txt

Puedes ver que los ficheros que serán actualizados son los marcados con un *.

2. Recuerda, puedes mover cosas

He visto personas pasando mucho tiempo en reuniones decidiendo la estructura de directorios y el lugar de los ficheros en un proyecto, pero con Subversion puedes mover ficheros y directorios con total libertad:

  $ svn move foo.c bar.c

 A         bar.c

 D         foo.c

Ahora bar.c ha sido marcado para ser añadido y foo.c ha sido marcado para ser borrado. (Así es como Subversion representa un movimiento de ficheros. svn commit Enviará tus cambios al servidor.)

Puedes mover ficheros y directorios directamente en el servidor mediante las URL's:

  $ svn move -m "Move a file" http://svn.red-bean.com/repos/foo.c \
                             http://svn.red-bean.com/repos/bar.c




Esto realiza el movimiento de foo.c a bar.c en el servidor directamente.

3. Etiquetar y crear ramas mediante copia

En Subversion, las operaciones de rama (branch) y etiquetado (tag) se hacen como copias:

  $ svn copy -m "Tag rc1 rel." http://svn.red-bean.com/repos/trunk \
                              http://svn.red-bean.com/repos/tags/1.0rc1




Has creado una etiqueta de tu línea principal de desarrollo o troncal (indicada como trunk en términos de Subversion). Si en realidad quieres crear una rama, copia la linea troncal de desarrollo en el directorio branches (ramas), es así de sencillo. Y en Subversion, etiquetar y crear ramas es así de rápido.

En Subversion, etiquetas y ramas son sólo rutas copiadas en el árbol del repositorio. Por convención, las etiquetas se encuentran bajo la ruta /tags y las ramas bajo /branches.

Subversion necesita solo copiar un unico nodo directorio para hacer una copia, lo cual no es realmente rápido, pero ocupa muy poco espacio en el repositorio--no importa el número de ficheros incluidos en la rama o etiqueta. ¡La comunidad de Subversion los llama "cheap copies" ("copia barata") por una buena razón!

No estás limitado a etiquetar todos los ficheros en la misma revision en Subversion: Si necesitas hacer una etiqueta o rama "revision-mezclada", siempre puedes copiar una copia de trabajo en una URL:

$ svn copy -m "Mixed branch." . http://svn.red-bean.com/repos/branch/1.2-mixed

Vete a Branching and Merging para una descripción más extensa de cómo hacer ramas y etiquetar.

4. "Revert" en vez de "delete and update"

Subversion almacena una copia original de cada fichero en el directorio .svn de tu copia de trabajo, de manera que puedes hacer esto:

  $ svn revert I-made-a-boo-boo.txt
 Reverted 'I-made-a-boo-boo.txt'

Esto viene bien si no tienes una conexión de red en un momento dado.

5. No temas a tu sistema de control de versiones

Por defecto, ciertos sistemas de control de versiones que no mencionaré (como CVS) traducen los finales de línea (de CR [Unix] a CRLF [Windows] y viceversa) y expanden palabras reservadas (como $Id$) en tus ficheros. Esto es muy útil hasta que subes al repositorio un fichero binario y CVS, en un alarde de generosidad, convierte tu fichero en algo incomprensible.

Subversion nunca hará nada sobre tus datos salvo que tú se lo pidas explícitamente.

Repitamos de nuevo:

SUBVERSION NUNCA HARÁ NADA SOBRE TUS DATOS A MENOS QUE SE LO PIDAS.

Puedes añadir cualquier fichero binario a tu repositorio de Subversion y no tener que hacer nada especial para que Subversion no destruya tu fichero. Sin embrago, si añades un fichero de texto (un fichero .java o .c, por ejemplo), podrías querer que Subversion controle la transformación del fin de linea automáticamente por ti. Esto se hace usando las propiedades de Subversion.

En este caso, tendrás que asignar a la propiedad svn:eol-style el valor native:

  $ svn propset svn:eol-style native halibut.c

y subir tu cambio al repositorio.

Puedes aprender de tu cliente de Subversion para añadir ciertas propiedades a tus ficheros automáticamente--lee la sección de Automatic Properties y su configuración para más información.

6. Log, log, log tu log

El comando log de Subversion proporciona datos útiles y compactos basado en un commit atómico de Subversion. Por ejemplo:

$ svn log
------------------------------------------------------------------------
r3 | sally | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line

Added include lines and corrected # of cheese slices.
------------------------------------------------------------------------
r2 | harry | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line

Outline sandwich fixins.
------------------------------------------------------------------------
r1 | sally | Mon, 15 Jul 2002 17:40:08 -0500 | 1 line

Initial import
------------------------------------------------------------------------

Cada entrada del log muestra el número de revisión de la entrada, el autor, la fecha, el número de líneas en la entrada de log (para ayudar en el análisis de la salida de svn log), y el mensaje de log en sí mismo. Si quieres ver las rutas que cambiaron en la salida de tu log, pasa la opción --verbose:

$ svn log --verbose ------------------------------------------------------------------------ r3 | sally | Mon, 15 Jul 2002 18:03:46 -0500 | 1 line Changed paths: M /trunk/sandwich.txt

Added include lines and corrected # of cheese slices.
------------------------------------------------------------------------
r2 | harry | Mon, 15 Jul 2002 17:47:57 -0500 | 1 line
Changed paths:
M /trunk/sandwich.txt

Outline sandwich fixins.
------------------------------------------------------------------------
r1 | sally | Mon, 15 Jul 2002 17:40:08 -0500 | 1 line
Changed paths:
A /trunk/sandwich.txt

Initial import
--------------------------------------------------------------------

En los ejemplos anteriores, habrás notado que no hemos pasado ningún fichero o directorio específico (llamados targets) al comando de log. Si ejecutas svn log sin especificar targets (objetivos), Subversion presupone que te refieres al directorio de trabajo actual. Subversion usa una revision de incio de 1, y la revision de trabajo de tu directorio de trabajo actual como la revision final. (Puedes saber cuál es esta revision de trabajo usando svn status -v, como mencionamos anteriormente.)

Y ahora una pequeña nota: Si subes un cambio de un fichero e inmediatamente ejecutas svn log, no verás el mensaje de log de tu commit reciente. Esto es debido a que la "revision de trabajo" de tu directorio de trabajo no ha sido actualizado (subir un fichero no actualiza inmediatamente tu directorio de trabajo o cualquier otro fichero). Si ejecutas svn update y a continuación svn log, verás el mensaje de log "perdido".

Lee http://svnbook.red-bean.com/en/1.5/svn.tour.history.html y http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.log.html para más información sobre el uso de svn log.

7. Deshacer rápidamente un commit erróneo

Supón que tienes una copia de trabajo de /trunk y descubres que el cambio que hiciste en la revisión 303, que modificó oyster.c, es erróneo por completo--nunca debería haberse subido al repositorio. Puedes usar svn merge para "deshacer" el cambio en tu copia de trabajo*, y entonces subir la modificación local al repositorio. Todo lo que necesitas hacer es especificar una diferencia inversa usando svn merge:

  $ svn merge -r 303:302 http://svn.example.com/repos/calc/trunk
 U  oyster.c

Usa svn diff para verificar que el cambio es correcto, y entonces súbelo al repositorio.

Para más información, lee Undoing Changes

* Es decir, restaura la última versión de tu repositorio a su estado anterior; Subversion todavía tendrá el commit "malo" en el repositorio. Siendo un sistema de control de versiones, el trabajo de Subversion es recordar todo lo que le hayas enviado.

8. Recuperar elementos eliminados

Si borras un fichero de tu repositorio y quieres "resucitarlo" a la última versión del respositorio, la forma más fácil es con svn copy desde una revisión anterior a su eliminación a tu copia de trabajo. Usa svn log -v para encontrar la revisión donde fue borrado, y entonces haz tu copia:

 $ svn copy --revision 807 \
             http://svn.red-bean.com/repos/trunk/perch.c ./perch.c

Para más detalles, mira Resurrecting deleted items.

9. Cambia a una rama sin crear una nueva copia de trabajo

Como Subversion trata las etiquetas y las ramas como rutas normales en el repositorio, puedes ejecutar svn update para actualizar tu copia de trabajo al nombre de la rama con la que quieres comenzar a trabajar. Introduce el comando svn switch.

svn switch actualiza tu copia de trabajo para apuntar a un nuevo árbol en el repositorio--es decir, el árbol de una rama en vez del árbol troncal.

Esta es la manera que Subversion tiene para mover una copia de trabajo a una nueva rama.

  $ svn switch http://svn.red-bean.com/repos/branches/vendors-with-fix .
 U  myproj/foo.txt
 U  myproj/bar.txt
 U  myproj/baz.c
 U  myproj/qux.c
 Updated to revision 31.

Para más detalles, ver Traversing branches.

10. Visualizar o montar tu repositorio

Si tu repositorio Subversion está instalado a través del servidor Apache HTTP Server (es decir, accedes a él mediante una URL que comienza con http), Subversion te da un par de regalos muy sabrosos:

Primero, puedes acceder desde cualquier navegador web al repositorio de Subversion y navegar como quieras através de la última revisión del repositorio.

Segundo, si usas un sistema operativo que conozca el protocolo DAV, puedes montar tu repositorio de Subversion en tu escritorio (sólo lectura):

Además de ser conveniente para ver el contenido de tu repositorio, es útil para compartir ficheros con usuarios distintos a Subversion.