Todo el mundo odia el cambio

El texto a continuación está basado en el libro: 

Peopleware: Productive Projects and Teams

Tom DeMarco & Timothy Lister. Dorset House Publishing, 1998

Los proyectos se llevan a cabo para producir cambios en las organizaciones. Al implantar el producto, servicio o resultado final en la organización ejecutora, cambiamos la forma de trabajar de la gente. 

Como Directores de Proyectos, nos aseguramos de que los cambios son para mejorar. Utilizando una lógica exhaustiva y precisa, explicamos cómo la nueva manera de hacer las cosas será mejor por muchas razones. 

¿Por qué alguien racional podría resistirse a cambiar para mejor? 

Los que ya han pasado por muchos procesos de gestión del cambio lo saben: La gente odia el cambio. Ese es el problema. No es que rechacen un cambio en particular, sobre la base de sus méritos, sino que se oponen a cualquier cambio. 

Todo el mundo odia el cambio

Gestión de Riesgos: el derecho a creer

Un barco de emigrantes está a punto de hacerse a la mar con un cargamento completo de pasajeros. El armador está tan preocupado por el estado de su viejo barco (no muy bien construido en origen), que se cuestiona si podrá soportar un último pasaje. Con poco esfuerzo, sin embargo, supera sus dudas y se convence a sí mismo de que no pasa nada por un pasaje más. El barco, después de todo, ya soportó en su día algunas tempestades y siempre se las arregló para llegar a puerto. ¿Por qué no una vez más? 

El barco sale a la mar, se hunde y mueren todos. ¿Qué puede decirse del armador? Seguramente esto: que es culpable de la muerte de aquellos hombres. Si bien se admite que su convencimiento era honesto y verdadero, esto no puede ayudarle porque no tenía derecho a creer sobre la base de tan pobres evidencias. Su creencia fue adquirida no a partir de una paciente investigación, sino ahogando sus dudas. Y aunque al final él se sentía tan seguro que no podía pensar de otra manera, dado que él mismo se había esforzado conscientemente para adquirir ese estado mental,  debe ser culpado como responsable.

Projects need more Sociology and less Technology

We Project Managers are mostly judged by results. This is not quite a rewarding profession: If we meet the goals, no one will praise us. If we don’t meet the goals everybody will criticize us. But the most of the project work falls out of our area of control: we are appointed not to do, but to manage what others do. 

Projects don’t usually fail just because of technological issues. You can easily find the required technical expertise among team members quite often. A project may fail just because team members John and Mike don’t even talk to each other. The absence of soft skills in project management is often the root cause of failed quality control and scope validation, low productivity of the team, high level of rework, slippages, cost overruns, etc. Our profession demands more of Sociology and less of Technology.

El rol del Product Owner en la práctica

El Product Owner es un rol muy importante en los proyectos ágiles: Representa nada menos que la voz del cliente. Se asegura de que el equipo conozca la perspectiva del negocio. Gestiona las historias de usuario, las prioriza, y las mantiene en el product backlog. En un proyecto ágil, no es menos importante la figura del “coach” o ScrumMaster, ocupado principalmente en asegurar que se sigue el proceso y evitar impedimentos.

Personalmente, me interesa mucho el papel nos toca a los Project Managers en un proyecto ágil, pero no está claro si debe ser ScrumMaster, Product Owner, una mezcla de ambos, o bien depende del caso concreto. En las referencias más utilizadas no parece haber una opinión consensuada: En este post se comenta que el Project Manager podría ejercer cualquier rol, dependiendo del caso. Este otro va más en la línea de que el Project Manager debe corresponderse con el rol de Product Owner.

Para arrojar luz sobre el tema, lo primero es conocer en detalle qué se supone que debe hacer el Product Owner en la práctica. Con este fin les recomiendo que visiten este famoso vídeo titulado Agile Product Ownership in a Nutshell. También pueden ver esta otra versión del mismo vídeo subtitulada en español: El rol del Product Owner en la práctica.

A continuación pueden leer una transcripción traducida al español.

Quiero ejecutar un proyecto ágil

Cambiar hacia métodos ágiles los procesos de desarrollo software de una gran organización es posible, deseable, motivador, rentable, sostenible, etc. En mi opinión, los métodos ágiles no son una moda pasajera sino que han venido para quedarse y constituyen la única alternativa realista a la crisis del software. Estos métodos son muy estables: han variado poco y son globalmente reconocidos desde que se publicó el manifiesto ágil en 2001. La prueba definitiva de lo estables que son estos métodos la obtenemos cuando buscamos información en Internet y encontramos material divulgativo de extraordinaria calidad. Más adelante comentaremos el vídeo de hace 2 años que da título a este post: I want to run an agile project. Hay otros muchos vídeos muy buenos: Visiten este enlace para tener una introducción muy completa de Scrum. ¿Quieren saber qué se supone que debe hacer un Product Owner? Solo tienen que visitar este enlace y ya lo saben todo. ¿Quieren ver cómo hay que hacer un daily standup? Pinchen aquí.

