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.
Hace algo menos de un año comentaba: "En este sector, un profesional sin formación continua está "out" en menos de 5 años, y aunque hay nuevas formas de difundir y compartir conocimiento, se siguen empleando sólo modelos de formación económicamente pesados, que limitan el acceso."
Otro problema de la formación presencial es que el precio por cursos de uno o dos días resulta prohibitivo.
Y también son ya una realidad los primeros cursos presenciales Scrum Manager (Flexibilidad con Scrum) de 100 a 200€ en hispanoamérica y de 200 a 300 en España, incluida certificación con examen; y que se están completando a las pocas semanas de anunciarse :-) Ya los hay en Tenerife, Barcelona, Madrid, Buenos Aires, Valencia, Córdoba (Argentina), San José...
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 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.
No nos gusta aprender recetas, porque no creemos en "balas de plata". Preferimos aprender nutrición: ser cocineros y no pinches. Saber cocinar nuestras propias recetas, con el sabor, vitaminas, nutrientes y presentación, más adecuados a nuestra empresa.
Scrum Manager: Preferimos la flexibilidad a la rigidez.
Primero fue con los campos de scrum; el scrum entendido y definido por Nonaka y Takeuchi, y que aunque posiblemente es era el mejor marco para implementar ciclos ágiles de desarrollo, lo hemos dejado debidamente domesticado: monopolizado, y atrofiada su evolución. Tardamos 10 años, en descubrirlos y aplicarlos a nuestros proyectos de software; pero luego, enseguida lo hemos "doctrinalizado"(1).
Los modelos que dan el protagonismo de la producción al conocimiento depositado en los procesos y la tecnología , "externalizan" en ellos el conocimiento que hace posible la calidad y repetibilidad de los resultados. Las personas que ayudan a ejecutar los procesos aprenden "internalizando" el conocimiento.
Cuando se trabaja con modelos ágiles, como el conocimiento empleado no es el de los procesos y la tecnología, sino el de las personas, resulta difícil (y posiblemente no sea recomendable) aplicar el mismo patrón: externalización-internalización, documentando y procedimentando. Lo normal en este caso es la "socialización".
Me parece especialmente gráfica la descripción que hacía Fabio en el foro de Scrum Manager en LinkedIn la semana pasada, al comparar una y otra forma de transmitir el conocimiento, desde el punto de vista de un agilista:
Con 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.
120 técnicos en 11 equipos ágiles, distribuidos entre las oficinas de Reykiabik, Atlanta y China. Es el equipo de ccpgames que programa y mantiene eve online y así es el campo de scrum que han diseñado para su empresa:
Las responsabilidades del producto están asignadas a un "Master Product Manager" y un grupo de "Product Managers". Cada uno toma información de diferentes áreas del producto y la principal tarea del grupo de dirección de producto es mantener la visión, darle forma y prioridad al backlog del producto, y transmitirla y comunicarla a todos los equipos.
Estas son las diapositivas que empleó esta semana Agustín Villena en la presentación "La Cultura ágil y su ecosistema" en las Jornadas Regionales de Software Libre en Santiago de Chile. Una visión de la agilidad poco frecuente: no desde las prácticas concretas, sino desde la cultura que implica y el ecosistema que necesita para dar resultados.
Habíamos previsto 40 como máximo para el primer curso de Scrum en la plataforma libre que estamos construyendo, y la matrícula no duró ni un día, porque cuando nos quisimos dar cuenta ya había 70 inscritos.
El viernes terminó el curso. De los 70, 50 han aprobado y pueden acreditar su nivel de conocimiento, que no de pago :-) y de los 43 que han respondido a la encuesta de valoración, más de la mitad nos ha dado un sobresaliente, y el resto un notable, además del montón de comentarios que hacen que nos pellizquemos al leerlos (1)
¡¡¡ Muchas gracias !!!
Es la mayor recompensa, y el mejor impulso para seguir adelante.
Pomodoro es una práctica, o técnica para la gestión ágil del trabajo individual. Se podría decir que Pomodoro es al individuo, lo que Scrum al equipo.
Su autor, Francesco Cirillo, lo bautizó con este pintoresco nombre, por ser un temporizador de cocina con forma de tomate, la herramienta que recomendaba en su primer manual para medir los ciclos de trabajo de 25 minutos que son el elemento central del método y que a su vez, se llaman: "pomodoros" :-)
Es una práctica bastante solvente para aplicar principios ágiles en la gestión personal del tiempo y las tareas: ejecución de las actividades de forma iterativa e incremental centrada en el concepto de "timeboxing": intervalos de tiempo fijos, e indivisibles; que en este caso son los pomodoros de 25 minutos.
Ya está "peinada" la documentación y las diapositivas para el curso de Scrum en la plataforma de formación abierta de Scrum Manager. Las pongo aquí, que pueden ser útiles para consulta o auto-formación; y los que queráis seguir el curso de e-learning... A partir del 7 de septiembre lo implartirá Claudia en OK-SM (Open Knowledge - Scrum Manager) , y la matriculación estará disponible desde el día 1... es libre! e incluye además un examen para poder obtener la certificación de 25 puntos de autoridad Scrum Manager.
Scrum, entendido como los principios ágiles de organización del trabajo definidos por Nonaka y Takeuchi. O sea los "campos de scrum",es posiblemente el mejor marco para implementar ciclos ágiles de desarrollo.
El "Scrum" de la ScrumAlliance y de los ScrumMaster: el "Scrum" cerrado en el que, como si fuera el Corán, nada se puede cambiar, además de ser un modelo de negocio piramidal sin escrúpulos, es una amenaza para SCRUM.
Esto no es muy nuevo en Navegápolis (1) , y por descontado, que decir segun qué cosas en un blog corta el malentendido "buen rollito" y cierra algunas puertas; pero mantiene la conciencia tranquila, y anima a construir soluciones. A aportar formación que no sea costosa: libre, y que de verdad acredite el conocimiento. (OK-SM).
Por eso me ha parecido muy valiente el artículo, nada menos que de Scott Ambler. (2). Me he sentido menos solo al leer a alguien de su talla, decir también sin ambages que el emperador está desnudo.
Hacer de una empresa un campo de scrum implica a toda la organización, no sólo a los programadores, o a la gestión de proyectos. Las organizaciones son realidades sistémicas, interrelacionadas.
Olvidemos, o desaprendamos (y si no lo conoces, mejor que mejor) eso de que scrum funciona con tres roles: propietario de producto, scrum master y equipo.
El grado de éxito de la implantación ágil en la empresa no depende tanto de implantar unos roles, sino de asignar con solvencia las responsabilidades necesarias en la organización para que se desarrolle la agilidad; y las que se deben cubrir de forma coordinada y alineada con la visión de la organización pertenecen a tres categorías clave: