Ya se ha anunciado la primera conferencia nacional sobre metodologías ágiles en España. Será el 10 y 11 de junio de 2010 en Madrid, en el Campus de la E.U. Informática de la U.P.M.

Toda la información sobre la misma se encuentra en la web de Agile Spain de la conferencia 2010.

Como invitado principal estará Henrik Kniberg autor de “Scrum y XP desde las trincheras” y de “Kanban vs. Scrum – Obteniendo lo mejor de ambos”.

Es una gran noticia la organización de este evento, por primera vez todos los profesionales que emplean metodologías ágiles tendrán una cita ineludible en España.

Todos podemos ayudar a que el evento sea un éxito, la mejor manera es participar activamente y para ello puedes hacerlo de tres maneras distintas:

• Siendo Sponsor
• Proponiendo una sesión de trabajo o conferencia (antes del 30 de abril)
• Colaborando en su difusión (antes del 30 de abril)

Desde este blog apoyamos esta iniciativa activamente, iremos comunicando todas las novedades sobre el evento, ni que decir tiene que ya hemos enviado nuestras propuestas de conferencias.

Para responder a esta pegunta hay que realizar un análisis de la situación actual de cada empresa, para ello se deben de tener en cuenta los requisitos y la tecnología que se está empelando.

En la gráfica podemos ver que si disponemos de una tecnología conocida y unos requisitos específicos , el problema a solucionar es bastante sencillo, por lo que cualquier sistema es válido para sacar el trabajo adelante. En el caso contrario ocurre lo mismo, cualquier trabajo sobre una tecnología desconocida y unos requisitos muy vagos, lo único que consigue es una anarquía que no puede solucionar ninguna metodología de trabajo, ni las ágiles, ni ninguna otras.

Integrar una metodología ágil en una organización o empresa, debe de tener como objetivo principal gestionar proyectos que estén dentro de la zona compleja.

Si la mayoría de los proyectos de una empresa se encuentran en la zona azul, es cuando se recomienda a los gestores de la misma el uso de metodologías ágiles. Esta recomendación viene avalada por que es justamente donde se puede sacar el máximo beneficio de Scrum y de sus procedimientos.

El framework Scrum está preparado y es efectivo para manejarse en las situaciones complejas, e incluso las que rocen la anarquía. En las otras zonas se comporta igual que cualquier otra metodología.

Cuando un cliente nos escribe en un documento las necesidades que tiene para alcanzar sus objetivos, nos esta dando una información muy amplia y normalmente poco precisa en bastantes aspectos. El cliente suele tener claro el objetivo, pero muy poco los detalles peque´ños, que al final son los garantizan poder tener éxito.

Tomemos como ejemplo un cliente que nos plantea el objetivo de tener una web de comercio electrónico para la venta de productos naturales de cultivo ecológico. Tiene muy claro el objetivo principal, y nos transmite este objetivo en un extenso documento, pero normalmente olvida traducir este documento en tareas a desarrollar.

La primera misión del Product Owner es exprimir toda la información que recibimos para convertirla en un documento donde se escriban los pequeños objetivos que tenemos que alcanzar, la pila de producto.

Como es bastante difícil poder desfragmentar en pequeñas tareas todos los objetivos intermedios del cliente, lo mejor es dividir los mismos en varios niveles de precisión. Básicamente, podemos precisar de forma mas exhaustiva las primeras tareas a realizar, sin saber como serán las que realizaremos dentro de unos meses u años, dado que no podemos adivinar al cien por cien el futuro.

La mejor manera de manejar la incertidumbre del futuro es crear distintos niveles de tareas en la pila de producto.

• Épicas: Son todas las grandes ideas del cliente. Todas se pueden hacer, no se dice no a nada. Las estimaciones suelen ser altas, al tener un alto grado de incertidumbre.
• Temas: Las ideas generales ya diseccionadas en áreas de trabajo distintas.
• Historias: Detalles concretos de cada tema
• Tareas: Si una historia dura mas de dos días de trabajo, debería dividirse en tareas, no es recomendable que se trabaje en una historia que dure mas de dos días.

Pongamos un ejemplo:

• Épica: Meter sistema de pago On Line
• Tema: Pago Por Tarjeta, Transferencia o PayPal
• Historia: Conexión con un banco en concreto.
• Tareas: Test, XML, etc.

En el ejemplo anterior no parece muy difícil disgregar las épica hasta llegar a las tareas. Esto por que es el primer objetivo del cliente que hemos analizado. Pero supongamos que el proyecto de desarrollo del portal se estima en un año. Al momento del inicio, no sabemos con que nos vamos a encontrar en un futuro, por lo que lo mejor es redactar una épica.

• Épica: Meter sistema de pago On Line
• Tema: Pago Por Tarjeta, Transferencia, PayPal, Iphone, Android, o algún nuevo sistema que salga, por ejemplo si lo lanza Google.
• Historia: Conexión con un banco, no tenemos ni idea de con que banco, dado que esta negociando als condiciones.
• Tareas: No existen tareas, dado que no hay historias concretas.

Como podemos comprobar, predecir el futuro es imposible, e incluso puede que el cliente al final no llegue a ningún acuerdo con ningún banco y solo acepte PayPal. Es por esto que para tener un rango del coste se crean dentro de la pila de producto distintos niveles de detalles, el cliente puede tener una idea aproximada, pero no se puede concretar hasta que llegue el momento de abordarla.

Perder el tiempo en querer redactar de forma detalla el futuro es una pérdida de tiempo y dinero, y casi siempre genera un gran conflicto entre el cliente y la empresa contratada. La recomendación es muy clara, emplear distintos niveles de detalles en la pila de producto.

Un equipo de Scrum es mas que la suma de sus individualidades. La foto que empleamos para ilustrar este artículo es el fiel reflejo de la relación de un equipo de Scrum.

Deben divertirse como niños, el trabajo que realizan, aún asumiendo su cuota de responsabilidad, les debe permitir divertirse, jugar en equipo. Esa es la principal cualidad que debe tener un equipo de Scrum.

Estamos acostumbrados a que las personas vean el trabajo como una carga, un mal menor. Esa es la opinión o pensamiento general que suelen tener los gerentes o directores de empresas. Que los miembros de su equipo hacen las cosas por obligación, buscando solo el beneficio económico.

Este planteamiento es un error muy común, como podemos ver en la pirámide de Maslow:

El nivel económico es una necesidad que se puede considerar que cubre los dos primeros escalones de la pirámide, pero no es la principal que hace que una persona cualificada se mantenga en su puesto de trabajo.

Hay que diferenciar, entre personas cualificadas y personas no cualificadas. Estás últimas tienen mas difícil el acceso al mercado de trabajo y un ascenso en el mismo, por lo que normalmente se conformarán con cubrir sus necesidades básicas.

Las personas cualificadas buscaran seguir escalando en la pirámide lo mas alto posible. En un equipo de Scrum se puede progresar, y seguir avanzando escalones de la pirámide.

En un equipo, si se les deja ser como niños, tener ilusiones, poder gestionar y solucionar problemas, ayudarles y estimular la participación global, por encima de una competición individual, al final se consigue que los miembros del equipo, alcances los siguientes niveles sin necesidad de hundir o desprestigiar a otros compañeros de trabajos.

Trabajando en equipos autogestionados las personas alcanzan: La afiliación, el reconocimiento y la autorealización.

El principal valor que tiene que tener un equipo es ser como un niño: Tener la mente abierta todo, poner ilusión en lo que hace, no mentir y sobre todo, disfrutar mucho de los que se está haciendo, compartir los éxitos y fracasos entre todos y ser feliz.

Es muy raro no ver a un niño feliz cuando juega a algún deporte con amigos en un equipo. En caso de no serlo, hay que educarle a pensar en el equipo por encima del egoísmo personal.

El Scrum Master necesita ser un referente dentro del equipo, un compañero especial, para ello debe ser y parecer un líder. Un líder que sepa dirigir al equipo, transmitir confianza, seguridad y valores de sacrificio por el equipo.

El Scrum Master debe poseer el don de la empatía, saber estar a la altura de cada uno de sus miembros, poder armonizar y canalizar la energía individual para que todos vayan al mismo compás, y se produzca un beneficio general.

El Scrum Master además debe ser sociable.

