Archive for Artículos

Gestión de cambios en Scrum

El otro día me preguntaron en el evento E-TIC de Sevilla vía twitter (@emartos) por cómo podemos realizar una gestión de cambios desde Scrum. He creido que igual podíamos compartir la forma en que vemos la gestión de cambios desde la agilidad. Tomamos como partida mi contestación a @emartos :)

QUÉ ES UN CAMBIO?

Digamos que una modificación en el alcance de una o varias piezas de un proyecto.

Entendamos por pieza del proyecto tanto las historias de usuario como las tareas que las conforman. Los cambios pueden afectar a lógica del proyecto, funcionalidad, tecnología empleada, entorno del proyecto, etc…

No debemos considerar cambios a las incidencias, bugs, etc.. que nos aparecen a lo largo de todo proyecto. Aunque a la hora de tratarlos podamos seguir en parte la forma en la que los tratamos.

TIPOS DE CAMBIOS

Me voy a basar en los tipos de cambios que dice ITIL sin tener en cuenta los cambios estándar o pre-autorizados. Nos quedaremos pues, con dos tipos, cambios Normales y de Emergencia.

De forma resumida:

  • Los cambios Normales, son aquellos que tienen que ser revisados por el conjunto equipo-Scrum Manager (ScrumMaster)-Product Owner. Pueden llegar en cualquier momento pero no implican acción inmediata.
  • Los cambios Emergencia, son aquellos tan inesperados como los Normales pero que nos implican acción en el mismo momento en el que llegan.

Además en ITIL hay un responsable de autorizar los cambios. Es el Gestor del proceso. En nuestro mundo ágil ese responsable será el Product Owner.

IMPACTO DE LOS CAMBIOS

Otro aspecto que tenemos que valorar es el impacto del cambio en nuestro proyecto/Sprint.

  • Sin Impacto destacable. El cambio no afecta de forma sustancial al objetivo del proyecto o Sprint
  • Impacto sustancial. El cambio afecta de forma sustancial o al proyecto o al Sprint.

……

Bueno tenemos las piezas, arranquemos la gestión de cambios.

CAMBIOS NORMALES

Los cambios Normales, llegan en cualquier momento y se han de ‘encolar’ hasta la próxima reunión de preparación de Sprint donde habrá que tratarlos y ver si se aceptan y entran a formar parte o modifican de alguna forma el Product Backlog.

Recordemos que el propietario del Product Backlog es el Product Owner y el será, como hemos dicho, el responsable de autorizar la modificación, eso sí, asesorado por el Equipo

Creo muy recomendable dejar claro al inicio del proyecto, entre Product Owner y el Equipo la forma en la que se van a tratar los cambios y evitar que esos cambios Normales nos interrumpan el Sprint. Lo digo porque seguro que si has estado en cualquier proyecto te han llegado esos cambios ‘Normales‘ que hacen que des la vuelta al proyecto cada semana :)

 

CAMBIOS DE EMERGENCIA

Ahora los difíciles, los de ‘Emergencia’, alguno pensará que el 90% de los cambios que le llegan son de ‘Emergencia’ :) Si es tu caso, mal vamos :) .

Los cambios de Emergencia, como los Normales, llegan en cualquier momento, pero estos implican que tenemos que actuar.

Debe estar prefijado entre Product Owner y Equipo, QUÉ SON cambios de Emergencia o al menos QUÉ NO SON cambios de Emergencia, que permita determinar si algo realmente es susceptible de ser tratado en cuanto llegue o puede esperar a la finalización del Sprint.

Hay dos tipos de Cambios de Emergencia según su impacto, los de bajo/sin impacto y los de Impacto sustancial.

CAMBIOS DE EMERGENCIA SIN IMPACTO SUSTANCIAL

Para los primeros (bajo o nulo impacto) debemos tener un procedimiento preparado para asumir la llegada de ellos sin que nos distorsione mucho el flujo del Sprint:

  • Si usas Kanban quizás dejar un camino para estos cambios y preparar el WIP limit de la columna ready para asumir ese extra. Esto te permitirá asumir las tareas derivadas del cambio.
  • Otra cosa es calcular la velocidad de tu equipo en función del % de esfuerzo que te vayan a requerir estas acciones extraordinarias. En lugar de 40 Puntos por semana, igual solo puedes tener 30 puntos y sabes que 10 los vas a dedicar a estos cambios… Analiza tu historia en el proyecto o en tu entorno. Esto es semejante a como podemos tratar incidencias, bugs, etc…

