viernes, 30 de diciembre de 2016

¿Qué tal JIRA como herramienta para apoyar la gestión de proyectos ágiles?

Propietario del Producto ante la pila de producto
Hemos ido probando distintas herramientas y hasta el momento ninguna cubre el ciclo completo incluyendo proyecto y fase de mantenimiento, desde la gestión de la construcción con Scrum, los planes de pruebas con sus criterios de aceptación y las incidencias. En esta ocasión hemos probado JIRA que promete tener todas las herramientas necesarias de forma integrada. Si visitamos la página JIRA Agile podemos leer:

"JIRA Software es una herramienta ágil de gestión de proyectos compatible con cualquier metodología ágil, ya sea Scrum, Kanban o la tuya propia. Desde tableros hasta informes ágiles, puedes planificar, supervisar y gestionar todos los proyectos de desarrollo de software ágil con una sola herramienta. Elige una metodología para ver cómo JIRA Software puede hacer que tu equipo publique software de calidad con mayor rapidez".

Y si vamos al apartado de Scrum:

"Scrum es una metodología ágil con la que se diseñan productos en una serie de iteraciones de longitud fija. Hay cuatro pilares que conforman la estructura de esta metodología: la planificación de sprints, los stand ups (también llamadas scrums diarios), los sprints y las retrospectivas. Saliéndose de lo común, JIRA Software viene con una completa serie de herramientas ágiles que harán que tu equipo de scrum lleve a cabo estos eventos con facilidad".

Entre las características del producto se puede leer:
De entre los informes ágiles incluye:
Pantallazo con la lista de informes ágiles y un par de ejemplos
Lo que no me gusta:
  • Se hace patente el origen de JIRA como gestor de tareas, las historias de usuario son task y las tareas sub-tasks. Pero esto es sólo una cuestión estética que sin duda Atlassian acabará mejorando.
  • El tablero de scrum, aunque está muy bien resuelto, es poco colorido (tengo que admitir que no cargamos fotos o avatares de los miembros del equipo), y se corta con más de 4-6 historias de usuario y por tanto requiere de scroll. Esto reduce la visión agregada del mismo y reduce la visión del todo y del avance del sprint.
Tablero Scrum muy funcional pero poco llamativo para una gestión visual
Lo que me gusta:
  • Historias de usuario no finalizadas en el sprint las lleva de vuelta, junto a sus tareas, a la pila de producto. Es exactamente como debe de ser, si no hay entrega no debe de contar. A más de un equipo novel le extrañará este comportamiento y se producirá la oportunidad para formarles y hacerles comprender el guiado por valor de negocio. Cuando se abra un nuevo sprint y se incluya la historia recuperará las tareas y los puntos hechos contarán para el nuevo sprint.
  • Me encanta que JIRA trabaje por defecto con puntos de historia, para cambiar a horas ideales hay que ir a un rincón de la configuración que está algo escondido. :-)
  • La gestión a nivel de release permite ver el estado completo, con trazabilidad a las incidencias, a los datos de desarrollo y a los impedimentos.
  • Incluye un potente motor de workflow que permite ajustar el flujo de JIRA al del equipo/compañía, permitiendo crear estados y transiciones de flujo personalizadas para cada tipo de elemento: incidencias, historias de usuario, epics, tareas...
  • Los tableros de scrum de JIRA son muy funcionales y muy intuitivos. Se pueden personalizar en vertical para encajar estados con el flujo de trabajo del equipo, y en horizontal para añadir carriles para separar epics, roles, productos/proyectos, etc.
A la izquierda: Los sprints se montan arrastrando historias desde la pila de producto
A la derecha: Arriba, la pila de producto y el detalle de una historia, abajo el detalle de una tarea
Para concluir mencionar que JIRA es una buena herramienta agile que cubre en gran medida las necesidades de desarrollo y que integra de forma avanzada las herramientas de desarrollo con una experiencia común para todo el equipo scrum e interesados del proyecto.

miércoles, 28 de diciembre de 2016

¿Qué parámetros analizar para determinar si un proyecto es factible?

¿Cuánto cuesta? del Agile Inception Deck de Jonathan Rasmusson
Nuestros clientes suelen estar interesados primordialmente en dos cosas:
  • ¿Cuánto va a costar esto?
  • ¿Para cuándo va a estar listo?
En el pack de actividades de la Incepción Ágil de Jonathan Rasmusson tenemos la dinámica ¿Cúanto cuesta?, en la que hacemos todo lo posible para responder a estas dos preguntas para que puedan decidir si el proyecto vale la pena y mostrarles lo que va a requerir.

Junto con los resultados de las actividades del pack de la incepción Estimar el tamaño y Mostrar la solución, esta actividad nos da la tu oportunidad de mostrar qué tipo de equipo va a ser necesario y en como lograr los objetivos del proyecto.
El equipo A del Agile Inception Deck de Jonathan Rasmusson
En la tabla del equipo A, como en la de la imagen de la izquierda, se muestra el equipo necesario sin el cual el proyecto no puede tener éxito. Con esta tabla se establecen las expectativas en torno al tamaño del equipo, los roles clave, el conjunto de habilidades requeridas y la combinación de habilidades funcionales cruzadas necesarias. Es importante incluir nombres de personas concretas cuando estas son requeridas por su expertise.

Con unos cálculos relativamente simples y a grandes números podemos encontrar el coste aproximado del proyecto y decidir sobre su factibilidad. Los costes derivaran principalmente de los salarios de los miembros del equipo durante el tiempo previsto del proyecto, más costes relativamente menores de recursos y servicios para la puesta en marcha. Un ejemplo de cálculo podría ser:

3 personas X 3,5 meses X 20 días/mes X 8 horas/día X $150/hora ≈ $250K

Si se tratara de un proyecto cerrado con un presupuesto establecido, podemos hacer ese tipo de cálculo para ver si el proyecto es factible dadas las condiciones preestablecidas.

martes, 27 de diciembre de 2016

¿Cómo identificar los riesgos principales en la fase de definición del proyecto?

Dinámica colaborativa con post-its para hacer
emerger los riesgos, en rojo el que más preocupa
¿Cuántas veces no nos hemos podido dormir dándole vueltas al estado de un proyecto? Y por buenas razones: pensamos en si nuestros clientes van a cambiar una y otra vez sus requisitos y prioridades, en si las estimaciones no han sido excesivamente optimistas, en que siempre parece que hay más cosas que hacer que lo que tiempo y presupuesto permiten... Y, ¡estos sólo son los riesgos conocidos del proyecto!

Hay mil cosas que pueden ir mal, algunas se pueden gestionar y otras no, algunas se deben de gestionar y otras no. Por ejemplo, no se puede hacer mucho ante el derrumbe de la economía, pero si gestionar dependencias con otros equipos e interesados.

En el pack de actividades de la Incepción Ágil de Jonathan Rasmusson tenemos la dinámica ¿Qué nos impide dormir?, una dinámica que nos invita a una discusión sana sobre algunos de los desafíos y riesgos con los que el equipo podría enfrentarse durante el proyecto, cuales simplemente asumir, cuales mitigar y cuales gestionar.

Riesgos que vale la pena gestionar son por ejemplo:
¿Qué nos impide dormir? del Agile Inception
Deck de Jonathan Rasmusson
Los objetivos de la dinámica son:
Dinámica:
  • Se rellena un tablero con los riesgos identificados por los participantes, cada participante en individual, para luego consolidarlos en un tablero
  • Para cada riesgo se asignan impacto y probabilidad
  • Se priorizan los riesgos y se establecen estrategias
  • Finalmente el entregable será un tablero de riesgos como por ejemplo un tablero ROAM:
    • RESOLVED: riesgos detectados pero que no eran tales
    • OWNED: riesgos sobre los que alguien toma la responsabilidad de gestionarlos
    • ACCEPTED: riesgos que simplemente se asumen
    • MITIGATED: riesgos para los que se han decidido acciones mitigantes concretas
Se trata de una dinámica muy potente ya que nos da la oportunidad de pedir los recursos necesarios para tener éxito y poder exponer las consecuencias si no se proveen estos recursos.

lunes, 26 de diciembre de 2016

¿Cómo transmitir la razón por la que se construye un producto?

¿Porqué estamos aquí? del Agile Inception
Deck de Jonathan Rasmusson
Uno de los cuentos de Jorge Bucay para hacer pensar nos narra:

"Éranse una vez dos picapedreros trabajando en una cantera, ambos trabajando mármoles con un pico de acero. Un desconocido se acercó a uno de ellos, uno que tenía mármoles rectangulares con la forma muy bien definida, y le preguntó qué estaba haciendo:

- Ya lo ves, estoy tallando un hermoso mármol
que me han encargado y así ganarme el sueldo.

Luego anduvo un poco más y vio a un segundo picapedrero, este tenía unos mármoles muy bien tallados y pulidos hasta tal punto que se reflejaba su rostro en la superficie, y le preguntó qué estaba haciendo::

- ¡Construyendo una catedral!
Yo formo parte de un equipo que construye una catedral
y yo tallo los mármoles para la pared del crucero."

Es fácil distinguir quién de los dos picapedreros trabajaba más a gusto, aparentemente hacen lo mismo pero no del mismo modo. No lo hacen con el mismo propósito y valores subyacentes, lo que varía es el "para qué" lo hacen.
Ejemplo de tablero resultado de la dinámica
Un equipo, especialmente un equipo de trabajadores de conocimiento en que la motivación y la creatividad son factores clave, no puede construir un gran producto si no sabe para qué lo está construyendo. Para ello quiero presentar la primera dinámica del pack de actividades de la Incepción Ágil llamada ¿Porqué estamos aquí?, dinámica que le dará al equipo el contexto necesario para la toma de decisiones acertadas durante la construcción.

No olvidemos que los equipos toman miles de decisiones durante la construcción de software, y para que estas sean acertadas han entender el objetivo del proyecto, entender el porqué, y estar informados a través de la visión del producto. Los objetivos de la dinámica son:
  • Compartir y entender las motivaciones que han llevado a la compañía a emprender el proyecto
  • Entender cual de todas las motivaciones es la principal
  • Team building & team commitment
Ejemplo de tablero
La dinámica:
  • El Propietario del Producto ayuda al sponsor a explicar el modelo de negocio a los asistentes a la reunión, utilizando como hilo conductor el porqué del proyecto
  • Se obtiene un tablero con las razones para la realización del proyecto. Una buena técnica consiste en que los asistentes escriban razones en post-its en individual, los consoliden en un tablero y finalmente voten para obtener las razones principales.
Si fuera posible, lo ideal sería llevar al equipo completo a donde está el cliente, y hacer que el equipo entienda lo que realmente necesita este último. Pasar un día en el lugar de trabajo del cliente, y trabajar con las personas que después van a usar el sistema diariamente. Hacer que el equipo se comprometa, que haga preguntas y que se convierta en el cliente.

Mis agradecimientos a mi compañera del equipo OK's Gertru por sus aportaciones siempre de aporte de valor :-)

sábado, 17 de diciembre de 2016

¿La calidad es negociable?

En Scrum la calidad es build-in, no es una variable - cortesía de Pixabay
Un proyecto no puede ser un éxito sin un alto nivel de "contento" por parte del cliente con el producto que le hayamos entregado. En un proyecto gestionado por metodologías tradicionales es factible negociar bajar la calidad con el objetivo de cumplir con los hitos y la fecha de entrega. Al cliente no le sirve lo perfecto, sino tener el producto a tiempo.

En Agilidad la calidad no puede ser una variable, los métodos ágiles priorizan los objetivos del proyecto en función del valor de negocio. A diferencia de las metodologías tradicionales siempre se trabaja con calidad, y para llegar a fechas se prescinde de funcionalidades que aporten poco valor de negocio, de aquellas que están al final de la pila de producto.

Recordemos el noveno principio del Manifiesto Ágil:

La atención continua a la excelencia técnica enaltece la Agilidad

Una técnica que nos garantiza la calidad es la comprobación continua, cuanto más nos ayudemos de este tipo de técnicas menos costoso será garantizar la calidad. Por ejemplo, es mucho más barato llevar las pruebas automatizables a un sistema de pruebas automatizadas y focalizar a los testers en las pruebas más complejas, que hacer que todas las pruebas las ejecuten personas. Con este ejemplo ganamos en dos aspectos, lo automatizable siempre resulta más barato y los testers aplicaran sus habilidades allí donde de verdad hay valor que lo haga una persona.

Otras técnicas para construir productos con calidad interna, necesarias para poder tener un ritmo sostenible de construcción iterativa e incremental, para evitar la deuda técnica y construir con escalabilidad y mantenibilidad nos las traen las prácticas de ingeniería de XP (eXtreme Programming):
Pero lo que realmente hace que construyamos productos excelentes y con gran calidad, es el marco de Scrum en si. Sus ciclos, los sprints, hacen que entre sprint y sprint tengamos inspección y adaptación, lo que quiere decir que tenemos puntos de feedback, puntos de aprendizaje y puntos mejora en cada sprint. La calidad es un resultado natural del marco, no hay que hacer una gestión específica, sólo aplicar correctamente el marco.

