Para producir de forma ágil, sólo hay un factor imprescincible. Uno sin el que cual no es posible. Y sin embargo, solemos centrar la atención y formación en lo accesorio.
Hace algo más de cuatro años apuntaba aquí en Navegápolis, que el interés por CMMI y Agilidad se estaba igualando, teniendo en cuenta las consultas realizadas en Google:
Navegápolis, mayo 2006
Visto así (y con el riesgo que tiene interpretar estadísticas):
Ahora mismo se están igualando los intereses (volumen de consultas) de ambas tendencias.
Si
continúan la tendencia descendente de CMM y la ascendente de la
Agilidad, en los años futuros se van a invertir los protagonismos.
El volumen de noticias sobre agilidad es mayor y con tendencia ascendente
Repitiendo cuatro años más tarde el mismo experimento el resultado confirma que se ha producido la caída del interés por CMMI y el incremento por la agilidad:
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.
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.
Robert Johnson, director de software de Facebook, afirma que de los 7
principios clave que han hecho posible al equipo de programación dar
respuesta al ritmo de crecimiento del proyecto, 5 tienen que ver con las
personas y su cultura de trabajo en equipo.
Estos son los números de Facebook a fecha de hoy:
500 millones de usuarios activos.
100 mil millones de hits diarios.
50 mil millones de fotos.
2 trillones de objetos cacheados, con cientos de millones de peticiones por segundo.
Respuesta rápida.
"La mejor manera para lildiar con las sorpresas continuas es tener
equipos de ingeniería y operaciones que sean flexibles para poder
resolver los problemas rápidamente. La capacidad de respuesta rápida
también nos permite pobar muchas cosas para ver cuáles funcionan
realmente en la práctica. Hemos encontrado que el mantenimiento de esta
flexibilidad es mucho más importante que cualquier decisión técnica".
Cambios incrementales.
Este principio va más allá del principio de evolución de producto ágil:
iterativa e incremental. Se refiere también al despliegue y puesta en
producción:
"Tratamos de desplegar de forma incremental. Esto puede significar para
unos pocos usuarios, o para una pocas máquinas a la vez, o incluso la
construcción de un nuevo sistema en su totalidad en paralelo con el
antiguo, y desplazar el tráfico poco a poco, mientras medimos los
efectos".
Equipos pequeños e independientes.
"Tenemos tres personas que trabajan en fotos. Cada una de ellas conoce
todo lo relativo a fotos perfectamente y puede tomar decisiones al
respecto, así que cuando hay que cambiar algo relativo a fotos lo
podemos hacer rápidamente y bien".
Control y responsabilidad.
"Ninguno de los principios anteriores funciona sin equipos de ingenieros
capaces de trabajar y resolver problemas, juntos y sin problemas.
Esto es mucho más fácil de decir que de hacer, pero tenemos un principio
general que es tremendamente útil: La persona responsable de hacer un
trabajo debe tener control sobre él".
Nos gustan mucho los campos de scrum, y para aportar un modelo de formación asequible y una certificación que no se logre sólo por pagar, que pueda conseguirse incluso gratis, pero que realmente acredite el conocimiento, nos pusimos manos a la obra, ahora hace sólo un año: Primer Año de Scrum Manager .
Aún está bastante tierno esto de cribar la red con criterio semántico, pero empieza a tener su gracia. Si le preguntas a Google Squared por prácticas ágiles, la respuesta en el momento de escribir este post es:
Integración continua
TDD
Scrum
Refactorización
XP
RUP
Flirting
Programación en parejas
Testing
Historias de usuario
Nota: No darle más valor del que tiene como curiosidad. A mi por ejemplo RUP me chirria un poco como ágil, y con Flirting no se está enterando muy bien. Allá cada uno :-)
"El auge de los denominados sistemas de Business Intelligence (BI o sistemas de inteligencia de negocio), está haciendo que en los últimos años se estén dando muchos proyectos de implantación de dichos sistemas BI. La gran mayoría de dichos proyectos (85%) han fracasado en conseguir sus objetivos...
...Por otra parte y de forma paralela, las metodologías ágiles de desarrollo de software están teniendo un gran auge y están dando buenos resultados en ámbitos en los que otras metodologías más convencionales habían mostrado limitaciones en su aplicación. Así pues, si juntamos la inmadurez de la disciplina de BI con la orientación práctica de los enfoques ágiles, podríamos obtener un resultado final más satisfactorio....
...Sin embargo, todas las herramientas de IT Governance actuales siguen centrándose en las estructuras y los procesos. Es necesario que, además existan mecanismos eficaces que fomenten la relación, comunicación y colaboración entre las personas de la organización, en contexto pautado de las estructuras y los procesos..."
Citas del artículo "Agile Business Intelligence Governance: Su justificación y presentación", de J. Fernández, E. Mayor y J.A. Pastor", que analiza la relación entre los 6 factores considerados clave para el éxito de una implantación de un sistema BI, y los principios ágiles. Bueno, hay cosas en las que seguro, cada uno estamos más o menos de acuerdo, pero qué duda cabe que las organizaciones son sistemas realacionados y que la síntesis entre los procesos y la agilidad está servida en todas las áreas.
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.