Sunday, 22 March 2015

Scrum en ING Holanda

ING Holanda había comprobado mediante proyectos piloto que el rendimiento de su departamento IT era, competitivamente hablando, muy desfavorable. Existía una cultura de la burocracia en la organización y, desde el resto de departamentos, había una clara insatisfacción con los servicios que proporcionaba.

El responsable de canales digitales de ING decidió tomar cartas en el asunto poniéndose como meta conseguir el doble del valor que se estaba obteniendo por cada euro que se destinaba a IT. Pidió consejo a un gran número de colegas sobre qué podía hacerse para mejorar el rendimiento de este departamento. La mayoría de ellos apuntaron a Scrum como posible solución. Inmediatamente se reunió con colaboradores de Capgemini para estudiar la adopción de Scrum en ING y en el departamento de IT específicamente.

Los primeros proyectos pilotos con Scrum comenzaron en 2011. El ciclo de vida para esos proyectos se redujo de los 3-6 meses a 6-9 semanas. Inicialmente se usaron puntos de función (FP) para medir la productividad. El ratio euro/FP y la calidad, expresada en defectos/FP, se mantuvieron pero los equipos Scrum habían realizado importantes trabajos de mantenimiento y mejora en el código.

No solo la innovación y la satisfacción del empleado subieron drásticamente sino que también lo hizo la mejora de las habilidades técnicas y la colaboración entre los miembros del equipo de trabajo. Desde los departamentos de negocio de ING comenzó también a aumentar la confianza en el departamento IT a medida que se iba entregando con éxito nuevo software que además era usable.

La reducción de costes en la entrega de software estaba en un rango de entre el 30 y el 50%. El número de incidencias técnicas reportadas se había reducido, en algunos casos, incluso por encima del 30%. La cantidad de releases puestas en producción se aumentó gradualmente para reducir los ciclos y para aumentar el aprendizaje (cuanto antes se ponía en producción antes se aprendía qué era bueno y qué no o como mejorar el producto).

Para septiembre de 2012 el número de equipos Scrum en ING había pasado de 45 a 75. Se esperaba que para diciembre de 2012 todos los equipos de trabajo en ING Holanda hubiesen adoptado Scrum en sus proyectos.

¿Y tú? ¿Pensando en adoptar Scrum en tus proyectos? Quizás te interese continuar leyendo aquí
Jornada sobre cómo "Adoptar Scrum y sobrevivir al intento...", aquí Implementar Scrum y cómo sobrevivir para contarlo o en mi libro Gestión práctica de proyectos con Scrum.

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

Sunday, 15 March 2015

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


Sunday, 8 March 2015

Céntrate en lo importante. Es ahí donde se marca la diferencia

Nos pasa a todos en todas partes. Nos devanamos los sesos pensando en cada pequeño detalle y, mientras, las cosas quedan sin hacer. En nutrición se discute y se discute sobre si el brócoli tiene más antioxidantes que la lechuga o si las lentejas tienen o no más hierro que las espinacas, en lugar de dedicar nuestro tiempo y esfuerzos en tener una dieta rica y variada en general sin preocuparnos de que en ella esté el alimento perfecto.

Lo mismo pasaría a los estudiantes de alfarería que mencionaba hace algunas semanas en este blog. Pueden discutir y discutir durante semanas sobre cuál es la mejor técnica de todas para hacer el jarrón perfecto pero solo harán buenos jarrones cuando se hayan cansado de practicar haciendo un jarrón tras otro.

Me pasa a mí también, que puedo quedarme horas pensando si el post es lo suficientemente bueno o no o si ya he revisado bastante o aún quedan faltas de ortografía. Me pasaba también al publicar el libro. Pasaba mucho tiempo decidiendo si usaba esta portada o la otra, si incluyo este capítulo o no, si es mejor Arial que Times New Roman ¡Publica! Otros libros se están vendiendo mientras tanto.

La fuente de letras no va a conseguirme muchos lectores más y, en cuanto a la portada, realmente no sabía cuál de ellas iba a funcionar mejor. Sólo sé cuál de ellas me parece un poco más bonita que la otra. Nunca lo sabría hasta que no la expusiera al público, mientras, sólo voy a darle vueltas hasta auto-convencerme de que una opción es mejor que la otra y que no me voy a equivocar. Esto nos puede llevar a la parálisis del perfeccionismo y a un excesivo miedo a equivocarse.

