Ya son varios proyectos en los que trabajamos la mejora continua de los procesos empleando la filosofía del agilismo. En algunos de ellos trabajamos para superar la certificación de ISO20000 y estamos obteniendo muy buenos resultados. Tiene gracia que la burocracia inherente a las normas de calidad se agiliza empleando este tipo de técnicas y que, aunque a priori sean mundos muy diferentes, se complementen tan bien. Seré escueta por falta de tiempo pero creo que este tema se merece más posts así que si a alguien le interesa, habrá más.
Es tan sencillo como montar un backlog de historias de mejora, historias que salen de la “A” del PDCA de cada proceso. Habitualmente el rol de Service Manager cubre el rol de Product Owner y decide qué historias de mejora priorizar. El equipo (habitualmente operaciones y service desk) decide qué historias abordar en el sprint, “P” y durante el sprint se trabaja en resolución de las mismas, “D”. En la demo del sprint se muestra el trabajo realizado y el análisis de los indicadores, “C” para que se puedan lanzar nuevas historias de mejora, “A” y completamos una vez más el ciclo. De esta forma conseguimos también que las mejoras se pongan en producción lo antes posible para detectar rápidamente (siguiente sprint) los bugs que pudiesen surgir (p. ej. Falta definir un criterio más claro para definir los cambios pre-aprobados puesto que hay cierta confusión cuando se trata de bla bla…). Las historias no solo contemplan mejoras de proceso, también se incluyen para revisar documentación, cambiar el alcance, planificar la auditoria interna y demás tareas que no pertenecen a ningún proceso concreto.
Dinámico, ágil y sencillo, características que se agradecen para los proyectos de certificación.
Hace poco me pasó que en un proyecto de mejora en el que estamos trabajando, uno de los empleados dijo que le parecía mal uno de los cambios implantados. Que le parecía que no ayudaba mucho sino todo lo contrario, la gracia es que este cambio llevaba prácticamente 2 meses implantado y era una de las perlitas, una quick-win de estas que nos gusta decir porque, según se implantó empezaron a llegar mensajes de satisfacción.
Obviamente hay que estudiar porqué esta persona opina así antes de tacharla de “follonera”. Seguro que tiene su parte de razón. Bueno, a lo que iba. En el momento me dio bastante rabia, pensé que había tenido tiempo suficiente para haber dicho algo antes! pero ahora me alegro de que pasase así. Toda esta charla apareció en la demo del 2º sprint y de hecho una de las historias para el 3º es hacer un seguimiento de la utilidad del cambio valorando todas las opiniones de los grupos de soporte.
Ahora me pregunto ¿qué hubiese pasado si este proyecto no estuviese gestionado empleando scrum? Probablemente esta persona jamás hubiese tenido la oportunidad de hablar, hubiese tragado con el cambio y se alimentaría la desmotivación y la falta de participación: mi opinión no cuenta y menos mal que soy yo quien opera el proceso, que si no…
Scrum no evita que surjan problemas sino que éstos salen a la luz lo antes posible para poder tratarlos. Estoy segura de que se le dará una vuelta a la mejora y que, empleando esta metodología, llegaremos a una solución beneficiosa para todas las partes y en la que todas las personas del departamento se vean partícipes de la misma. Es lo bonito de trabajar así.
Implantar procesos de ITSM no es nada fácil, sobre todo si se define un proceso a la “perfección”. Con esto quiero decir que, si utilizamos el enfoque tradicional de toda la vida en materia de gestión de proyectos es muy natural caer en la falsa perfección: “estoy definiendo EL proceso de gestión de incidencias capaz de reproducir todas las situaciones que se puedan dar”.
Podemos invertir materia gris a mansalva y quizás definamos el super proceso pero quizás, también este super proceso abrume a los que van a hacer uso del mismo y casi que prefieran quedarse con el post-it colgando del monitor, que no era muy funcional pero lo manejaban con soltura. Pienso que un enfoque iterativo en el que vayamos implantando poco a poco el proceso, añadiendo funcionalidades según el estado de madurez de los operadores que lo vayan a utilizar, es mucho más acertado. De esta forma, nos aseguramos de que sea fácil de asimilar por las personas y además se parte de la gran ventaja de poder realizar cambios en las funcionalidades mientras avanza el proyecto de implantación.
Lo dicho, “inspect and adapt” para todos, para ITSM también! y funciona…
Innovación significa introducir una novedad, crear productos o servicios que faciliten la vida a quienes los utilizan. Adoptar la metodología scrum en mi opinión facilita la innovación e intentaré explicar por qué.
Una de las muchas ventajas que aportan este tipo de metodologías ágiles es que los ingenieros, técnicos, desarrolladores y en definitiva la gente que trabaja sobre el desarrollo de un producto conocen el sentido último del trabajo que desempeñan. Me explico: en scrum, cuando vamos a desarrollar algo, se definen una serie de funcionalidades con sentido de negocio (y aquí está la clave, “de negocio”) o historias que el producto tendrá que cubrir. Éstas funcionalidades son las que se transmiten al equipo que trabaja en el proyecto, así que hemos conseguido que la gente que sabe articular o materializar funcionalidades sepa realmente la finalidad última y de esta forma pueda aportar soluciones creativas e innovadoras a necesidades concretas.
Voy a poner un ejemplo sencillito que veo a menudo para que quede más claro: cuando hacemos formaciones acerca de los principios de scrum, empleamos una simulación llamada Agile IT en la que la gente tiene que construir una ciudad de Lego. Yo soy la encargada de definir las funcionalidades o historias con sentido de negocio y de transmitirlas al equipo para que las construyan, por ejemplo: construir un restaurante para que los turistas puedan disfrutar de la gastronomía autóctona. Cuando llega esta fase casi no tienen bricks de Lego y han de realizar malabarismos para poder abordar la construcción.
Bien, llegados a este punto, son muchos los equipos que me han sugerido reutilizar alguna de las construcciones anteriores como restaurante, como por ejemplo una de las casas de la ciudad argumentando que dónde mejor se va a disfrutar de la gastronomía autóctona que en una casa tradicional de la ciudad. Y realmente tienen razón, es un buen servicio y no lo presta demasiada gente, me consta que en el casco viejo de Bilbao hay una empresa que cede su típica casa acogedora para servir menús a altos ejecutivos y a turismo de alto nivel ofreciendo la experiencia de “comer en como en las casas tradicionales vascas”.
Efectivamente el equipo en esta ocasión ha innovado puesto que ha creado un servicio de valor añadido que en principio no se había solicitado como tal y además, ahorrando recursos! pues se ha evitado invertir más bricks de Lego.
Es un ejemplo simple pero espero os sirva para ilustrar mi afirmación de que scrum en cierta forma facilita la innovación.
Estamos colaborando en el Máster Universitario en Ingeniería del Software de la UPM, reforzando sus conocimientos de scrum. En la sesión de la semana pasada tuvimos que salir al pasillo para formar grupos y construir la ciudad con Lego, para casi todos ellos era su primer contacto “físico” con un proyecto scrum. Y lo pillaron sorprendentemente rápido, a pesar de que mis explicaciones en inglés rozaban el espanglish en ocasiones.
Sin embargo, en las reflexiones posteriores me sorprendió algún comentario tipo “yo he estado en dos empresas que trabajaban con scrum y no funcionaban. El equipo no se ponía de acuerdo, había luchas de egos, y si no hay alguien que tome las decisiones no se hace nada”.
Hay un mundo entre decir comercialmente que “usas scrum”, y tener un equipo ágil. Una enorme diferencia. Y lo peor es que genera la sensación de que scrum no funciona. Cuando lo único que estás haciendo es desarrollo en cascada iterativo con post-its en las paredes, mientras el equipo sigue anclado en los valores de toda la vida, luego nos sorprendemos de que “scrum no funcione”. Pregunté el nombre de las dos empresas que hacían fake-scrum, pero no conseguí sonsacarle; eso sí, al parecer ni siquiera tenían scrum masters…
Ser ágil no es obligatorio. Las empresas han sobrevivido muchos años sin serlo. Así que por favor, si no has entendido en qué consiste, y no quieres contratar a nadie para que te ayude a dar el salto, no digas que lo eres.
Dado el cúmulo de post que se están escribiendo sobre el AOS2010 de la semana pasada, quería dar mi punto de vista desde la organización del evento. Creo que para todos los voluntarios que nos ofrecimos para organizar el sarao ha sido una experiencia especial, por varios motivos:
- Hemos demostrado que un equipo motivado auto-organizado es capaz de sacar adelante muchas cosas, a pesar de la ignorancia o la falta de recursos. El primer día que tratamos de reunirnos por Skype casi no lo conseguimos porque nadie sabía iniciar una conversación de grupo, con eso lo digo todo. Teníamos cero experiencia en estos eventos, no sabíamos por dónde empezar, qué había que hacer exactamente ni cuánto nos iba a costar. Pero teníamos ganas de hacerlo.
- La sensación de estar haciendo algo útil. La gente estaba muy ilusionada con esta nueva oportunidad de reunirse, el twitter hervía, y sentías que el “cliente” tenía altas expectativas
- Y nos hemos divertido. Mucho. Para mí al menos no ha sido una carga, y creo que se debe sobre todo al buen ambiente generado dentro del grupo. Las risas y las bromas han sido constantes, y eso ayuda más de lo que pueda parecer
En resumen, creo que conseguimos generar el estado de ánimo ideal para un equipo ágil: colaboración, compromiso, entusiasmo… Habrá más Opens, y esperemos que mejores (¿en Zaragoza?). Pero yo al menos me llevo de éste un grupo de gente estupenda y la sensación de que el agilismo no es una moda, sino una necesidad.
¿Qué aspecto tiene un Open? Aquí hay un breve vídeo que está circulando:
Si estás en el Parque Tecnológico de Walqa en Huesca o alrededores, quizá te apetezca unirte a nuestro Taller de Introducción a Scrum los días 3 y 4 de Noviembre.
Hablaremos de metodologías ágiles, practicaremos con varios juegos, discutiremos pros y contras, y seguro que entre todos recogemos ideas para poder aplicar en el trabajo – o en la vida, hay quien utiliza scrum para organizar las tareas domésticas en las familias numerosas- :-)
Si te gustaría introducirte en el mundo ágil, ésta es una buena ocasión. Envía un correo hoy mismo a Beatriz Lorente de Walqa (blorente@ptwalqa.com). ¡Plazas limitadas! (Y por sólo 150€).
Viaje relámpago a París la semana pasada, para apoyar a una empresa madrileña que está defendiendo una propuesta ante una gran compañía francesa. Les exigen gestionar el posible proyecto con scrum, por lo que pidieron nuestro apoyo en la parte metodológica. Una experiencia interesante, 6 horas discutiendo el proyecto y su enfoque con los futuros clientes. Es la primera vez que veo un análisis tan exhaustivo de las distintas ofertas presentadas; menudo power point comparativo había preparado el cliente, para dejar muy claros sus puntos fuertes y débiles respecto a la competencia. Así da gusto.
Es curioso que en Francia las mayores empresas empiecen a requerir scrum como requisito imprescindible para adjudicar un proyecto; allí llevaban más de 2 años gestionando sus desarrollos de esta forma, y ya no conciben otra manera de hacerlo. Y por supuesto en el proyecto Product Owner a tiempo completo para dedicarlo al equipo. ¿¿Para cuándo en España??
A finales de agosto sabremos si hemos pasado el siguiente corte (de la short-list a la short-short list…). Crucemos los dedos.
Cuando la gente se enfrenta a su primer contacto con Scrum en nuestros cursos de formación, las reticencias suelen desembocar siempre en un punto principal: la falta de confianza. No me fío de mi equipo, no me fío de mi jefe, no me fío de mis clientes, así que con semejante panorama las metodologías ágiles nunca van a funcionar.
Para protegerme de esto me blindo ante los clientes con contratos y penalizaciones, informes de seguimiento y actas kilométricas para que quede claro “de quién es la culpa”. Y luego hago micro-management con el equipo, diciéndoles exactamente qué hacer y cuándo debe estar listo. No sé si es un tema cultural en España, cultural en IT… pero estoy convencida de que hay otra forma de hacer las cosas. Difícil, pero mejor.
Me sorprende especialmente cuando el escepticismo proviene de gente joven, veintipocos, que con su escasa experiencia ya están seguros de que “O le dices a la gente exactamente qué tienen que hacer, o nunca harán nada” (comentario de la semana pasada en un máster). O sea, Teoría X de McGregor en estado puro. ¿En qué momento se llega a este convencimiento, en la Universidad, en la primera experiencia laboral, antes?
Por suerte, siempre hay un porcentaje de los asistentes a los cursos que terminan convencidos de que vale la pena intentarlo. Y a veces basta con sembrar la semilla del cambio en una sola persona.
Si bien es cierto que cuando se practica Scrum, lo mejor es ser fieles a la filosofía ágil y lean, empleando recursos sencillos como una pizarra, post-its, papel y lápiz, hay toda una serie de herramientas, online y offline, que nos permiten ponerle el “toque tecnológico” a la gestión de nuestros proyectos. Hoy vamos a repasar algunas de ellas, sin ningún orden en particular, de manera rápida como forma de “ampliar el repertorio” si es que queremos emplearlas en un momento dado.
1. ScrumWorks: La firma Collabnet pone a nuestra disposición dos versiones de su producto: una Basic, con funcionalidad simple, pero más que suficiente para pequeños proyectos o grupos, y la versión Pro, de pago, para actividades de mayor envergadura. Con su interfaz de dos columnas nos permite diferenciar entre el contenido de los sprints y las tareas del backlog fácilmente. Permite arrastrar y soltar tareas y gestiona de manera eficiente los lanzamientos de software, si así lo precisamos. El precio por licencia para la versión Pro es algo elevado (USD 500), pero incluye soporte de por vida, actualizaciones y acceso al servicio técnico.
2. SfTS: O Scrum for Team System, de la empresa EMC. Funciona bajo un esquema de suscripción (como casi todas), y es básicamente un plugin para el producto Visual Studio for Teams de la misma casa. Es gratuito, pero es necesario tener el producto mencionado antes para poderlo usar. Una manera de introducir los conceptos ágiles si estamos desarrollando bajo esta plataforma.
3. Pivotal Tracker: El “buque insignia” de los gestores ágiles. Con una interfaz muy amigable y sencilla, nos permite gestionar proyectos con filosofía ágil fácilmente. Una de sus características es que puede calcular la velocidad de un equipo a partir de los datos de los proyectos gestionados en él con anterioridad. Permite generar informes exportables, así como listas en formato CSV de tareas si hiciera falta. También puede importarlas para añadir tareas al Icebox o al Product Backlog, que podemos incluir en los sprints arrastrando y soltando. Su interfaz es muy parametrizable con distintas vistas de tareas en curso, hechas o pendientes. Permite invitar a personas que no tengan cuenta en PT a unirse a un proyecto determinado y nombrar varios administradores para cada proyecto. Como siempre, dos sabores: gratuito (todos los proyectos son públicos) y de pago.
4. Scrumy: Un enfoque minimalista muy lean. Simplemente añadimos el nombre de nuestro proyecto a la dirección web (es decir, http://www.scrumy.com/miproyecto) y ya está, sin necesidad de crear cuentas ni nada por el estilo. También dos modalidades: gratuito y de pago. La última permite pagar mes a mes (USD 7 por mes o USD 5 al mes, si se pagan 12 meses por adelantado). También permite arrastrar y soltar entre las cuatro columnas básicas: To Do, In Progress, Verify y Done. Una buena alternativa para no complicarse la vida si queremos comenzar sencillo.
5. ProjectCards: Esta herramienta, a diferencia de las anteriores (con excepción de SfTS) funciona en local en las principales plataformas (Windows, Linux, Mac OS y como plugin de Eclipse). Es una opción bastante potente si tenemos que gestionar múltiples proyectos complejos y queremos mantener el control “en local”. También posee dos versiones, una gratuita y otra de pago, con un precio por licencia de USD 145, que incluyen soporte perpetuo y actualizaciones. Nos permite llegar a un nivel de detalle muy granular si hiciera falta.
6. Gadget para Google Wave: Si alguno se apuntó a la onda Wave, hay un gadget que se puede emplear para gestionar proyectos con Scrum, como lo muestra este vídeo:
Y por último, una curiosidad. Sabian ustedes que es posible gestionar proyectos de Scrum utilizando el mando de la consola Wii, algo de software y mucha creatividad? Pasen y vean: