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 mas que teoría |