Si una determinada organización se decide por el método ágil más popular, Scrum, mucha gente dentro de la organización ya sabrá en qué consiste, quién debe hacer qué y y por qué, y qué podría ir mal. Todos saben de los peligros de los “scrum-buts” (esto es, usar Scrum parcialmente ignorando los beneficios posibles de usarlo todo), y reconocen la conveniencia de empezar siendo puristas en una adopción inicial, hasta alcanzar la madurez suficiente en gestión de proyectos adaptativos para adaptar entonces los procedimientos a la organización.

Entonces, si adoptar los métodos ágiles es tan fácil, hay tanto conocimiento y tanto consenso, ¿por qué será tan infrecuente que se adopten de forma eficaz en las grandes organizaciones?

La mentalidad “hamburguesa cocinada, hamburguesa vendida”

 
El desarrollo de software es una actividad muy diferente a la producción. Sin embargo, los Directores de Proyectos de software a menudo aplican una filosofía de gestión derivada completamente de los entornos de producción de la era industrial.

Imagine por un momento que usted es el gerente de una franquicia local de comida rápida. Para usted, tendría mucho sentido tomar cualquiera de las siguientes medidas para aumentar la eficacia en la producción:

• Reducción de la tasa de error: Hacer que la máquina (humana) funcione tan suave como sea posible.
• Dirección autoritaria (presionar, castigar, más horas).
• Tratar a los trabajadores como piezas intercambiables de una máquina.
• Ritmo de producción constante: No pensar en lo que supone la transición operativa para ganar velocidad o el tiempo que supondrá cerrar la operación.
• Estandarizar el proceso: Hacerlo todo según el manual.
• Eliminar la experimentación (para eso pagan a los de servicios centrales).

Estas medidas serían razonables si usted se dedicara al negocio de la comida rápida (o a cualquier otro entorno de producción), pero no es así. Usted es Director de Proyectos. La mentalidad de “hamburguesa cocinada, hamburguesa vendida” puede resultar fatal si se dedica al desarrollo de software, o cualquier otro proyecto relacionado con el “trabajo del conocimiento”. Solo le servirá para quitarle la ilusión a la gente y para alejar su atención de los problemas reales.

Este estilo de gestión es completamente opuesto a la efectividad en el tipo de trabajos que debe desarrollar el “knowledge worker”.

Retrospectiva del Proyecto Havannah

A continuación tienen un vídeo con un breve resumen de los 5 últimos posts dedicados al caso práctico con métodos ágiles desarrollado en el libro Agile Estimating and Planning, de Mike Cohn.

Espero que les sirva como referente práctico para aclarar conceptos como: iteración, historia, puntos-historia, velocidad, iteration planning, release planning, iteration review, etc. Nada tan efectivo como imaginar estos conceptos en acción en un caso más o menos realista, ¿verdad?

Por favor, no se queden solo con el vídeo, que no equivale a leer el capítulo de más de 50 páginas. Les animo a que compren este buen libro, ideal para comprender mejor los métodos ágiles. Si solo pueden leer una parte, lean el caso práctico desarrollado en el capitulo 23. Si quieren leer este capítulo en español, pueden empezar por aquí.

Quemando las iteraciones del Proyecto Havannah

Quinta y última entrega de la traducción capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, dejábamos al equipo a punto de comenzar la primera iteración de 2 semanas, que habían planificado en 4 historias de 18 puntos. También habían previsto que el proyecto duraría entre 12 y 20 semanas. En este post veremos lo siguiente:

1. El equipo demuestra los resultados de la 1ª iteración (completan 16 puntos de 18) y planifican la 2ª iteración con 3 historias de 18 puntos.
2. Demuestran la 2ª iteración completa al 100% y planifican la 3ª teniendo en cuenta dos nuevas funcionalidades “emocionantes” que ha investigado Diana, de 30 y 35 puntos, respectivamente. Si quieren mantener la planificación en 12-20 semanas, deben renunciar a una funcionalidad emocionante de 30 puntos. Antes de arrancar la 3ª iteración, quedan por quemar 133 story points (más que los 132 que tenían al principio del proyecto, ¿significa esto que van para atrás?).
3. Por último, atendemos a la reunión de revisión de la última iteración del proyecto, finalizado en un plazo 22 semanas, con 2 semanas de retraso sobre la estimación inicial comunicada de 20 semanas, pero a cambio de mucho más valor para el negocio.

