Archive for

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..

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.

Scrum no es un proceso.

En Scrum, a diferencia de los modelos de procesos, (CMMI, ISO15504…) la calidad del resultado no depende de la calidad el proceso, sino de las personas.

Si una pianola no suena…  es una mala pianola.

No ocurre lo mismo con los pianos.

Kanban Boxes: campos de scrum en oficinas multiproyecto

Implantar un campo de Scrum para un único equipo de 4 a 8 personas, que trabaja en el desarrollo de un único sistema es un “caso de libro”. No hay más que “copiar y pegar” las prácticas tradicionales de scrum de Ken Schwaber y Jeff Sutherland.

Pero en las empresas en las que nos movemos son bastante habituales los entornos multiproyecto, y “equipos” mínimos de tres, dos, o incluso una persona, y como flexibilidad consiste adaptar las prácticas a nuestra circunstancia y no al revés, os comento una práctica, de invención propia, que me está funcionando razonablemente bien, y que me ha dado por llamar “cajas kanban” o “kanban boxes”, que parece que inglés siempre mola más ;-)

Mantiene los principios de “time boxing “, Seguimiento diario del avance, comunicación directa y visual, pero no hace dependiente el avance iterativo de ciclos temporales o “sprints” sino simplemente de nuevas funcionalidades, y es válida para entornos multi-proyecto, y también más aconsejable que el ciclo Scrum clásico para equipos muy pequeños (3 personas o menos)

¿Qué es una caja Kanban o una Kanban Box?

La descomposición y estimación de una funcionalidad o historia de usuario en las tareas que la componen, con un formato visual y simple (Kanban) y un indicador de avance diario ágil:

Y a partir de aquí, en función de cómo es nuestro equipo y los proyectos en los que estamos, vendría la gestión ágil: el arte de lo posible: cuál es el mayor valor que puede entregar el equipo de la empresa, con los criterios de prioridad de los responsables de producto, en el menor tiempo posible. Un ejemplo de uso:

Kanban Boxes

1.- Las diferentes pilas de producto se priorizan entre los diferentes “propietarios”, y teniendo en cuenta la capacidad de desarrollo. del equipo total de la empresa…

2.- …se van “encajando” las historias más prioritarias, y por tanto las próximas que van a entrar en producción.

3.- Cada caja constituye en sí un incremento para construirse de forma completa y operativa, y queda encolado a la espera del próximo “slot” para entrar en desarrollo.

4.- Al entrar al tablero Kanban de desarrollo, se calcula la velocidad prevista en función de la personas(s) que se la han asignado y a diario se actualizan las tareas y los indicadores de avance: el teórico y el real.
Ej: la caja tiene un tamaño de 35 puntos. Se la han asignado 2 personas y por la media de velocidad en la empresa (p. ej.: 4 puntos persona /día) la velocidad prevista de avance serían 8 puntos /día. Cada día se borran 8 puntos de la barra de velocidad teórica, y se actualiza la barra de velocidad real con los puntos que realmente queden por hacer.

Kanban Boxes

Para la comunicación en los puntos 1 y 2: priorización de la pila general de la empresa entre los diferentes propietarios, y descomposición y valoración de las tareas, respetad los principios ágiles de comunicación directa (socialización) y conocimiento y aportación conjunta del equipo a la visión del producto, estableciendo reuniones de características similares a las de inicio de sprint del ciclo clásico de scrum con los criterios de momento y participantes más adecuados según cada empresa.

Espero que os sirva de idea… Bienvenidas las sugerencias y mejoras!

La agilidad crece sola, y gusta.

Uno de cada tres programadores, o gestores que trabajan directamente en proyectos de programación usan metodologías ágiles, y las han incorporado por propia iniciativa, no por instrucciones “corporativas”. La implementación se produce “motu proprio” en equipos que trabajan en la misma planta o en el mismo edificio.  La metodología más empleada, con mucho, es Scrum; y la mayoría de los que las emplean hablan bien de ellas, y creen que han mejorado la comunicación en el equipo, la velocidad en el cierre de versiones y la flexibilidad en el diseño.

Estas son las principales conclusiones de uno de los pocos estudios realizados sobre una muestra de técnicos, significativa (492 encuestas anónimas). Lo realizó Microsoft hace 2 años entre su personal de EE.UU, Europa y Asia, para analizar el grado de “contagio” de agilidad que estaba teniendo la empresa, la opinión de los técnicos y los resultados.

Prácticas ágiles empleadas

Prácticas ágiles empleadas

Grado de satisfacción por el uso de prácticas ágiles

Grado de satisfacción por el uso de prácticas ágiles

BDD: la evolución del Desarrollo Dirigido por Tests (TDD)

Poner las pruebas (el testing) delante de la programación ha marcado un hito en las prácticas de programación, un antes y un después, que ha transfromado a la “cenicienta” del testing en princesa; de trabajo indeseado (probar lo que iban terminando los programadores) a tarea “cool” de diseño y pre-codificación.

