Índice de contenidos.
Introducción
Una vez leí sobre un concepto que se llama iluminación: Consiste en que una persona tiene tan claro cómo hacer las cosas que cuando se acerca a otro grupo piensa que va a ser extremadamente fácil llevar a cabo una tarea porque para esa gente va a ser tan evidente el camino como para él mismo (supongo que tiene que ver con un sesgo de proyección).
En muchas conferencias sobre agilismo veo a grandes profesionales que han decidido salirse del mundo de la gran empresa y se han establecido por su cuenta para ayudar a pequeñas organizaciones o para emprender, por lo que han dejado atrás los grandes problemas de las corporaciones. Pueden fácilmente definir un modelo de trabajo, la tecnología que más les apetezca y, a través de dinámicas ágiles (como las retrospectivas), introducir nuevas técnicas con facilidad. Obviamente, esto es grandioso. ¡Bien por los que tienen esa suerte! (incluso nos pasa internamente).
Ahora bien, imagínate que una persona que ha huido de las grandes compañías y tiene este contexto semi-idílico, se va a una gran corporación a hacer coaching de implantación de métodos ágiles… ¿que crees que puede pasar? Si no es consciente de este efecto de iluminación corre el riesgo, como poco, de la frustración.
En las grandes corporaciones se pueden dar algunos de los siguientes casos, o todos a la vez:
- El cliente (product-owner real) de negocio es fuerte y está lejos de las áreas de tecnología, incluso en otros edificios. Algunas veces ni tan siquiera está identificado claramente quién es.
- Se crea un middle-management (como oficinas de proyecto, áreas de racionalización de demanda, arquitectura, etc.) que ni construye ni tiene poder para aceptar o priorizar (product owner-proxy). No saben muy bien cómo afectará a su parcela de poder estos nuevos modelos. Si sólo hay 3 perfiles: dueño de producto, scrum master (o coach) y equipo ¿esto significa un paso atrás o un paso adelante en su carrera?.
- Los desarrollos se subcontratan, normalmente a coste fijo, a proveedores históricos que han sido apretados hasta la saciedad por áreas de compras, con penalizaciones dolorosas. La función de compras es conseguir más por menos y, cuando no ha habido diferenciación de proveedores, no acaban de entender otros modelos de contratación ni tampoco otros rangos de tarifas de personal altamente experto.
- Los proveedores no quieren ni oír hablar de agilismo porque es otro factor más de riesgo: llevan ya años trabajando de un modo y, aunque malo, es conocido. Con proyectos a coste fijo, ¿qué van a significar ahora conceptos como «Aceptar el cambio»? ¿que se van a tragar más cosas gratis?
Por tanto, implantar metodologías ágiles en grandes corporaciones va a costar. Es más, como a todo el mundo se le está llenando la boca con el agilismo, se está utilizando sin criterio para seguir trabajando como antes pero incorporando únicamente unas pocas prácticas simples. Cuando los proyectos fracasen o no se vean los resultados, alguien empezará a hablar de «la gran mentira del agilismo» (¿apostamos a que dentro de un tiempo alguien escribe ese artículo?).
Las metodologías ágiles creo que son lo más revolucionario que ha pasado en el mundo del desarrollo de Software en muchos años, que incluso sobrepasa a las áreas de desarrollo y las da más valor.
Disciplined Agile Delivery (DaD)
Este verano he decidido hacer un «master personal» y voy a leer todos los libros que me dé tiempo sobre agilismo corporativo, toma de requisitos ágiles y temas similares; convencido de que de todos aprenderé algo. Haciendo esto en tu cerebro las ideas además se juntarán de un modo único, que generarán seguro nuevo conocimiento.
Podéis encontrar gran parte del contenido del libro en el portal Discipline Agile Delivery. Si leéis entre líneas veréis que ya hay formación y certificación sobre el tema.
También podéis ojear el contenido y esquemas interesantes en la previsualización del libro en Google Books.
DaD adopta estrategias de: Scrum, XP, Agile Modeling, UP, Agile Data y Kanban. Con esto entenderéis que resumir el libro sería como escribir otro. Tiene más de 500 páginas con muchísima información.
Yo no voy a hablar del libro desde su estructura, sino sobre cosas que creo que pueden serme útiles o que me han invitado a un pensamiento cruzado.
Describe 3 fases en un proyecto: Inception, construcción y transición. Esto encaja de un modo muy sensato con la realidad de las empresas. Hay una fase de definición de un proyecto y gestión de la demanda; se construye iterativamente; se pone en marcha y opera en producción, generando necesidades para otras iteraciones. En grandes corporaciones esto lo hacen grupos distintos.
Para entender el planteamiento globalmente podéis ver este diagrama.
Primer contacto
Alguna de las cosas que me han gustado nada más empezar es la referencia a otro libro: Agile Career Development Lessons Approaches. No lo he leído todavía pero puede dar ideas, sobre todo porque es un tema que está provocando interés y, de hecho, hace poco se propuso como tema de trabajo en una reunión de Agile Madrid: Recursos humanos ágiles.
Algo grandioso es que se trata de un libro de IBM Press y lo firma Scott W. Ambler (y Mark Lines) y en el prólogo de Dave West (firma como Forrester Research) dice: The process wars are over, and agile has won. Recapacitemos: Una de las empresas más grandes y relevantes del mundo publica un libro, apoyado por un experto de Forrester diciendo que agilismo es el camino. Cada vez que nos acerquemos ahora a un cliente final y sus proveedores (sobre todo si son el propio IBM), deberíamos decirles que se lean este libro y en concreto esa frase.
Todavía me llaman potenciales clientes diciéndome las pegas que le ven y las que les ponen los proveedores, que su organización no está preparada, que todavía hay que validar el modelo, etc…
Ahora le sumas las estadísticas del CHAOS Manifesto del Standish Group comentadas por verdaderos maestros como Mike Cohn, y a ver qué te cuentan: los proyectos con éxito pasan del 14% al 42% comparando waterfall con agile. A éstos números también hace referencia el libro DaD.
Por estas cosas ya merece la pena tener el libro.
Hace referencia constantemente a surveys, os recomiendo echarle un vistazo.
Sobre el contenido
Habla de Agile Scaling Model.
Parece sensato que, en base a la dimensión de la organización, influyan distintos factores y haya que poner en marcha distintas prácticas y disciplinas. En una gran corporación hay un portfolio de proyectos, una estrategia de puesta en producción (con coordinación de distintas áreas), una arquitectura tipo a la que se quiere ir, un interés por el re-aprovechamiento de esfuerzos, etc…
Esto no significa sólo tener un equipo auto-organizado, motivado y preparado. Son muchos equipos haciendo muchas cosas y con dependencias entre ellos. Equipos que lleva tiempo componer y formar y que hay que procurar que sepan lo máximo posible del mínimo de cosas: se busca homogeneidad para que en producción, soporte y mantenimiento no sean luego una locura, sobre todo cuando el experto que lo ha hecho ya no está y lo tiene que mantener otro.
En un equipo ágil, lo ideal es que en entre todos sus miembros posean los conocimientos y habilidades para desempeñar todos los trabajos. Aunque en Scrum se establecen los roles de product-owner, scrum master y equipo, es posible que haya otros roles.
Con múltiples equipos trabajando simuladamente, las decisiones arquitectónicas ya no pueden emerger tan fácilmente de la necesidad de uno en concreto: será necesario coordinar esas decisiones. Aquí es cuando oímos hablar (ya no en el libro) de Scrum o de reuniones de «arquitectos» de distintos proyectos.
Por tanto en una corporación es normal que surjan otros roles y cometidos estructurales.
Algo que comparto es la identificación de la figura de Team Leader. No sé si la entendemos igual pero creo que una organización tiene varios grupos técnicos, las personas dependerán jerárquicamente de alguien. Hay asuntos que trascienden a un equipo auto-organizado (no auto-gestionado) como, por ejemplo, que alguien no se sienta cómodo en el equipo, no aporte en él, no tenga la actitud adecuada, el equipo no esté equilibrado, etc… También hay otras tareas como pedir cursos de formación a proveedores para cubrir necesidades de más de un equipo, transportar prácticas de unos equipos a otros, incluso evaluar la aportación y gestionar las compensaciones… Esto no se hace solo.
Voy a hacer mención a algunos puntos en concreto, pero fijaos que hay decenas de páginas de salto entre los comentarios: el libro tiene muchísimo contenido.
Propone cambios en el manifiesto ágil (pág. 27)
En el libro se propone que tras más de 10 años de experiencia podrían hacerse modificaciones al manifiesto ágil:
- Cambiar las referencias de desarrollo de software por entrega de soluciones.
- No centrar el interés en el cliente sino en stakeholders de un modo más general.
- No focalizar tampoco en el equipo de desarrollo sino en el ecosistema organizacional.
Por tanto lo que se hace es abrir o generalizar a estructuras más grandes.
Justifica con Lean la descentralización de todo el foco en la construcción de software (pág. 35).
En vez de mejorar la construcción de software se apoya en el principio Lean de mirar el todo. Hay que mirar la solución completa de entrega de funcionalidad al cliente: esa fase de transición y no sólo de construcción.
Reflexiona sobre el punto de realidad de la retórica ágil
Dice que muchos programadores interpretan el objetivo de mantener el diseño simple como una indicación para hacer todo desde cero y conseguir que la arquitectura emerja. Esto elimina la ventaja de lo que realmente hay ya construido. Considera que invertir tiempo previo en la arquitectura es una buena idea, adicionalmente a buscar el potencial de reutilización de activos existentes.
Habla del rol de Architecture Owner (pág. 77) y anti-patrones
Entre los antipatrones:
- Los arquitectos se han constituido como una nueva clase que no codifica. Imponen a los equipos de desarrollo en modelo command and control. La idea es que también construyan con ellos y abstraigan piezas.
- Muchas veces son buenos técnicos sin habilidades sociales.
- No pueden ser los product-owners.
- Habla del síndrome «no construido aquí» de tal modo que quieren que todo sea construido desde cero en la organización. Imagínate esto en compra de empresas y fusiones.
Invita a utilizar el método de Kanban para reuniones diarias con equipos grandes (pág. 92)
En los equipos Scrum se dedican 15 minutos para la reunión diaria de unas 10 personas y cada persona trata sobre los que se hizo ayer, lo que se pretende hacer hoy y los impedimentos que nos encontramos. Ahora bien, si tenemos 50 personas en un grupo ésta técnica ya no es tan efectiva. Parece más práctico plantear la reunión no tan basada en cada individuo sino alrededor de los impedimentos al flujo completo de trabajo.
Habla de problemas al implantar la disciplina ágil (pág. 102)
No contar con un mentoring adecuado. Los técnicos no nos caracterizamos precisamente por la humildad. Nos creemos capaces de resolver los puzzles que nos pongan delante con tiempo e Internet. El problema es que nos pegamos los mismos tortazos constantemente. Ir a una charla de 2 días o leerte 3 artículos no da demasiada base. Además, hablamos de gestión del cambio y no sólo de técnicas… ¿disponemos de esas habilidades?.
Coach y formación externo son vitales.
Hay muchas más cosas que hacer y gente con la que interactuar en una empresa aparte de escribir buen código (pág. 105)
Tratar con equipos no ágiles por dependencias técnicas o funcionales.
- Áreas de calidad y pruebas. Cuando se hacen entregas a producción hay entornos donde ni siquiera es fácil probar en entornos de desarrollo. Os pongo el ejemplo de compra y venta de acciones en tiempo real. Incluso por el posible impacto de un error puede ser necesario ejecutar todos los escenarios de prueba (que pueden afectar a desarrollos de varios equipos)
- Escritores técnicos. Imagínaos que haces producto y las guías de usuario se escriben en varios idiomas.
- Equipos de UX, que pueden trabajar directamente con los clientes de un modo poco ágil.
- Arquitectos corporativos: Imagínate que eres una delegación nacional de una empresa internacional. Hay más gente que opina sobre lo que haces además de tú mismo.
- Grupos de gobierno y oficinas de proyecto: Que trabajan a un nivel mucho más alto buscando el ROI incluso determinado qué líneas siguen, cuáles pivotan y cuáles se terminan.
- Administradores de sistemas: Los modelos de datos son compartidos por muchos desarrollos.
Apunta lecciones desde las trincheras sobre contratación (pág. 129)
El coste fijo incrementa el riesgo del proyecto. Es preferible fijar el coste y la agenda y dejar abierto el alcance. Si están bien priorizadas las historias se conseguirá una parte importante del producto sin rechazo de los cambios necesarios. Es la forma para hacer el mejor uso del presupuesto.
Comenta estrategias para elementos de trabajo y requisitos no funcionales (pág. 172)
Entre las estrategias están: la gestión formal de cambio, el scrum backlog, la pila de elementos de trabajo, la pila de calles (con distintas prioridades).
Respecto a los requisitos no funcionales propone una matriz de perspectivas distintas de la arquitectura y los riesgos asociados.
Cuenta cómo visualizar requisitos (pág. 265)
Propone modelos visuales como por ejemplo unos psuedo-diagramas de casos de uso de contexto, para facilitar el diálogo con los clientes y flujo de subsistemas.
Comenta patrones y anti-patrones de construcción (pág. 284)
Destacamos dos cosas de los patrones, que los periodos de iteración no deben cambiar y que cualquier stakeholder puede pasarse por el área de trabajo en cualquier momento y solicitar una demostración. La gracia es conseguir que se quieran pasar ;-).
Dentro de los anti-patrones cabe destacar: lista de trabajo demasiado grande para el Sprint, no atender los riesgos, asumir que la arquitectura funcionará sin código que sustente el papel, asumir que trabajar en ciclos cortos es trabajar ágil, que el personal trabaja en múltiples proyectos a la vez, no realizar reuniones previas a la de planificación para que la de planificación no sea un desperdicio de tiempo, que los defectos se incrementen cada iteración, etc.
Describe los múltiples criterios para la priorización de tareas (pág. 293)
Entre ellas el valor para negocio, riesgo asociado, fecha límite, emergencia en operación y dependencias. Esto puede chocar al principio con el concepto de que el que prioriza es negocio y el que estima es desarrollo. Supongo que negocio también tendrá que ser influenciado por la realidad.
Nos habla de sacar gente de los equipos como medidas de sanidad (pág 302)
Gente que no se encuentra bien en él, que no tiene las habilidades necesarias, por ser muy senior y trabajar con gente mucho más junior o al revés, alguien que no encaja en la dinámica…
Comenta distintas aproximaciones a la hora de entender y diseñar el sistema (pág. 327)
Un palabro cada vez más de moda es spike o prototipo técnico que puede posteriormente ser completamente desechado.
Comenta la importancia de obtención de métricas (pág. 347)
Pero éstas métricas tienen que obtenerse automáticamente para no desviar la fuerza de trabajo.
Podemos obtener métricas de calidad de código, de ruptura de builds, de avance de sprints y producto, etc…
Ofrece focalizar las retrospectivas (pág. 373)
Sobre todo en dos aspectos: aquello que el equipo puede resolver por sí mismo con facilidad y aquellas acciones más estratégicas que tienen que ser abordadas con iniciativas y proyectos de transformación más global. Creo que para estas funciones un coach con un alto nivel de interlocución jerárquico es vital.
Habla de cómo preparar a los stakeholders para las releases (pág. 423)
- Operación: Jobs necesarios, backup y recuperación, producción de documentación para despliegue y operadores.
- Marketing: distribuir la información entre clientes lleva tiempo.
- Otros empleados: Puede requerir cambios en la disminución de puesto o tareas de otras personas.
- Órganos regulatorios: dado que es posible que sea necesario notificar a organismos.
- Formación: preparación de materiales y cursos.
- Help-desk: Guiones de atención a clientes.
El último capitulo lo dedica a las distintas disciplinas que necesitamos (pág. 483)
Para arrancar y mantener las prácticas, para reducir el ciclo de feedback, para la formación continua, para la entrega incremental y continua de valor, etc…
Conclusión final
A la gente le podrá gustar más o menos lo que dice pero a mí me parece una obra impresionante. Hay decenas de cosas que no he comentado y seguro que a alguno os llama más la atención que lo que he destacado.
El mundo de la gran empresa es complejo y tardaremos años en que se vayan haciendo aproximaciones reales al mundo ágil y muchas se quedarán en el camino por la poca inversión en formación.
Si consiguiéramos que los CIOs, responsables técnicos de compras, arquitectos y jefes de desarrollo se la leyeran tendríamos mucho ganado para los que queremos trabajar de otro modo.
Advertir que hay veces que se hace demasiado numerativa y repetitiva, por lo que puede invitar a dejarla. Francamente me alegro de haberlo leído.