Ajedrez - antoniomartel.com

Archivos por Etiqueta: Agile

Scrum en la serie de TV Silicon Valley y en las tiendas Zara

Scrum, Lean y otros métodos ágiles se están haciendo cada vez más populares. Han pasado de la industria del automóvil al del desarrollo del software y de ahí se está disparando hacia un gran número de sectores diferentes. Hasta en Hollywood se ha interesado por estos nuevos métodos.

Ya se están viendo casos como el del gigante de la moda Zara que usando Lean Manufacturing o Lean Management para producir determinados artículos sólo cuando hay demanda (just in time). Cuando comprueba que una nueva línea de prendas con topos rojos está causando sensación, pone en marcha su maquinaria para fabricar y enviar en solo unos días los nuevos productos a sus tiendas de Shangai o Nueva York.

No tiene que esperar a la próxima temporada de otoño-invierno para diseñar, producir y distribuir los productos que veremos en verano en las tiendas ¡A saber qué estará de moda en ese momento!

También está pasando en la banca. Hablaba hace unos días del caso de ING pero no se está limitando sólo a sus departamentos de informática sino también de oficinas ágiles que intentan adaptarse a las nuevas necesidades de los clientes (ya hablaré de banca ágil en otro post).

Pero quizás la prueba definitiva de la popularidad de lo ágil venga de la mano de la televisión. En la comedia Silicon Valley de la HBO los actores interpretan a programadores recluidos en la casa de un millonario gracias a las páginas web. En varios capítulos pueden verse tableros kanban, gráficas burn-down o de deuda técnica.

En otro capítulo un consejero de la start-up recomienda al dueño usar Scrum pero cuando deciden implantarlo el equipo se queja amargamente y todo acaba con muy malos resultados (ya sabes, es sólo ficción).

Referencias:

Meteduras de pata, confianza y política CYA

Los errores en un proyecto software son algo habitual, algo con lo que lidiar cada día. Se calcula que una aplicación web tiene una media de 4 errores por cada punto de función (contando 1 punto de función como unas 50-55 líneas aproximadamente de código Java).

Recuerdo incluso haber leído en mis tiempos de Universidad que, en la construcción de cierto sistema operativo, por cada 3 bugs corregidos se introducían 2 nuevos. Quizás una aplicación web no tenga la complejidad de ese sistema operativo pero no me resultaría extraño si alguien me dijera que en ese caso la relación fuese de 3 a 1.

Los errores al programar no son los únicos fallos que puede cometer un equipo de desarrollo. Pueden haberse entendido mal las especificaciones. Pueden haber olvidado copiar un archivo en un despliegue o no haber concretado lo suficiente un requerimiento. Oportunidades para equivocarse hay muchas.

Si ante cada error afeamos la conducta al que lo cometió e insistimos en encontrar al culpable para señalarlo con el dedo sólo vamos a conseguir que el equipo de trabajo esté más preocupado de salvar su pellejo que de hacer su trabajo lo mejor que sabe. Se tenderá a argumentar y argumentar en la documentación para justificar el porqué de las decisiones y dejar claro quién fue el que tomó la decisión.

En inglés hay un término llamado ‘CYA (cover your ass)‘ para indicar cuando se están tomando acciones sólo para protegerse las espaldas. Se dice también que cuando no tienes que emplear una mano en tapar tus vergüenzas puedes contar con las dos manos para trabajar mejor.

Si logramos en nuestros equipos una cultura ‘No need to CYA‘ podremos trabajar más tranquilos y ocuparnos sólo en entregar nuestro trabajo. Si alguien comete un error, bueno, quizás la próxima vez sea uno mismo quién lo cometa. Se asume, se explica, se toman las acciones necesarias para corregirlo y se avanza a la siguiente tarea. Es más rápido y más efectivo que estar buscando al culpable entre acusaciones cruzadas.

Referencias:

Scrum en ING Direct

Si son clientes de ING Direct probablemente se hayan dado cuenta que desde hace algún tiempo tienen una nueva web desde la que realizar sus gestiones con el banco. Algunos ya lo sospechábamos pero en esta entrevista a Enrique Ávila, director general del tecnología de ING Direct en España, se confirma: están usando Scrum/Agile para su desarrollo.

Empezaron con un desarrollo pequeño, con las funcionalidades básicas para hacer el 80 o 90 por ciento de las operaciones y dejando otras funcionalidades más específicas para más adelante. Tampoco la lanzaron de una sola vez al mercado obligando a todo el mundo a usar la nueva web sino que la proponían desde el portal de siempre para que la fueran usando los usuarios más avanzados (y probablemente tampoco a todos al mismo tiempo).

Con estos usuarios fueron probando que todo funcionaba bien y corrigiendo o adaptando lo que necesitasen cambiar. Desde entonces han ido incorporando cada poco tiempo más y más funcionalidades según las necesidades del cliente, tanto que ya casi no es necesario visitar la antigua web.

En el vídeo se comenta la adopción de Scrum por ING y cómo era el desarrollo, con equipos Scrum pequeños y multidisciplinares con todas las capacidades para entender al cliente y entregar productos construidos en ciclos muy cortos. A partir del feedback del cliente vuelven a repetir los ciclos de manera más refinada y aproximándose cada vez más a lo que el cliente necesita.

Pero la agilidad no es nueva en ese banco. ING Holanda ya la había puesto en práctica con excelentes resultados. Aquí tienen parte de la historia:

Amir Arooni, un CIO de ING Holanda, decidió que por razones de competitividad, las entregas de los servicios IT de su departamento necesitaban mejoras sustanciales. Los métodos de trabajo y los proyectos en cascada ya no estaban siendo viables y necesitaban un cambio urgente.

Se creó un pequeño proyecto piloto para medir el rendimiento real del departamento. Era un proyecto estimado en 1500 días/hombre (casi un año para un equipo de 5 personas) pero se tardó 11 meses en terminar a pesar de estar involucradas 47 personas y 25 departamentos.

Las entregas eran percibidas como inseguras por la poca fiabilidad de las fechas de finalización y había una alto nivel de burocracia debajo de todo el proceso formal que estaban usando. La forma tradicional de gestionar proyectos basándose en el presupuesto y en el tiempo estaban retrasando enormemente las entregas que estaban lastrando la competitividad del banco.

Amir envió una petición a un gran número de sus colegas pidiéndoles ayuda para tratar con esta situación. Una gran mayoría de ellos apuntó a Scrum como la solución por lo que Amir decidió contactar con Capgemini Holanda para valorar las posibilidades de adoptar Scrum en ING y en su departamento específicamente.

Lo que sucedió en ING después de implementar Scrum lo termino de contar en este otra entrada del blog. Sigue el link: Scrum en ING Holanda.

Referencias:

Si te ha gustado este post, puedes encontrar más contenidos que expliquen Scrum de forma práctica y desde su base en mi libro en Amazon Curso práctico de Scrum: Algo más que teoría.

Libro en Amazon: Curso práctico de Scrum: Algo más que teoría
Libro en Amazon: Curso práctico de Scrum – Algo mas que teoría

Nuevo curso Gestión de Servicios TIC

ITProiectus y la SPEGC organizan un nuevo curso de ‘Gestión de servicios TIC en departamentos de desarrollo de software’ en el edificio INCUBE los días 2, 9 y 16 de octubre.

Será un curso compuesto por 5 sesiones de dos horas de duración cada una en las que se tratarán metodologías y marcos de trabajo como PMP por Iván Tejera y Mónica Khiani, ITIL por Agustín Tapia, Kanban por Antonio Dorta y Scrum que será impartida por mí.

Serán sesiones orientadas a la práctica en las que se pondrán ejemplos de uso contando el por qué y para qué de cada técnica además de un pequeño debate al final de cada sesión. Seguro que les resultará interesante.

Tienen toda la información y datos para la inscripción y matrícula, sólo 30€, en la web de Proiectus. Ánimo y a apuntarse.

¿Estás usando Scrum?

Veo a menudo en la llamada ‘comunidad Ágil’ demasiada discusión sobre si se está usando Scrum o si lo que estás haciendo puede llamarse Scrum o no en lugar de centrarse en si se está entregando trabajo con frecuencia y si este trabajo es lo que el cliente necesita. Esto es lo realmente importante, el proceso que se siga para lograrlo es secundario.

Es una especie de fundamentalismo que afecta a unos pocos que han aprendido un Scrum ‘único y verdadero’ y ellos deciden lo que está bien o está mal. Lo implementan de una manera poco flexible pretendiendo que de un plumazo toda la organización cambie su forma de trabajar. Ante cualquier queja contestarán: ‘Debe ser que no lo estás haciendo bien. En Ericsson y Spotify funciona perfectamente‘.

Hay otro tipo de implementador de Scrum, el llamado pragmático. Es el que, conociendo aún poco de Scrum, usa sólo algunos de los métodos porque considera que los otros son demasiado difíciles de implementar o que hay mejores formas de hacer esa parte en concreto. Es como ir a una clase de kárate y después de la primera lección decirle al instructor ‘Bueno, todo esto está muy bien, pero creo que puedo simplificarlo un poco para hacerlo mejor‘.

No hay nada de malo en adaptar Scrum a las necesidades de tu proyecto, de hecho es necesario y a veces quizás imprescindible. Comenzar con Scrum siguiendo al pie de la letra el libro también es importante. Aprender del patrón ideal o común a muchos proyectos para luego flexibilizarlo y adaptarlo a tus características es bueno si se mantienen de fondo los principios ágiles. Haz lo que funcione para ti o tu empresa pero mantente en ello y mejóralo con el tiempo.

Referencias: Pragmatism, Fundamentalism and Transformation – the Three Modes of Scrum

Suscríbete