Me gusta dar como ejemplo el móvil actual y las prestaciones que da, este es el resultado de un centenar de iteraciones y, si lo pensamos bien el, móvil es un producto más que excelente, es increíble y alucinante. Con el software y Scrum pasa los mismo, a base de iteraciones bien guiadas por negocio llegamos al mejor producto posible en tiempos y costes establecidos.

domingo, 11 de diciembre de 2016

¿Qué tipos de coaches ágiles existen?


Enterprise Agile Coach Coach ágil Scrum Master
Niveles de coaches ágiles
Con el asentamiento de la Agilidad en las compañías se han creado nuevos perfiles profesionales, si miramos ofertas de trabajo nos encontramos con nuevos perfiles de coaches ágiles que a veces resultan confusos.

Lyssa Adkins, del Agile Coaching Institute, nos habla de tres niveles de coaches ágiles:

sábado, 10 de diciembre de 2016

¿No son excesivos los costes de tener a todo el equipo presente en las reuniones de Scrum?

Equipo completo reunido ante un tablero
Observo una y otra vez un error muy común que consiste en poner únicamente el foco en los costes de algo, obviando lo que nos dice la Agilidad, hay que mirar también cuales son los costes por no hacerlo.

Si calculamos los costes de tener a todos los miembros del equipo de Scrum en las diferentes reuniones, podemos llegar a priori a la conclusión que dedicar a todas esas personas dos días de cada diez, en caso de sprints de dos semanas, puramente a reuniones, puede resultar un coste innecesario. Pero recordemos el lema que dice:
"Piensa dos veces
y codifica bien a la primera"

A veces he oído a algún cliente o gerente de consultora sentenciar: "¡Es mejor que dediquen ese tiempo a codificar, que para eso se les paga!". Suelo contestar que con esas reuniones nos aseguramos de que los equipos construyan a la primera lo correcto, con esas reuniones comprenden lo que han de construir. Y les pregunto: ¿Cuál sería el coste si los desarrolladores no construyen lo correcto a la primera? y, si son conscientes de que tal como muestran las estadísticas del Standish Group, que estudian miles de proyectos de todo el mundo al año, desde mantenimientos pequeños hasta gigantescos proyectos de reingeniería, ¡alrededor de un 80% de lineas de código nunca llegan a producción por malentendidos, retrabajo, etc!

Ya no suelo entrar en que además con Scrum construimos guiados por valor de negocio, lo que nos asegura que mediante estas reuniones el equipo está trabajando en todo momento en lo que más valor aporta. Recordemos que negocio sabe lo que quiere, no lo que necesita, eso madura durante el camino y se materializa en cambios necesarios y deseables.

Pero entremos más a fondo, ¿qué puede ocurrir si no hacemos esas reuniones?
  • Escasa colaboración entre negocio y equipo de desarrollo.
  • Comunicación pobre de las necesidades de negocio.
  • No se identifican los malentendidos, con lo que estos emergen en etapas tardías del proyecto y sus consecuencias pueden generar incidencias y deuda técnica.
  • Desarrollo por capas horizontales, diseñamos pensando en el todo, lo que nos lleva a batches largos de trabajo perdiendo así la entrega frecuente de valor de los ciclos cortos.
  • Fases largas de testing y de resolución de incidencias, con lo que alargamos los batches ya de por sí largos.
  • Resistencia al cambio, con lo que los ciclos de absorción de cambios también son largos y dolorosos.
  • Miembros de equipo focalizados en sus tareas, lo que implica poca colaboración y poca creatividad.
  • Finalmente una baja motivación, las reuniones de Scrum hacen que todos sientan que participan del proyecto y que aportan. Recordemos que el propósito es una de las motivaciones intrínsecas más fuertes.
Curvas que son ejemplo de como se pueden comportar ambos costes
estas pueden variar en función del proyecto y la madurez ágil del equipo
Visto todo esto, vemos que sin reuniones trabajamos con batches largos (usualmente hasta final de proyecto o el siguiente hito), lo que produce grandes colas en el flujo de construcción, lo que a su vez produce tiempos de entrega largos, y desde la perspectiva de negocio un time-to-market bajo que puede minimizar seriamente la competitividad de la compañía.

A parte de los costes directos del tiempo dedicado a las reuniones, lo vemos en el gráfico de la derecha en la curva de color rojo oscuro, hemos de tener en cuenta el coste de la demora, en verde, que representa el coste que supone la espera en la entrega de una funcionalidad de valor. Si acometemos un proyecto abarcando el todo desde el principio, y no hacemos reuniones periódicas, perdemos oportunidades de mercado ya que no hay entrega hasta el final, perdemos los ciclos de aprendizaje que nos permiten mejorar el producto y la forma de trabajar así como también perdemos la absorción de los cambios, cambios que siempre implican un aumento del valor de negocio. En la parte de la derecha el coste de la demora vuelve a subir porque en ese caso hipotético los equipos dedicarían su tiempo a reunirse y sus entregas serían muy escasas.

La curva naranja nos muestra el coste total, podemos ver claramente que el coste menor se produce con un nivel de tiempo dedicado a reuniones de entre el 15% y el 25%, tiempo que es coherente con los eventos de Scrum.

Un alumno de uno de mis cursos de Scrum me habló convencido de la imposibilidad de hacer pair programming en su compañía, por los costes elevados que supone. De nuevo hay que preguntarse por los costes de no hacerlo.

Poner a dos personas en un solo ordenador es más costoso que poner a una sola, es de lógica, pero de lógica financiera. Si pensamos en productividad veremos que una persona ante un ordenador tiene 1 de productividad, y cuando hacemos pair programming bien hecho, integramos equipo, unificamos formas de trabajar, creamos base de conocimiento, se producen buenas ideas por colisión de ideas individuales... y todo eso hace que la productividad suela situarse entre el 4 y 6. Desde este punto de vista, el punto de vista de productividad y la lógica de los equipos técnicos, ¿pair programming tiene más costes? ¿o más bien es menos costoso?
¿Es más costoso hacer las reuniones de Scrum? o ¿es más costoso no hacerlas? - cortesía de Pixabay

martes, 6 de diciembre de 2016

¿Pueden las compañías prescindir de la creatividad de sus empleados?

Vivimos en la era del cliente, una era en la que las compañías ya no son dueñas de concebir el producto que van a fabricar. Quienes decidimos somos las personas de a pie, nosotros empoderados por internet y los móviles somos quienes decidimos por ende qué producto tiene éxito y cual no.

Pensemos en un vendedor en un concesionario de coches, ¿tiene posibilidad de vendernos otro coche que no sea el que nos hayamos informado en foros y páginas de internet? Seguramente sabremos más que él de ese modelo que queremos. O, pensemos en la transformación digital en bancos y compañías de seguros, ¿esta es una iniciativa que surge de las compañías o más bien se han visto obligadas a ello para permanecer competitivas?

Ya en 1986, en su artículo "The New New Product Development Game", Nonaka y Takeushi identifican el surgimiento de un nuevo modelo de desarrollo. En la introducción los autores afirman:

"Muchas compañías han descubierto que para mantenerse en el actual mercado competitivo necesitan algo más que los conceptos básicos de calidad elevada, costes reducidos y diferenciación. Además de esto, también es necesario velocidad y flexibilidad… En 1981 las encuestas realizadas a 700 empresas americanas revelan que el 30% de sus beneficios se debe a nuevos productos".

El nuevo escenario, en la era el cliente, eficiencia y previsibilidad ya no son las claves del éxito, claves del éxito son las siguientes variables:
  • Lanzamiento constante de novedades: ¿quién compraría un televisor en el Media Market si este hubiera sido fabricado dos años atrás?
  • Reducción del tiempo de desarrollo: las compañías necesitan un time-to-market corto y frecuente para mantenerse en el mercado
  • Cambios y mejoras rápidas: las compañías necesitan mantenerse competitivas y reaccionar rápidamente a tendencias y oportunidades del mercado
  • Componente innovador: las compañías han de innovar constantemente, y seremos nosotros, las personas de a pie, quiénes en definitiva haremos que una innovación sea un éxito o no funcione
No olvidemos que somos nosotros los de IT quienes construimos herramientas que harán funcionar el core-business de nuestros clientes, por tanto ellos necesitan productos de software que se adapten rápidamente al mercado y a las nuevas ideas.