¿Y en el software? Claro, también nos pasa. Horas y horas para decidir si usamos este patrón de diseño o el otro. Cada uno tendrá sus ventajas e inconvenientes. Una vez comparados los dos, apostamos por uno después de haber sopesado los pros y los contras y continuamos con el trabajo. Sólo después de unos meses sabremos si era la mejor solución o no (en realidad tampoco podremos estar seguros porque solemos tender a dar más peso a los aspectos negativos de las decisiones que tomamos en lugar de a los positivos).

Haz cien jarrones, corrige 100 bugs, escribe 100 clases, haz 100 entregas. Sólo eso te hará saber qué es lo mejor para el proyecto. Entrégalo y que los usuarios vean mediante su uso qué es lo más práctico.

De cada 100 clases habrán 5, 10 o 15 errores. Todos, sin excepciones, cometemos fallos, es inevitable pero de la tolerancia a errores y de la tranquilidad del equipo para probar lo que cree que es mejor o, como se diría en inglés, no need for C.Y.A, hablaremos en otro post.

Sunday, 1 March 2015

Implementar Scrum y cómo sobrevivir para contarlo

Pocas cosas hay más de moda ahora en el mundo IT que Scrum y otras técnicas ágiles. Muchas empresas están adoptando Scrum en sus proyectos pero no todas tienen éxito. Muchas fallan miserablemente al primer intento y deciden no volver a probar. Comentan 'Scrum no es para nosotros, ya lo intentamos y no sirve para nuestros proyectos' o 'Al cliente no le gustó. Quería volver a sus diagramas de Gantt y sus entregas a final de año'.

No suele ser debido a nuestro tipo de proyecto o lo especial de nuestros requerimientos. Tendemos a pensar que nuestros proyectos son muy particulares o más complejos que ningún otro pero la mayoría de nosotros no trabaja en proyectos tan poco comunes. Adoptar técnicas como Scrum no es fácil. Suponen un cambio importante en la forma de trabajar y cuando algunas cosas empiezan a no ir bien algunos señalarán con el dedo al Scrum Master y a esas técnicas raras que no les están llevando por buen camino.

Si aún así decides apostar por esta metodología y te planteas llevar tu próximo proyecto con Scrum aquí tienes algunos de los posibles problemas con los que te encontrarás:

Clientes: esto es una cosas de frikies

No todos tus clientes habrán oído hablar de estas técnicas ágiles y quizás no les importe demasiado la forma en que tú y tu equipo se organicen. Quieren los resultados por los que te han contratado y para ello supervisarán tu trabajo y te exigirán unas fechas y unos compromisos. No estaba en sus planes oírte hablar usando terminología rara.

En la reunión de arranque de uno de los primeros proyectos en los que empecé a utilizar Scrum quise explicar la metodología que íbamos a usar y cuál iba a ser nuestro funcionamiento. Comencé hablando de deliverables, sprints o scrum masters para continuar después con daily meetings y gráficas burndown. Pronto vi que me miraban atónitos así que me salté el resto de puntos pendientes y fui directamente a la conclusión. Nadie se dio cuenta ni hizo ninguna pregunta al respecto.

Desde entonces no entro en gran detalle sobre nuestros procedimientos y desde luego tampoco uso términos que puedan sonar raros a alguien que no conozca esta metodología. Para mi sorpresa algunos clientes terminan preguntándome un tiempo después cómo se llama esta forma de trabajar y adaptándose rápidamente a los tiempos de los sprints y los spikes.

Directores: Scrum es anarquía

La máxima preocupación del director de una compañía IT suele ser que desarrolles un buen producto pero que lo hagas dentro del plazo y presupuesto previsto. Si no puedes cumplirlo puedes dejar un enorme agujero en las cuentas de la empresa y encima puedes perder un posible cliente contento. Demasiado riesgo para dejarlo en manos de nuevas metodologías.

Puede sonar más tranquilizador oír hablar al jefe de proyecto de calendarios, seguimiento de costes y de ocupación en lugar de entregas frecuentes y software funcionando. No dudo que los primeros puntos sean también importantes pero sirven de poco si el cliente no tiene un software con el que pueda ir trabajando. El jefe de proyectos tendrá que ir haciendo malabares con su tiempo para entregar los informes de facturación, el registro de horas empleadas o hacer estimaciones pero, sobre todo, no debe olvidar que su principal trabajo es entregar software que funcione.


Pueden haber muchos otros inconvenientes a la hora de implantar Scrum en tus proyectos. Iré desgranando algunos de ellos en mis próximos posts. En cualquier caso, si no quieres esperar, puedes echarle un ojo a esta presentación en prezi en la que cuento Cómo sobrevivir a la adopción de Scrum. Espero que te guste.



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