En este caso práctico, los métodos ágiles han supuesto una cuantificable mejora del proceso de desarrollo de software, sobre todo comparando con el retraso acumulado del proyecto anterior de 6 meses.

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.

Plan inicial del Proyecto Havannah

Cuarta entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah estaba manteniendo una reunión con una agenda de tres puntos:

1. Planificar la primera iteración.
2. Revisar los resultados de la investigación de mercado.
3. Hacer una estimación preliminar del plan de entregas y el calendario.

El primer punto de la agenda concluyó con el compromiso firme del equipo sobre 4 historias de 18 puntos. A continuación se cubrirán los puntos 2º y 3º, para lo cual es necesario priorizar las 29 historias restantes. Una forma de hacerlo es usar el modelo del profesor Noriaki Kano:

El modelo de Kano sirve para determinar si las características de un producto son obligatorias (insatisfacción si no están), lineales (cuantas más hay, mayor satisfacción producen) o emocionantes (satisfacción si están, pero no hay insatisfacción si no están). El proceso habitual para llegar a estas conclusiones es plantear una encuesta a los usuarios con preguntas funcionales (cómo se sentirían si la característica estuviera presente) y disfuncionales (cómo se sentirían si la característica NO estuviera presente). Una vez se reciben las respuestas, la siguiente tabla permite clasificarlas en 6 categorías: obligatoria, lineal, emocionante, contrario, cuestionable, indiferente.

A continuación se describe cómo transcurre la segunda parte de la reunión.  El resultado de la reunión es que el proyecto durará 7 iteraciones (14 semanas). ¿Por qué? Porque a una velocidad de 18 puntos por iteración, en 7 iteraciones daría tiempo a asumir los 132 puntos previstos en la release. ¿Por qué 132 y no los 146 puntos de todas las historias? Porque el Product Owner no quiere que se dedique esfuerzo a las que resultan indiferentes para el público objetivo (6 puntos) y cree que puede ahorrarse una funcionalidad emocionante de 8 puntos. El equipo ya tiene una estimación para la duración del proyecto, pero el coach insiste en que esta estimación no debería publicarse, sino que es mejor decir que el proyecto durará entre 12 y 20 semanas. ¿Por qué?

Sigan leyendo y lo descubrirán.

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.

Comprometidos como EQUIPO con la primera iteración

Tercera entrega de la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En el post anterior, el equipo del proyecto Havannah había escrito 32 historias de usuario, que tenían un tamaño de 146 puntos en total. 

En este post, los miembros del equipo dedican dos semanas a terminar otro proyecto mientras la analista Diana comienza la investigación de mercado con una encuesta a potenciales compradores. Al cabo de las dos semanas, el equipo se vuelve a reunir con Carlos, el coach en métodos ágiles, para planificar la primera iteración y comprometerse como equipo para terminar las historias más prioritarias. El resultado es un compromiso firme del equipo sobre 4 historias que miden 18 puntos.

¿Quiere saber cómo se planifica esta primera iteración?

Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.
 

Las historias del proyecto Havannah

Continúa la traducción capítulo capítulo 23 del libro Agile Estimating and Planning, de Mike Cohn. En este segundo post (véase nota*) veremos la conveniencia de escribir tarjetas físicas y cómo puede organizarse una reunión de brainstorming para hacer que los miembros del equipo vayan deduciendo los requisitos (en forma de user stories). Es recomendable estructurar el brainstorming por temáticas para no dejar ninguna funcionalidad sin analizar.

Casi al mismo tiempo, los miembros del equipo pueden estimar el tamaño o complejidad de los requisitos mediante un juego conocido como planning poker, en el que se estima el tamaño y complejidad de cada historia en unidades llamadas story points.

Estas dos actividades (recopilar requisitos y estimar sus tamaños) son interdependientes porque, a veces, una historia de usuario muy grande hay que descomponerla en varias más manejables.

Una regla básica que hay que recordar es que las historias de usuario deben ser independientes, negociables, valorables, estimables, pequeñas y verificables (Independent, Negotiable, Valuable, Estimatable, Small, Testable -INVEST-).