Creándo espacios para la creatividad hace que hagamos
cosas espectaculares - cortesía de Pixabay
Necesitamos buenas ideas, necesitamos innovar de forma continuada, por tanto, no, las compañías no pueden prescindir de la creatividad de sus empleados.

Para fomentar la creatividad las compañías han de ajustar el trabajo a la capacidad, tener equipos autoorganizados y motivados como ocurre con los equipos de Scrum. Agilidad no es sólo una aproximación más al Design Thinking o al prototipado iterativo, es un sistema holístico bien desarrollado y probado diseñado para imprimir flujo y superar las barreras comunes a la innovación exitosa.

Podemos dotar a los equipos y a los empleados de espacios donde puedan colisionar sus ideas, espacios como son las comunidades de práctica en las que los empleados se dedican libremente a temas relacionados con su trabajo. Funcionan del mismo modo que los cafés ingleses en la época de la Ilustración o los salones parisinos del Modernismo, que fueron motores para la creatividad porque crearon espacios donde las ideas pudieron colisionar para crear grandes nuevas ideas.

Atlassian, la empresa que ha creado Jira, invita una vez al trimestre a que sus desarrolladores se dediquen durante un día, día que han bautizado como ShipIt Day, a lo que quieran, con la única condición de mostrar el resultado al final del día. Resulta que un día de autonomía pura ha dado lugar a un toda gama de ideas para productos de software existente, como Confluence por ejemplo, y ha reducido notablemente deuda técnica y bugs conocidos.

Para cerrar quiero mencionar una frase del libro "¿Dónde está mi equipo? - La vida es viaje" de José Ochoa y Mario Kogan.

Personas comunes consiguiendo
metas poco comunes en equipo

sábado, 3 de diciembre de 2016

¿Cómo afecta la música a los miembros de equipos de Scrum mientras estos codifican?

Escuchando música mientras codifica
Cortesía de Pixabay
Si observamos una sala de desarrollo de software veremos que muchos programadores escuchan música mientras codifican. Muchos dicen que escuchan música para no perder la concentración.

En ambientes de manufactura los empleados nos dicen que escuchando música un trabajo repetitivo cobra vida y se hace más llevadero. En términos biológicos escuchar música hace que liberemos dopamina en el área de recompensas del cerebro.

Amit Sood, físico de medicina integrativa de la Clínica Mayo, nos dice que la mente de las personas tiende a divagar, "y sabemos que una mente que divaga es infeliz, la mayor parte de ese tiempo le estamos dando vueltas a las imperfecciones de la vida", y la música nos ayuda a concentrarnos y a volver al momento presente.

Teresa Lesiuk, profesora asistente en el programa de terapia musical en la Universidad de Miami, se centra en el impacto de la música en el rendimiento en el lugar de trabajo, y en caso de los programadores e informáticos halló que aquellos que escuchan música completan sus tareas más rápidamente y tienen mejores ideas que aquellos que no lo hacen, y que es así porque la música mejora su estado de ánimo.

¿Pero que ocurre con los miembros de los equipos de Scrum? Pensemos que forman parte de equipos muy integrados, conectados de forma "on-line" a través de la autoorganización, motivados y consecuentemente concentrados en sus tareas y de por sí con buen estado de ánimo.

El hemisferio derecho del cerebro, el lado especializado en emociones, sensaciones, sentimientos y habilidades artísticas y musicales, es el que procesa la música. Los trabajos intelectuales de conocimiento y de concentración requieren del hemisferio izquierdo, este maneja la lógica, el pensamiento proporcional, procesamiento de información en series de uno en uno, manejo de información matemática, la planificación, la ejecución y la toma de decisiones entre otros.

Hasta aquí parece buena idea escuchar música mientras se codifica, pero recordemos que los miembros de equipos de Scrum suman mucho más que sus partes y suman también en su ingenio y creatividad, habilidades que ocurren en el hemisferio derecho del cerebro. Como dice Javier Garzás: "Si escuchas música, puedes perder la oportunidad del salto creativo, ya que esta influye en la reducción de la creatividad, y este efecto es acumulativo."

Mi consejo es que no escuchéis música en procesos de concepción y de análisis, los momentos en los que busquéis buenas ideas, y, una vez ya esté decidido como va a ser la codificación será el momento para concentraros sólo en la lógica escuchando música.