TDD ha hecho que sean las pruebas las que tracen la pauta al desarrollo, y no al revés, y al hacerlo ha abierto dos dimensiones nuevas al testing tradicional: documentación, y sobre todo: diseño:

  • Se empiezan a escribir pruebas unitarias con herramientas como JUnit o NUnit.
  • Empieza a aumentar la confianza en el código, en la misma proporción que el volumen de pruebas que se va generando.
  • Al escribir las pruebas en primer lugar, el código gana simplicidad, programándose lo extrictamente necesario.
  • Las pruebas van tomando una nueva dimensión: “documentación”, porque cuando se retoma código ya olvidado,  son las que mejor explican qué es lo que hace ese código.
  • Poco a poco se empieza a descubrir la segunda dimensión: desarrollar pruebas revela el “API” del código, y pasa entonces a ser también un proceso de diseño.

A partir de este punto se empieza a plantear olvidar el origen de TDD, quitar el foco del “testing” de unidades de código, y llevarlo hacia diseño y comportamiento funcional, pasando de TDD a BDD (Behaviour Driven Development)

Básicamente es lo mismo, pero con unos cambios clave: La unidad de prueba ya no es una unidad de código (unit) sino un comportamiento. Los estados pasan a comportamientos y los marcos “xUnit” a “rSpec”.

La verdad es que en nuestra industria la espiral de conocimiento está girando muy deprisa. Si tuviéramos que dibujar su avance en el campo del testing podría ser algo así:

Evolución del testing

Más información

Herramientas BDD

Scrum Manager: Campo de Scrum en toda la empresa

El concepto original “Campo de Scrum” definido por Nonaka y Takeuchi describe un entorno de trabajo con principios ágiles en equipos motivados, con delegación y  “empowerment”, que desarrollan proyectos de forma iterativa a incremental, que no dividen el ciclo de desarrollo en fases, comparten el conocimiento por socialización (comunicación directa)…

La implementación de un campo de scrum no depende de las prácticas empleadas (Backlog Burndown / historias de usuario / Etiquetas kanban …) o del ámbito de aplicación (proyecto, producto o empresa).

La implementación que Jeff Sutherland realizó en 1993 en su equipo en Easel Corporation, a nivel de proyecto, que Ken Schwaber  documentó, en el libro Agile software development with scrum y que difunde la Scrum Alliance, es una implementación concreta, como lo son tambien cada una de las desarrolladas originalmente por Canon, NEC, Xerox, hp, Honda,  Epson… Es buena, pero nada impide diseñar un campo de scrum con flexibilidad en las prácticas para  adecuarlas a cada realidad, y con ámbito de proyecto, producto o de empresa, según sea para un equipo, departamento (por ejemplo de I+D en una software factory de procesos), o de organización en su conjunto.

Tomando el concepto original de Scrum y “des-monopolizándolo” de la Scrum Alliance, es posible plantear implementaciones con diferentes prácticas y también a nivel de producto o de empresa. Con esta visión de Scrum Manager la agilidad da su mejor resultado cuando se implican y alinean los diferentes ciclos de la empresa: estratégico, proyectos y producción.

» Read more..

Motivación: mejor intrínseca que extrínseca

Scrum Manager bit: La motivación extrínseca es adecuada en trabajos relativamente mecánicos y entornos industriales, pero puede ser contraproducente en empresas del conocimiento.

Ambiente Industrial Campo de Scrum
Los principales responsables de la calidad del resultado son los procesos y la tecnología Los principales responsables de la calidad del resultado son las personas
Fábrica

cc by cloneofsnake

campo_scrum

cc by Dan Zen

Las personas ayudan a los procesos y la tecnología Los procesos y la tecnología ayudan a las personas
La mayoría de principios y prácticas de gestión en cualquier nivel y en sus relaciones (empresa, proyecto o producto) son diferentes.
La motivación extrínseca es una prescripción relativamente válida para los primeros, y  normalmente contraproducente para los campos de Scrum.

Safe Creative #1001035242501

¿Modelo de Madurez de la Capacidad de los equipos?

equipo_baloncesto_1909Con el principio de calidad de Juran, el protagonismo del resultado lo tienen los procesos: “La calidad del resultado depende de los procesos empleados en su fabricación”

Con el principio de agilidad, el protagonismo del resultado lo tienen las personas trabajando en equipo: “Preferimos el valor de los individuos y su interacción, por encima de los procesos y las herramientas”

La apuesta de aplicar el primer principio para mejorar los resultados de la fabricación de software, viene desarrollando desde los 90 modelos de “Madurez de la Capacidad de los Procesos” (CMM’s) tomando por capacidad de un proceso, el grado de eficiencia con el que logra el resultado que se espera de él.

Parece lógico pensar que sobre el principio de agilidad se debería desarrollar la “Madurez de la Capacidad de los Equipos”  (MMCE… ¿Modelo de Madurez de la Capacidad de los Equipos?)

Aunque pueda parecer lo contrario, los procesos son fáciles, la agilildad no.
Aplicando las prácticas del modelo CMMI se logran los objetivos de las áreas de procesos y con ellos, procesos de alta capacidad.
Aumentar la capacidad de las personas, y de éstas trabajando en equipo es algo más complicado. Aplicando prácticas ágiles no se logran equipos de alta capacidad.