A continuación se describe cómo transcurre la reunión inicial de análisis de requisitos en un proyecto ágil. Al finalizar la reunión (que puede durar entre 2 y 4 horas), los miembros del equipo del proyecto Havannah habrán consensuado los requisitos con 32 historias de usuario, y también habrá consensuado la estimación del proyecto en 146 story points.

¿Quiere saber cómo se hace?

(*) Siguiendo mi recomendación en un post anterior, he anotado estas historias en un tablero virtual de Evernote, que pueden acceder fácilmente a través de Evernote por web o desde su propio Evernote desktop, usando como usuario y contraseña la palabra “pmpeople”.

Un caso de estudio ágil: El Proyecto Havannah

El siguiente caso de estudio es una traducción del capítulo 23 del libro de Mike Cohn titulado Agile Estimating and Planning. Este capítulo, el autor, con la intención de resumir y ejemplificar la mayoría de los puntos clave del libro, desarrolla el caso práctico de la experiencia del primer proyecto ágil en una empresa ficticia llamada Bomb Shelter Studios, en el que participan las siguientes personas:

• Francisco: Responsable de productos.
• Alberto: Programador.
• Santiago: Programador.
• Carlos: Coach en métodos ágiles.
• Paula: Responsable de pruebas.
• Rosa: Diseñadora gráfica.
• Diana: Analista.
• Laura: Directora financiera.
• Felipe: Director general.

Este post reproduce la traducción del mencionado capítulo, desde que surge la necesidad de probar métodos ágiles para gestionar un nuevo proyecto software hasta que comienza la primera reunión de recopilación de requisitos en forma de “historias de usuario”.
 

¿Va a usar Agile en su próximo proyecto Software?

¿Ha tenido usted alguna vez la experiencia de un proyecto software que haya fracasado? Si ha estado trabajando en este sector algún tiempo, es casi seguro que le ha pasado alguna vez. ¿Recuerda la sensación cuando se iba dando cuenta de que no iba a ser posible cumplir el plazo, o que el producto sería inaceptable?

Usted intentó alertar a la dirección, pero ellos no querían escucharle. Más bien al contrario, declaraban abiertamente lo bien que iba el proyecto. A usted le parecía un tanto “surrealista” lo convencidos que estaban de que todo iba bien, cuando era obvio que todo iba mal. Los que sabían que su proyecto iba en caída libre, tampoco querían hacer nada al respecto. En vez de intentar salvar el proyecto, se concentraban en salvarse a ellos mismos: El proyecto no iba tan mal (por lo menos en su área no había problemas).

¿Usar Evernote en Proyectos Ágiles?

Quizá usted ya conoce y usa habitualmente Evernote, una herramienta muy popularizada para tomar notas desde el ordenador, el portátil, la tablet, el móvil, etc. Las notas quedan guardadas “en la nube”. Ya no tenemos que usar libretas ni cuadernos. Podemos tomar notas en todo momento y en todo lugar. Es una herramienta tan presente en nuestro día a día para profesionales y estudiantes, que muchos de nosotros ya no sabríamos vivir sin ella y por supuesto no nos parece un gran coste los 5 € al mes que cuesta el modelo premium (si bien la versión gratuita es completamente funcional).

Lo que seguramente no hace todavía es usar Evernote como tablero virtual para proyectos ágiles. A mí personalmente me parece que la “estructura flexible” del contenido que pueden tener las notas de Evernote, la capacidad de mover notas de unas carpetas a otras, de etiquetarlas, etc., hacen que me parezca una herramienta muy en sintonía con el estilo “low-tech, high-touch” que se demanda en los proyectos ágiles. Por supuesto, un equipo usando un tablero físico en una sala dedicada es insuperable. Quizá en estos proyectos sea cierto eso que dicen muchos colegas de que “la mejor herramienta es ninguna”. Pero un repositorio centralizado con la información del proyecto también tiene sus ventajas, sobre todo cuando hay algunos miembros del equipo que no comparten la misma ubicación.

Si quiere saber cómo le doy yo esta funcionalidad de tablero virtual a Evernote, siga leyendo, por favor. Las pantallas que muestro son de un ejemplo preparado en Evernote con mi propia cuenta de usuario. Puede verlas usted mismo entrando en Evernote por web o desde la aplicación desktop, usando como usuario y contraseña la palabra “pmpeople”.

¿Agile es no planificar?

¿Cuándo fue la última vez que le tocó gestionar un proyecto predictivo? Ya sabe, uno de esos en que se debe invertir mucho tiempo y esfuerzo en la fase de planificación, la mayor parte del trabajo empieza a quedar clara desde el principio, el cliente firma los requisitos, y su misión fundamental como Project Manager es minimizar las desviaciones de tiempo, coste, alcance y calidad.