Cada conjunto product owner + equipo usará el proceso que mejor encaje.

 

CAMBIOS DE EMERGENCIA CON IMPACTO SUSTANCIAL

El problema son los cambios Urgentes con Impacto sustancial.Creo que este tipo de cambios deben tratarse y resolverse en la reunión de planificación del Sprint. Así que cuando llega un cambio así hay que:

  • Preguntar si el cambio puede esperar ya que no afecta al Sprint.
  • Si la respuesta es SI. Terminar el Sprint y en la reunión de planificación del siguiente Sprint tratarlo y construir el siguiente Sprint.
  • Si la respuesta es NO (por su alto impacto en el proyecto o porque si que afecta al Sprint). La acción es fácil. Interrumpir el Sprint y volver a la planificación. La decisión de la interrupción del Sprint la ha de tomar el Product Owner. Debidamente informado por el equipo y valorando el impacto que trae dicha interrupción.

Una última cosa. Los cambios mejor al principio de los Sprints :)

Y tu? Gestionas los cambios? Cómo?

Scrum Manager contra el mundo

En España llevamos un gran retraso respecto a otros países europeos en algunas cosas. Es verdad, sí, les ganamos en tomarnos nuestras cañitas, en echarnos la siestecita y en algunas otras cosas que llamamos calidad de vida (aunque no será para tanto cuando salimos tan tarde de los trabajos) y mantenemos esa culturilla que enaltece al triunfador, al que ha sabido engañar al sistema, al que se lo ha montado bien y ha dado el pelotazo, en definitiva, al que vive como un marqués, sin apenas dar el clavo. Esta misma culturilla es la que nos impide dar pasos con mayor firmeza para salir de la crisis, la misma que nos sume en ese dejar hacer las cosas tal y como están, porque así ya funcionan.¡Nosotros sí que sabemos vivir!

Qué lamentable sensación la de saber que se están haciendo las cosas de forma mediocre, y ver que los demás piensan igual, pero nadie se atreve a dar el primer paso para cambiarlas. Esta sensación de pregonar al vacío cuando nos dirigimos a la jerarquía establecida, ofreciéndoles otras formas de gestionar, que hace falta más motivación entre el personal, que podemos dar pasos de gigante en nuestro negocio y no conformarnos con estar en el mercado, choca inevitablemente con este tufo de sabelotodo que nos impregna.

Cuando hablamos de Scrum Manager, en el fondo estamos ofreciendo la idea de que es necesario el cambio en la gestión, y esto choca inevitablemente con la pirámide de poder. Cuando hablamos de que cada vez es mayor el número de empresas que están cambiando la forma de hacer las cosas, estamos diciendo a nuestros gestores, que se están quedando rezagados, que empieza a llegar al negocio la terrible obsolescencia. Y ese es el primer revulsivo que estamos observando entre el empresariado. Parece como si doliera más a nuestro orgullo saber que otros nos toman la delantera, que el saber que durante años hemos estado haciendo las cosas de forma mediocre.

Si nos fijamos en el artículo Adopción de metodologías ágiles: un estudio comparativo entre España y Europa, pág.6, publicado por la revista REICIS – Volumen 6, Número 4 de Diciembre 2010 (www.ati.es/reicis), podemos ver lo mucho que nos queda por hacer en España. Tenemos que seguir luchando cada uno desde su trinchera para cambiar las cosas.

Como decía Gandhi: “Cada logro sea grande o pequeño tiene etapas de esclavitud y de triunfo; un comienzo, una lucha, una victoria.”

Hagámoslo vs Hazlo

Si es verdad, como empieza a vislumbrarse según las experiencias de Masaru Emoto en base a su libro “Los mensajes del agua”, que el agua, y por extensión los seres vivos que la poseen, mantiene una estructura interna acorde a las sensaciones y al tipo de pensamiento que sobre ella proyectamos, pronto entraremos en una fase decisiva en la evolución humana.

Empezaremos a comprender las maravillas de ciertas aguas curativas, o el porqué de la incorruptibilidad de ciertos personajes, así como la explicación de terapias alternativas como el reiki. Las investigaciones sobre el poder de la oración se harán cada vez más creíbles, y asistiremos a un nuevo proceso de bendición de alimentos, personas, casas, y cuantos objetos imaginemos.