Quiero invitaros a leer el post "El porqué de que programar con música hace que seas menos productivo" de Javier Garzás, en él explica un interesante experimento relacionado con este tema.

viernes, 2 de diciembre de 2016

¿Funciona Scrum con equipos con miembros localizados en diferentes áreas geográficas?

Equipo amplio OK's
Si me hicieras esta pregunta hace un par de años diría que no, o que con bastante dificultad, y estaría muy convencido de ello. Luego, en mis experiencias posteriores con proyectos con equipos deslocalizados, algunos entre Madrid y Sevilla por ejemplo, he podido constatar que si, que Scrum puede funcionar perfectamente en esta circunstancia.

Tenemos tecnología y herramientas para ello, las videoconferencias están a la orden del día, pero es necesario algo más, algo más ligado a la naturaleza humana:
La clave está en la confianza

La personas tenemos un bloqueo interno, desconfiamos de quienes no conocemos, por tanto lo tanto hay que desbloquear y generar esa confianza.

Quiero invitaros a leer la experiencia del equipo OK's de Scrum Manager en la primera retrospectiva internacional, el equipo que tutoriza los cursos on-line y que está localizado entre España y Venezuela. Aquí podéis ir al post en el blog de Scrum Manager, post que hemos escrito conjuntamente Gertrudis, Ana, Nicolás y yo, y que allí fue publicado en primicia.

Queremos compartir con todos vosotros algo muy especial que hemos hecho en nuestro curso on-line de Scrum Manager. Una de las realidades que ocurre cada día con más frecuencia es la deslocalización de equipos de los proyectos, y en Scrum Manager no somos una excepción. El equipo OK's está distribuido entre Madrid y Venezuela, y si nos referimos al equipo amplio habría que hablar de toda España. Así que aquí estamos, queriendo compartir nuestra experiencia.