No es que no vaya a haber cambios durante la ejecución, también habrá muchos problemas, pero los interesados esperan de usted que coordine todos los cambios de forma integrada, que les haga seguir un proceso de solicitud, evaluación, aprobación, etc. Todo el mundo es consciente de que los cambios tienen un alto coste, pocos se toman la molestia de defender la necesidad de alterar algo: no quieren ser los culpables de que el proyecto sufra retraso o sobrecoste.

Quizá en ciertos sectores (construcción, ingeniería, etc.) este tipo de proyectos siguen siendo la norma. Desde luego no es el caso de los proyectos de desarrollo de software, o en los proyectos de consultoría, donde al principio suele estar poco claro el producto del proyecto. ¿Podríamos generalizar a todo proyecto de los “trabajadores del conocimiento”, donde los entregables y el trabajo son de tipo “intelectual”?
 

Algo pasa con el Software

¿Qué tendrá la Ingeniería del Software que la hace tan diferente a las demás? He aquí algunas claves:

Gestionando las expectativas de calidad

El efecto final de satisfacción de cliente no se improvisa, hay que sembrarlo y trabajarlo continuamente. Cuando decimos que “la calidad se planifica”, esto tiene que ver con que hay que imaginar los criterios de aceptación, idear los procesos de aseguramiento y control de calidad que hacen más probable que dichos criterios de aceptación se cumplan.

Sin embargo, es muy frecuente que los clientes no nos firmen los requisitos. ¿Qué podemos hacer entonces para gestionar las expectativas del cliente?

El Director de Proyectos debe ser "buena persona"

Hubo un tiempo en el que yo pensaba que todo en la vida era técnica. Para todo problema existía al menos una técnica o herramienta adecuada. El ser humano ganó la carrera evolutiva gracias a su destreza para usar herramientas. Dominando suficientes técnicas se podía triunfar en la vida:

• ¿Quieres ser buen judoka? Aprende bien las técnicas de combate en pié y en suelo, entrena tus mejores llaves. En las competiciones, mejor si eres zurdo, hay picardías como esquivar el agarre, pisar, rozar la cara del contrario con el kimono, soltarse el cinto (el árbitro te dará una pausa para que te lo coloques y de paso recuperarás el aliento). 
• ¿Quieres ser buen estudiante? Consigue buenos apuntes y exámenes de otros años, estudia intensamente los días antes del examen, con mayor esfuerzo lo que sabes que va a caer. Selecciona con cuidado a tu compañero de laboratorio.
• ¿Quieres aprender inglés? Contrata una semana de inmersión, clases particulares con un nativo, que a tus hijos los cuide una au pair americana o inglesa, algo se te pegará. Ve de vacaciones al extranjero.
• ¿Quieres ser buen programador? No te preocupes por la calidad del código, mejor si lo entiendes tú sólo. Si compila, has terminado. Las pruebas no son tu responsabilidad. No te preocupes porque tu clase se integre con el resto del sistema, simplemente cumple las interfases. Usa muchas librerías que no hayas programado tú, copia y pega todo lo que puedas, así acabas antes, y si falla no es culpa tuya. Exagera el impacto técnico de cualquier cambio. Consigue que los problemas funcionales no sean asunto tuyo.

  

Culpable de “teamicidio” Nº 5: La reducción autoimpuesta de la calidad

Nadie quiere realmente reducir la calidad de los productos, sino su coste. Habitualmente, sin embargo, el significado es el mismo. Los pasos que se dan para entregar el producto en menos tiempo implican menor calidad. A menudo son los usuarios finales quienes consienten una menor calidad a cambio de una entrega en menos tiempo y con menos coste.

Pero estas concesiones pueden ser muy dolorosas para los programadores. Su autoestima y disfrute del trabajo salen perjudicados ante la necesidad de construir un producto de una calidad claramente inferior a la que son capaces.

Culpable de “teamicidio” Nº 3: El papeleo (la burocracia)

En las décadas de los 70 y 80, Caper Jones dirigió una serie de estudios para categorizar los costes en los desarrollos de sistemas de información. Una de las categorías era el papeleo (paperwork, en inglés). Lo que Jones llama papeleo es algo así como la documentación que se genera sin sentido, la que sirve para "cubrir el expediente", simple y llana "burocracia". Hablamos aquí de la documentación no relacionada con los requisitos, el análisis, el diseño, codificación, planes de pruebas, ayudas, manuales, etc. Jones concluía que el papeleo supone más del 30% del coste de producir un determinado producto software.