La recomendaciones sobre que personas del equipo deben asumir el papel de Scrum Mater, varían según las distintas corrientes de opinión:

a) Hay una corriente que aboga por que este rol sea rotatorio entre todos los miembros del equipo, lo que conlleva, a que cada uno vaya creciendo en las cualidades antes comentadas cuando tenga que meterse en el papel del Scrum Master.

b) Existe otra que opina que este papel debe desempeñarlo la persona que tenga estas cualidades, dado que conseguirá aumentar la productividad y felicidad del equipo. Con esto se busca el objetivo de no obligar a miembros del equipo a ejercer una rol para el cual no están capacitados.

La recomendación es que cada uno elija la opción que considere mejor para su equipo. No existe una verdadera.

Una de las mayores críticas que recibe Scrum es la carencia de una documentación exhaustiva, una documentación, que según estos mismos argumentos, ayuda a seguir el plan y a que se cumpla exactamente.

En este aspecto tienen toda la razón, Scrum no esta acompañado de una exhaustiva documentación, como dice uno de los principios del manifiesto ágil: “El software que funciona, por encima de la documentación exhaustiva”.

Scrum no adivina el futuro lejano, ni el intermedio, como mucho te ayuda a tener una visión general de como quiere llegar a ese futuro. Scrum te ayuda a ir dando pasitos hasta llegar a él, pero no sabe que ocurrirá en el futuro .

En realidad nadie sabe que ocurrirá en un futuro lejano, cualquier proyecto que tenga de tiempo de trabajo mas de un año tiene una gran incertidumbre, por lo que querer averiguar el futuro con una documentación exhaustiva, es como jugar a las cartas de tarot, por eso Scrum decide aprovechar el tiempo que se invierte en generar esta documentación en otros menesteres, como por ejemplo comenzar ya el camino, el trabajo, que ya veremos donde estaremos dentro de unos meses.

Lo que es una crítica con argumento, en verdad se convierte en una herramienta que no sirve para predecir el futuro, si no todos seríamos visionarios y sabríamos adivinar el futuro.

Los estudios demuestran que un 64% de las funcionalidades implementadas en proyectos con una documentación exhaustiva no se usan, y que solo un 16% de los proyectos se completa con éxito. Estas cifras demuestran que la disposición de una documentación grande no garantiza adivinar mejor el futuro.

La recomendación es preparar de forma sencilla una hoja de ruta con las ideas básicas que se quieren alcanzar priorizadas por importancia y comenzar a caminar. Cuando se vayan cumpliendo etapas ya se volverá a pensar sobre nuevas necesidades e incluso añadir la documentación necesaria para su buena ejecución si hace falta.

Esta semana en la web de Proyectalis, han puesto a disposición de toda la comunidad la traducción al español del libro “Kanban and Scrum – making the most of both“, escrito por Henrik Kniberg & Mattias Skarin y prologado por Mary Poppendieck & David Anderson.

Descarga del libro en español desde la web de Proyectalis.

Para descargar la versión en Inglés, se debe acceder a la web de InfoQ.

Han participado en esta traducción el equipo de agile-spain.com
Rodrigo Corral, Xavier Quesada-Allue, Jorge Uriarte, Agustín Yagüe, Teo Sánchez, Juan Palacio, Gregorio Mena, Ángel Agueda, Laura Morillo-Velarde, Jorge Jiménez, Javier Sánchez  y Juan Quijano.

Coordinación de la traducción: Ángel Medinilla.

Uno de los errores mas comunes que se comete a la hora de implementar Scrum en un equipo de trabajo, es estimar el coste de los esfuerzos en horas. Nunca se debe utilizar este parámetro, dado que el factor tiempo solo es una parte de la ecuación.

Cuando una persona pregunta como se cuantifica en valor de 1 esfuerzo en Scrum, lo ideal es plantear la siguiente ecuación:

Esfuerzo = Tiempo + Incertidumbre + Complejidad

Un claro ejemplo exagerado de que no solo se puede medir en tiempo los esfuerzos de cada tarea de la pila de producto es el siguiente:

Una médico tiene que operar de apendicitis a un paciente, a lo mejor lo hace en 20 minutos, pero necesita tener todos sus sentidos alertas para no fallar, se está jugando la vida de una persona. La tarea en tiempo no es mucha, la incertidumbre de lo que se va a encontrar tampoco, pero la complejidad de las acciones que va a llevar a cabo es alta, lo ha tenido que aprender en muchos años de estudio y prácticas.

Después de esos 20 minutos de alta concentración. El médico debe descansar y tomar una pausa para pasar a su próxima tarea.

Con esto queremos hacer reflejar que el tiempo solo es uno de los factores de la ecuación del cálculo de un esfuerzo, cuando un equipo se reúne para estimar una pila de producto, no puede tener este valor solo como referencia, porque entonces la operación de apendicitis costaría casi “0 puntos”.

Volvemos a hablar de ScrumManager, y esta vez para recomendar sus podcats, dado que son unas lecciones muy interesantes. En cada uno se van tratando diversos temas, siempre relacionados con Metodologías Ágiles y Scrum.

Lo podcats son un coloquio entre personas invitadas debatiendo sobre el tema principal. El nivel de los participantes es muy alto, entre ellos: Agustín Villena, David Alfaro,etc.

Recomendamos esta página, por que cada vez es mas completa, puedes realizar cursos, acceder a mucha información y escuchar podcast.Los podcast te permiten poder escucharlo en cualquier momento y circunstancia, lo que nos permite aprovechar cualquier momento de viaje o de espera para seguir formándonos en Scrum y las Metodologías Ágiles.

Volvemos a emplear una imagen del genial Forges para ilustrar este tema.

Antes que nada explicar que se le llama “Deuda Técnica” a una metáfora creada por Ward Cunningham:

Aquella deuda que se contrae, normalmente con los clientes que no con los bancos, aunque si un banco es tu cliente es posible que tengas una deuda técnica con él, cuando se decide hacer las cosas de forma rápida, normalmente interrumpiendo la pila de sprint.
Esta interrupción u distorsión suele tener como objetivo meter mas carga de trabajo en la pila de sprint, o también, acelerar artificialmente la velocidad para poder llegar a una fecha de entrega pactada, por lo que el resultado final de esta entrega no cumple con los estándares de calidad admisibles, comprometiendo además los futuros desarrollos con el mismo cliente.
Se genera una “Deuda Técnica” con el cliente, que genera unos intereses futuros, la cual se arrastrará en siguientes trabajos hasta que no se le ponga una solución.

El foco de inicio de la deuda suele venir por la prisas el Product Owner, que presionado por el cliente decide alterar los sprint para poder cumplir objetivos.
Todos los clientes sienten una tentación a denominar urgente a muchos encargos, aunque de verdad no tengan esta etiqueta. Este mensaje se lo transmiten al Product Owner, y al final repercute en la velocidad y la calidad.

Para poder minimizar los efectos de las deudas se pueden plantear varias soluciones:

• Explicar al cliente las consecuencias de sus decisiones, las cuales van a generar una deuda técnica, y que en un futuro se deberá disponer un tiempo para arreglarla.
• Demostrar con un ejemplo práctico al cliente que la deuda disminuye la calidad del resultado.
• Enseñar al Product Owner a decir “No”.

- Un ejemplo práctico real de deuda técnica en un desarrollo de un software:

Un cliente tiene la necesidad de presentar una página web en una fecha en concreto, el equipo de producción eran dos personas, por lo que disponía solo del tiempo de esta dos personas.

Estaban realizando el proyecto según el plan previsto, pero el cliente al final necesitó lanzar la página antes de lo previsto, por lo que modificó algunas tareas. Para ello decidió crear una plantilla única para todos los contenidos de texto de los artículos, los cuales solo incluían una foto al comienzo de cada artículo y un texto, así ahorraba tiempo en el diseño y la maquetación de la web.

A la hora de lanzar la web se dió cuenta de que la mayoría de artículos deberían tener mas de una foto, había asumido una deuda técnica por salir antes, y ahora venían las consecuencias por las prisas, o pagaba por las próximas horas para volver a programar el gestor de contenidos o se quedaba como estaba.

En muchos proyectos no es tan clara la deuda técnica, pero son pequeños detalles que se van sumando, y al final del mismo suponen un gran problema.