Acaba de finalizar el curso troncal on-line realizado entre octubre y noviembre de este año, y el equipo Open Knowledge (OK's) que lo tutelamos; Álex Menzinsky, Ana Valero, Nicolás Escobar y Gertrudis López, decidimos realizar una retrospectiva al finalizar el curso para ver cómo hemos trabajado en equipo, darnos las gracias entre nosotros por cosas que valoramos que otro miembro del equipo haya hecho durante el curso, ver qué fue bien, ver qué fue lo que no nos gustó, ideas de mejora que se nos ocurrieran y buscar acciones concretas a tomar en los próximos cursos.

Lo particular de nuestro equipo OK’S es que tres de sus miembros viven en Madrid y el otro vive en Caracas, así que teníamos que hacer una retrospectiva internacional, donde pudiéramos participar todos a la vez y así lo hicimos.

Para tener un tablero compartido por todos en la retrospectiva y en donde cada miembro del equipo pudiera colocar sus impresiones, usamos un tablero de retrospectivas on-line en https://realtimeboard.com/, una aplicación espectacular que permite tener un tablero compartido on-line y que provee de una cantidad de formatos predefinidos superútiles y prácticos, entre ellos, formatos para retrospectivas. Además, provee mecanismos para hacer votaciones y comentarios sobre las aportaciones de los participantes.

Definimos y publicamos el tablero unos días antes de hacer la reunión de la retrospectiva para que cada miembro del equipo pudiera ir colocando sus opiniones y tener la base para la reunión. El tablero tiene 5 áreas para opinar: ¿Qué estuvo bien?, ¿Que no me gustó?, Agradecimientos, Ideas y Acciones. En cada una de las áreas fuimos colocando nuestros post-its virtuales con nuestras aportaciones, y si alguien no entendía algo o tenía una pregunta, la colocaba mediante los comentarios que proporciona la herramienta. También expresamos si nos gustaba un comentario colocando un aplauso virtual (uno de los mecanismos de votación que provee el Realtimeboard). A continuación, podéis ver nuestro tablero de la retrospectiva:
Tablero virtual de la retrospectiva del curso troncal de Scrum Manager oct-nov 2016
Acordamos la fecha y hora de la reunión para hacer la retrospectiva, tomando en cuenta la diferencia horaria entre ambos países. Ana, Álex y Gertrudis desde Madrid y Nicolás se conectó vía Hangout desde Caracas. Pudimos compartir la pantalla de nuestro ordenador vía Hangout y trabajar de manera simultánea sobre el tablero, conversando y llegando a acuerdos en cada una de las áreas de discusión. Durante la retrospectiva fuimos rellenando el área de acciones de mejora concretas a tomar para el próximo curso.

Equipo OK'S en plena retrospectiva:
Ana, Álex y Gertrudis desde Madrid y Nicolás desde Caracas
Fue una vivencia magnífica el poder hacer la retrospectiva los cuatro al mismo tiempo y trabajar juntos sobre el tablero, yendo más allá de los kilómetros y del charco que nos separa.

Nuestra experiencia fue espectacular y lo más importante es que funcionó y, al igual que una retrospectiva plenamente presencial, ha tenido la misma potencia. Fijémonos que los participantes de la retrospectiva trabajamos en los cursos on-line de forma distribuida y que en la retrospectiva uno de los participantes lo hizo de forma virtual. En nuestro entorno profesional, y como Scrum Masters, acompañamos cada vez más a equipos de proyectos que están deslocalizados en sus reuniones de Scrum.

Para que ello sea posible necesitamos herramientas que nos proporcionen un tablero virtual y herramientas de videoconferencia que nos permitan vernos y compartir lo que vemos, como el escritorio del ordenador y el mismo tablero virtual. Muchas empresas hacen sus reuniones de forma deslocalizada, pero algo no funciona, utilizan herramientas como las descritas, pero no acaba de rodar bien del todo.

El elemento clave para que funcionen reuniones con participantes distribuidos es la confianza. Si, la confianza en las personas que vemos al otro lado de la pantalla. Una forma fácil de detectar si es así es tan simple como observar si hay caras alegres, risas, chistes y se habla de otras cosas mundanas que, por ejemplo de un grupo de miembros a otro miembro remoto “¿Qué te ha pasado en el pelo, parece que te acabas de levantar? jajaja”

Por tanto, las reuniones por videoconferencia pueden funcionar si generamos confianza entre los participantes. La mejor forma de generar confianza es juntando la gente. Un buen consejo para proyectos que empiezan es juntar durante un par de días a todas las personas comprometidas con el proyecto y hacer que trabajen y tengan actividades lúdicas juntas. En las comidas hablarán de la ciudad, de su familia o de fútbol, ese tipo de conexión es la clave que genera confianza. Podemos llegar a pensar que eso es costoso, pero os aseguramos que no hacer ese tipo de actividad es más costoso, las reuniones por videoconferencia van a ser mucho menos eficientes, quizá hasta estériles en la suma de las personas.

Nosotros generamos la confianza con la presencia, Ana, Álex y Gertrudis, y con el ambiente distendido de un local de batidos y hamburguesas por ambos lados con Nicolás… ah, y contándonos todo tipo de cosas como chistes a través de un grupo como el del whatsapp.

Animaros a que hagáis reuniones y retrospectivas deslocalizadas, que funciona, ahora sí, haced todo lo posible para generar confianza, para generar team-building, y tendréis experiencias tan espectaculares como la nuestra.

En esta retrospectiva podemos ver representado uno de los valores más importantes del Manifiesto Ágil: "Individuos y su interacción, por encima de los procesos y las herramientas". En todo lo descrito anteriormente se puede observar que existe un equipo motivado y que, aunque la distancia que nos separa es significativa, la tecnología se ha encargado de reducirlo a un simple click.

Aunque cada quien tiene una serie de conocimientos y experiencias, se hace la transferencia continua de los mismos en cada una de las interacciones que tenemos día a día por las diferentes herramientas que manejamos; Whatsapp, Trello, RealTimeBoard, Mail, Google Drive, Foro de Scrum Manager, cada quién aportando su punto de vista y generando una gran sinergia.

Y como dice Aristóteles “El todo es más que la suma de las partes”, esto es la holística, que se refiere a la manera de ver las cosas enteras, en su totalidad, en su conjunto, en su complejidad, pues de esta forma se pueden apreciar interacciones, particularidades y procesos que por lo regular no se perciben si se estudian los aspectos que conforman el todo, por separado. El todo que hemos obtenido después de hacer esta retrospectiva va mucho más allá de la suma de nuestras aportaciones individuales, son nuevas ideas nacidas a partir de la combinación de las ideas, de diversidad de perspectivas, de opiniones y pensamientos de cada uno. Así han surgido las grandes ideas para nuestros próximos cursos.

Gertrudis López, Ana Valero, Nicolás Escobar y Álex Menzinsky