Sorprende comprobar algo en lo que venimos insistiendo durante años, cuando nos referimos a la forma de trabajar, a la forma en la que se manifiesta la autoridad, tal y como se desprende de las imágenes obtenidas sobre los pensamientos “Hagámoslo” frente a “Hazlo”. ¿Es posible que la Naturaleza posea un mecanismo interno antiquísimo mediante el cual sobrevivan mejor las especies que colaboran frente a las que trabajan de forma aislada? ¿Es posible que el orden de las pequeñas cosas, a nivel molecular, se refleje también en el orden funcional?

Si es verdad que el agua cambia a la par que nuestro pensamiento, iremos más allá y pensaremos, por qué no, cómo alterar el rumbo de las cosas. El problema es que cada uno querremos cambiarlo en un sentido, y, entonces, ¿cómo se decantará el agua? ¿Será mejor actuar juntos pensando con unos mismos objetivos? Sin duda nuevos experimentos inundarán los artículos de revistas especializadas. Estaremos pendientes, y mientras tanto, seguiremos con nuestro pensamiento… siempre positivo.

Cambiar el mundo desde un teclado

Quienes tenían dudas sobre si era posible alterar el curso “natural” de la Historia, o quienes pensaban que las redes sociales no podrían ser sino un mero divertimento de adolescentes, se equivocaron. Se equivocaron cuando pensaron que un férreo mando conseguiría acallar a la multitud organizada en redes escondidas a la mirada de los fanáticos del poder, y también se equivocaron cuando pensaron que era imposible que un puñado de jóvenes de entre veinte y treinta años podría dar lugar a lo que ya se llama la Revolución del 25 de Enero, tras la cual ha sido depuesto el dictador Mubarak.

Esos Jóvenes del 25 de Enero, como ya se conocen en todo el mundo, fueron expandiendo por Internet poco a poco sus ideas, que finalmente han sido aceptadas por la mayoría. Esa mayoría que dicen es posible cambiar a partir de un número crítico de personas comprometidas con el cambio.

Por eso, cuando encontramos miradas socarronas o sonrisas de incredulidad entre algunos compañeros de nuestra propia empresa al hablar de la filosofía Scrum Manager, me divierto pensando en el poco tiempo que les queda para cambiar de actitud. Es imparable esta forma de pensar. Se tiende finalmente a construir equipos en los que se permita que aflore el talento de las personas. No podemos ya seguir manteniendo estratos que impidan que fluya la inteligencia en favor del negocio.

Vuelvo a mirar las imágenes de la tele, y ya no me parece imposible cambiar el mundo desde el teclado de este viejo ordenador.

Los mejores equipos no siguen metodologías

En el último viaje a San Francisco conocí ingenieros tanto de Google y de Apple, como de pequeños proyectos y startup’s (La gente de Apple cuenta muy poquito por las cláusulas de confidencialidad de sus contratos).

Aunque son empresas y equipos diferentes,sus formas de trabajar tienen dos cosas en común, que prácticamente ni se las cuestionan:

La primera: sus prácticas y métodos dan forma a principios ágiles: Trabajan desde una visión conocida y compartida por todo el equipo, no desde requisitos detallados. Avanzan de forma iterativa e incremental en incrementos cortos y breves, tomando feedback continuo…

La segunda: Pasan de metodologías y dogmas ágiles.

Y es que fijarse en la forma (en las prácticas) y no en el fondo (en los principios) es mirar al dedo y no a la luna a la que señala. La agilidad sin flexibilidad acaba siendo un dogma paradógico: enseñar cómo deben organizarse los equipos “auto-organizados” (?).  Es como aquello del “prohibido prohibir”

Me recuerda las conclusiones de Jared M. Spool en su conferencia de edui 2009:

  • Los mejores equipos no tienen una metodología ni siguen un dogma.
  • Los equipos con problemas a menudo intentan seguir una metodología, sin éxito.
  • Los mejores equipos exploran nuevas técnicas de trabajo de forma continua.
  • Los equipos con problemas tienen un repertorio de técnicas fijo y limitado.

Así era la primera implementación de Scrum para Software

Scrum es el término dado por Nonaka y Takeuchi al método de desarrollo de nuevos productos realizado con equipos reducidos, multidisciplinares, que trabajan con comunicación directa y empleando ingeniería concurrente, en lugar de ciclos o fases secuenciales.

Esta forma de trabajo logra niveles de eficiencia y valor en el producto superiores a los obtenidos con ingeniería secuencial y producción basada en procesos. En los 80, Nonaka y Takeuchi analizaron esta forma de producción, observando cómo trabajaban los equipos de las empresas tecnológicas que lograban mayores niveles de eficiencia y valor en sos productos(“New New Product Development Game“): Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.

Diez años más tarde Ken Schwaber presentó en OOPSLA (1995) la descripción de la implementación de Scrum para software que él empleaba en el desarrollo de Delphi.

Las implementaciones de Scrum para desarrollo de software se vienen enriquecendo desde entonces, y poco tienen que ver las implementaciones actuales con la original de Ken. Ahora es muy raro que alguien configure un campo de Scrum con los controles originales (paquetes, cambios, riesgos, soluciones…) el Backlog único ha evolucionado a Backlog de producto y Backlog de Sprint. También es habitual usar un backlog estratégico o “Epics” de producto. La evolución añadió a la reunión de revisión de sprint, otra de inicio; y más tarde otra de retrospectiva. Tampoco se suele usar la fase de cierre, etc.

También la prácticas se han enriquecido. En 2001 apareció el gráfico burndown, más tarde empezó a ser habitual el uso de estimación de póker, luego tableros de control visual kanban…

Para dar una visión de retrospectiva, este es el “paper” de Ken Schwber presentado en 1995  su implementación de Scrum en OOPSLA: “SCRUM Development Process ” y este otro su artículo del mismo año “Living on the Edge” en el que describía su implementación de Scrum para Software.

Como adelanto, esta sería la traducción de  la “metodología” y su fases:

Los primeros en observar diferentes implementaciones de SCRUM para el desarrollo de nuevos productos con alto rendimiento fueron Takeuchi y Nonaka (1) en Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, y Hewlett-Packard.
Coplien ha seguido y documentado un enfoque similar para el desarrollo de software en Borland, logrando la mayor productividad con C++ (1). Recientemente, Jeff Sutherland ha aplicado un enfoque más refinado de SCRUM en Smaltalk, y Schwaber en el desarrollo de Delphi.


Llamamos a este enfoque metodología SCRUM (véase Takeuchi y Nonaka, 1986) por el uso del término SCRUM en rugby –la formación cerrada que forman los delanteros para realizar el avance-

Scrum es una metodología para mejora y mantenimiento de un sistema existente o la producción de un prototipo. Se asume la existencia de diseño y código en su mayor parte  orientado a objetos, basado en librerías y clases. SCRUM gestionará la reingeniería completa posterior  de sistemas heredados.
…..

FASES DE SCRUM

SCRUM comprende las siguientes fases:

» Read more..

De la visión a la tarea: niveles de requisitos ágiles.

Visión - Temas - Epics - Historias - Tareas

La clave de la agilidad

Estamos descubriendo formas mejores de desarrollar software tanto por nuestra propia experiencia como ayudando a terceros. A través de este trabajo hemos aprendido a valorar:

Individuos e interacciones sobre procesos y herramientas

Manifiesto ágil

Scrum Manager: Alternativa Hispana sin Complejos

Scrum Manager es una visión de scrum amplia y flexible:  la original de Nonaka y Takeuchi,  diferente a la implantación concreta de la Scrum Alliance.

Scrum Manager y Scrum Alliance no son lo mismo. Las características de flexibilidad,  globalidad, y síntesis entre la agilidad y el conocimiento anterior (CMMI, 15504…) así como la difusión abierta, y condicionada a la calidad son aportaciones de Scrum Manager, o cuando menos, otra forma de interpretar los entornos de trabajo que Nonaka y Takeuchi llamaron “campos de scrum(1)hace 25 años, y de compartirlo y difundirlo.

Convencidos de que es un error monopolizar el concepto de campo de scrum. De que se encorseta y se empobrece al trocar los principios básicos(2) por prácticas determinadas de sprints, backlogs y reuniones; y de que se podían aportar mejoras sustanciales a lo carísimo del modelo “comercial” de formación scrum, y al criticado certificado scrum master, Claudia y el que suscribre nos decidimos a no sólo hablar de alternativas, sino a construirlas.

