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

jueves, 1 de diciembre de 2016

¿Como identificar de forma colaborativa cuáles son los aspectos más importantes de un proyecto?

Compensar las decisiones del Agile
Inception Deck de Jonathan Rasmusson
En todos los proyectos hay que gestionar y priorizar las expectativas, para ello quiero mostrar la dinámica que se denomina compensar las decisiones y que forma parte del pack de actividades de Incepción Ágil.

Todos los proyectos tienen que estar balanceados en el tiempo, el dinero, el alcance, la calidad... en algunos proyectos se trata del coste, en otros del tiempo... es necesario tener una conversación por adelantado para que sepamos cuales de estos aspectos son más importantes y cuáles pueden ser flexibles.

Tablero con las prioridades del proyecto
La dinámica nos muestra con claridad lo que se va a dar como: ¿cuál es el aspecto que pudiera romper el proyecto? ¿es la facilidad de uso? ¿la sencillez? ¿la velocidad? ¿la flexibilidad? ¿la seguridad? Hay que anotar todos estos aspectos y asegurarnos de que las expectativas de todos los implicados en el proyecto estén alineadas. Esta dinámica de alto nivel puede ser una guía cuando las cosas se compliquen.

Se trata de poner sobre la mesa todos los aspectos que pudieran ser importantes y decisivos en algún momento del proyecto, por ello debemos estudiarlos y ver cuales están en juego, que compensaciones podemos hacer, y como utilizarlos a nuestro favor en el proyecto.

Los cuatro aspectos clásicos a tratar son:
Otros aspectos importantes que se pueden tratar y que dependerán del proyecto son:
  • Usabilidad
  • Sencillez (no me hagas pensar)
  • Auditoria detallada
  • Seguridad
  • Velocidad
  • Escalabilidad
  • Aprendizaje
  • ...