Y como, “¿Cuál es la diferencia con Scrum Alliance?” o “¿Qué aporta?”,  son preguntas frecuentes, cuando no críticas, :-( estas son, contadas con brevedad y objetividad, las razones y mejoras aportadas con  Scrum Manager:
1.- MEJORABLE: El enfoque de Scrum en el área de gestión de proyectos está bien, pero un “campo de scrum” implica también al área de programación o desarrollo de producto y también a la gerencia y dirección de la organización.

APORTACIÓN: Scrum Manager contempla tres áreas de conocimiento: Proyecto, Producto y Gerencia.

2.- MEJORABLE: La formación de Scrum Master sólo muestra las prácticas scrum de la Scrum Alliance.

APORTACIÓN: Scrum Manager presenta una síntesis de conocimiento entre procesos y agilidad: un enfoque objetivo mostrando la agilidad como antítesis de los procesos y las posibilidades que la síntesis de los dos conocimientos da a un gestor: como “criterios de gestión” en lugar de “recetas de actuación”.

3.- MEJORABLE: La formación de Scrum Alliance tiende a hacer olvidar el concepto original de campo de scrum y monopolizar scrum como las prácticas que ella misma define,  empobreciendo las posibilidades de implementación de cada campo de scrum de la forma más adecuada a cada organización.

APORTACIÓN: Flexibilidad. Es un principio de Scrum Manager: adecuar las prácticas ágiles a la empresa, y no al revés.

4.- MEJORABLE: Los certificados de la Scrum Alliance se obtienen sólo por pagar los 1.000€ o más que vale el curso de 2 días. Puede acudir una persona sin entender inglés a un curso scrum manager dictado en inglés, no entender nada y sin ningún examen ni comprobación lograr la certificación  Scrum Master.

APORTACIÓN: Un modelo enfocado en la formación, que permita incluso lo contrario: poder aprender y obtener un certificado acreditando que se sabe, de forma gratuita. (http://www.scrummanager.net/ok). Los certificados de Scrum Manager requieren un examen y actualmente un 20% de los presentados los suspenden y no obtienen la certificación.

5.-MEJORABLE : Servicios profesionales presenciales (franquiciados) centrados en el negocio, que exigen una tasa de franquicia para dar formación, generando como consecuencias: a)encarecimiento de los costes normales de un curso presencial, b) formadores más centrados en el negocio que en los resultados de los alumnos.

APORTACIÓN: modelo partnership de Scrum Manager sin canon de entrada ni cuota de mantenimiento. Concesión otorgada y mantenida por la valoración de calidad de los cursos (http://scrummanager.net/qa). Consecuencia: los formadores tienen como principal interés ofrecer formación de calidad, (la valoración media de los cursos presenciales actualmente es > 8 ) y el modelo garantiza que un formador que no ofrece calidad no puede trabajar con Scrum Manager.

6.-MEJORABLE:  Modelo de certificación “parco”. Me explico: con dos días de formación, (aun suponiendo que sea de calidad y con examen) ya se es “ágil certificado” (?), sin marcar ningua apreciación de grado. Un profesional puede, además de conocer del scrum rígido de la Scrum Alliance,  saber también de gestión de equipos, producto, recursos humanos, cultura ágil, o de prácticas de programación ágiles: integración continua, TDD, etc… Decir que una persona es Scrum Master, no es decir mucho de cuánto sabe de agilidad.

APORTACIÓN: Modelo de certificación con puntos de autoridad. La certificación Scrum Manager va vinculada a un grado de autoridad, que es proporcional a las áreas de conocimiento acreditadas.

He intentado sintetizar, y escribiendo un poco a vuela pluma. Seguro que me dejo cosas, pero creo que en conjunto este es el mapa general de razones y diferencias entre Scrum Alliance y Scrum Manager.

(1) “Moving the Scrum Downfield” – The New New Product Development Game. (Hirotaka Takeuchi and Ikujiro Nonaka. 1986)
(2) Built-in instability – Self-organizing project teams – Overlapping development phases – Multilearning – Subtle control – Organizational transfer or learnig.

Agilizando CMMI

Con los principios de Scrum Manager de síntesis del conocimiento, y adopción global y flexible, esta estas son las diapositivas de la charla “Agilizando CMMI” que presentó José Manuel Navarro en el CITIC de A Coruña.