Agile Project Management

Haz un premortem de tus proyectos para que te pongas en lo más negativo y así luches para que las cosas salgan bien.

El pensamiento positivo puede hacer que nos confiemos e idealicemos los resultados de nuestro trabajo o abandonemos a las primeras de cambio porque las cosas no van saliendo tan bien como pintaban. En cambio, imaginar todos los obstáculos de un proyecto hará que nos preparemos para resolverlos y amortigüemos los golpes antes de que ocurran.

Haciendo un premortem antes de empezar y calculando todo lo que puede salir mal nos va a acercar un poco más a nuestra metas. Habrá gente a la que no le guste que se esté dando una visión negativa del reluciente nuevo proyecto que se va a empezar, pero será mucho peor si al final las cosas empiezan a torcerse y no nos pilla preparados.

Te puedo asegurar que muchos de los obstáculos que habías previsto en el premorten terminarán pasando, pero además habrá otros muchos que ni siquiera se te pasaron por la cabeza cuando lo hiciste y te harán pasar un mal rato. Nada hay tan fácil que no pueda hacerse mal.

Extracto del libro Thinking in bets:

Despite the popular wisdom that we achieve success through positive visualization, it turns out that incorporating negative visualization makes us more likely to achieve our goals. Gabriele Oettingen, professor of psychology at NYU and author of Rethinking Positive Thinking: Inside the New Science of Motivation, has conducted over twenty years of research, consistently finding that people who imagine obstacles in the way of reaching their goals are more likely to achieve success, a process she has called “mental contrasting.” Her first study, of women enrolled in a weight-loss program, found that subjects “who had strong positive fantasies about slimming down . . . lost twenty-four pounds less than those who pictured themselves more negatively. Dreaming about achieving a goal apparently didn’t help that goal come to fruition. It impeded it from happening. The starry-eyed dreamers in the study were less energized to behave in ways that helped them lose weight.

Thinking in bets by Annie Duke

Hace como 1000 años (año arriba, año abajo) trabajaba en una Creamery de queso Blue Stilton en el centro de Inglaterra, una fábrica que producía y envasaba quesos azules en distintos formatos. Tenía que pagar el alquiler mientras me salía un trabajo como desarrollador de software.

Estaba en mi puesto de operario al final de una de las líneas de producción, y notaba que la máquina iba más rápido que yo. Recogía y etiquetaba cada pieza, pero al poco otra llegaba y se queda al borde de caer al suelo. Incrementaba la velocidad para evitarlo, pero de nuevo otra pieza corría el mismo riesgo. Volvía a recogerla en el último instante, y seguí así todo el tiempo que pude, recogiendo, etiquetando y colocando cada vez más y más rápido. La línea de producción no paraba, no importaba a la velocidad que fuera: ahora docenas de trozos de queso se apilaban esperando que los atendiera.

Cuanto más rápido iba, más trabajo había. Llegó un punto en el que ya no coordinaba mis movimientos. Pedí ayuda para parar la máquina antes de que todo aquello llegara al suelo Con todo el ruido en la fábrica nadie me oyó. Cuando no pude más, levanté las manos para intentar contener el río de envases que fluía por la línea, y en ese momento todo se paró.

No me había dado cuenta de que al final de la línea de trabajo había un sensor que, como en las cajas de los supermercados, paraba el movimiento si el último queso seguía allí sin ser atendido. Si yo recogía un envase, otro se ponía en su lugar inmediatamente después, y otro y luego otro. No importaba lo rápido o lento que fuera.

Esa misma sensación de estar haciendo el «tonto» la tuve mucho después, cuando al llegar al trabajo después del fin de semana, me encuentro docenas de correos en mi carpeta de entrada. Comienzo a responder tan rápido como puedo cada uno de ellos intentando dejar la bandeja límpia de nuevo y poder atender con tranquilidad las reuniones de mediodía.

Sin embargo, horas después, cuando creo haber terminado me encuentro otro montón de correos que han llegado nuevos. Son las respuestas a los correos a los que había estado enviando durante toda la mañana. Unos me pedían clarificación, otros solo me daban las gracias, pero algunos me apremiaban aún más. El atasco en la bandeja de correos lo estaba causando yo.

Podía haber seguido atendiendo la bandeja de correos otro par de horas, pero de nuevo tendría una pila de emails nueva. No es la bandeja de correos, ni el chat, la que debe dirigir tu trabajo. Vas a tener que priorizar lo urgente, pero sobre todo lo importante, y no dejarte llevar por el resto o no completarás nunca nada relevante de verdad. Solo estarás ocupado (muy ocupado!), pero la máquina no va a parar de entregarte nuevos trozos de queso para que les pongas una etiqueta.

Hace unos meses publicaba este post sobre la documentación y las pocas posibilidades de que se la lea alguien. Solo van a pulsar Control+F y buscar en el texto lo que le lleve rápido a la sección donde está la información que le interesa.

Pero ahora pienso distinto, los usuarios ni siquiera van a hacer eso. No van a entrar a un Confluence con multitud de páginas y carpetas, ni a abrir tu documento Word de 200 páginas y perder las pestañas leyendo el índice tratando de adivinar si ahí hay algo de interés para lo que buscan.

Si su empresa les proporciona una IA integrada con Teams, con sus emails, con Confluence, con Jira y con todos los repositorios de documentos de la empresa, simplemente van a hacer una pregunta a Copilot. La IA va a examinar toda la Intranet para hacerte un resumen claro y detallado de lo que necesitas, justo al momento en el que lo necesitas.

Me di cuenta de esto hace poco, cuando pregunté a Copilot por información y definiciones de unos términos que no tenía claros, y que muy poca gente en la empresa podía hablar de ellos con seguridad. Copilot me dio un resumen claro, detallado y suficiente para leer en dos minutos, junto a referencias de correos de años anteriores en los que un líder técnico los explicaba a un cliente. Pero añadió también referencias a páginas de Confluence que yo mismo había creado meses antes y que ya ni recordaba.

Si ahora queremos dejar nuestro trabajo documentado, mejor buscamos cómo dejárselo fácil a la IA para que lo indexe bien y sea rápido de encontrar para quien lo necesite.

Genial el post de María Sol Souto: «Dejen de pedir features, en serio».

https://lnkd.in/dwKgu9pd

A veces no tenemos muy claro qué hacer, queremos mejorar y vender más el producto, pero sin una estrategia clara, solo pequeñas «brillantes» ideas que todo lo más, van a conseguir unos pocos clics más en el producto, cuando no a restar ventas.

Pensamos que hay que hacer algo, que hay que buscar con qué entretener al equipo de trabajo. Si estamos haciendo algo, lo que sea, nos sentiremos bien, pero nos está acercando en algo al objetivo?

No puedo evitarlo, pero esta es la imagen que me vino a la cabeza cuando alguien sugirió hace unos días poner Pair Programming en todos los equipos de trabajo de la empresa:

Imagen obtenida de Imgur: https://imgur.com/gallery/2-hamsters-1-wheel-9000-amusing-level-gvdbyg8

Algunos gobiernos, como los de USA, tienen fuertes requisitos para la gestión de sus datos CUI (datos clasificados no controlados). Solo ciudadanos americanos, y con residencia en Estados Unidos, pueden tener acceso físico o lógico a esa información. Son datos con un nivel de protección muy alto que la administración de ese país no quiere que circulen fuera de sus fronteras

Cuando todos los proyectos alrededor del mundo se están migrando a la nube por sus ventajas de gestión y económicas evidentes se hace cada vez más difícil garantizar el control de la información. ¿Quién la lee? ¿Quién la copia? ¿A dónde la envía? Para eso Amazon y otros empresas han soluciones como AWS GovCloud que están operadas exclusivamente por personal estadounidadense que reside allí.

Europa tiene también exigencias muy altas para el control de su información, normalmente relacionadas con la RGPD y la privacidad de la información. Amazon tiene también regiones aquí (Madrid, Frankfurt, París, etc.). Por ejemplo, la administración pública española puede usar AWS Europa (Madrid) que tiene sus servicios certificados para ENS (Esquema Nacional de Seguridad) y RGPD.

Cada vez se irá viendo más claro que apostar por centros de datos locales que no pueden llegar ni de cerca a los servicios de seguridad, velocidad y fiabilidad que pueden ofrecer las nubes de Amazon o Azure no va a ser la mejor de las opciones. Cuanto antes apuesten por una nube segura, como en el 112 de Canarias, mejores servicios tendremos los ciudadanos.

Después de ver este tweet, uno cae en la cuenta de que probablemente también esté procrastinando más de lo que debería:

https://lnkd.in/dtHJbMPC

Ver podcasts, leer libros, aprender sobre Cloud o Economía, pero ¿qué se hace después con todo eso? Probablemente nada. Solo sentirse bien porque estás aprendiendo, y seguramente haciendo algún pequeño progreso, pero si no lo pongo en práctica, si no me remango la camisa y arranco con algo, dificilmente voy a conseguir los beneficios de ese aprendizaje.

Puede que a veces sea necesario dar un golpe en la mesa para conseguir un cambio, una reacción, pero ¿es eso todo lo que puedes hacer?

Si tienes un problema, o tienes que hacer una entrega es posible que te funcione dar un toque de atención, pero si dos semanas después hay otro incidente en producción que no se resuelve, o cada final de mes tienes que volver a dar otro toque de atención para que te hagan caso, para que “se pongan las pilas”, me temo que esto no te está funcionando.

Revisa el problema de fondo y descubre qué está atascando al equipo ¿Son las pruebas insuficientes y por eso hay tantos errores? ¿Están los requisitos mal redactados? ¿Tu gente tiene el conocimiento suficiente para hacer el trabajo? Descubre qué está pasando y pon medidas para resolverlo.

Gobernar por impulsos, llamar la atención y echar broncas va a conseguir una mejora repentina de la fiebre, pero no del problema. Saldrás del atasco y salvarás la cara por unos días. Solo hasta el siguiente problema. Además, seguramente estarás retrasando todo lo otro que no está bajo la línea de fuego ahora. Sin embargo, lo estará en breve, cuando se pase esta alarma y alguien descubra que se desatendió el resto del trabajo durante días.

Tengo malas noticias: no va a ser rápido, no va a ser fácil, pero es la única forma de mejorar un poco. Van a pensar que no estás haciendo nada, que hace falta alguien que dé un golpe rápido de timón, pero no creo que ningún barco llegue a buen puerto a base de dar bandazos de un lado a otro según alguien reclama tu atención aquí o allí.

Algo de esto le ha pasado a Agile. Primero cayó en combate el Scrum Master. Al poco tiempo hablar de Scrum ya sonaba a viejuno. Por último, todo lo que suene a Agile recuerda ahora a los vendedores de aceite de serpiente del salvaje Oeste. Te vendían el mismo remedio como bueno para tratar la caída del cabello, el reuma o la artritis. Incluso para conciliar el sueño y teñir el pelo. Si usabas bien la loción, podía hasta salvar proyectos con alta rotación de personal.

No todo lo que daba vueltas alrededor de Agile se puede declarar difunto o simple humo. Los valores y principios básicos continuarán con nosotros mucho tiempo. Reformulado quizás, con un nuevo nombre y marketing, pero colaborar con el cliente, adaptar los requisitos y entregar pronto algo de código que ayude al usuario, eso dificilmente va a cambiar.

Ver el post de Amalio A. Rey en LinkedIn: https://www.linkedin.com/feed/update/urn:li:share:7374501464880254976/

Estos días leía un libro de arquitectura software en el que te aconsejaba: «No escribas documentación de más de 5 páginas. No se la van a leer».

Y ahora qué hago yo con los documentos de 40-60 páginas que escribí hace solo unas semanas!?

Me temo que tiene mucha razón. Veo los accesos a esos documentos, y apenas hay visitas. Solo unas pocas personas accedieron a ellos, y estoy seguro de que la mayoría solo le echaron un vistazo al índice y pulsaron Control-F para buscar algún término que les llevara directamente al grano.

Si quiero que estos documentos sean útiles, creo que mejor paso esos docs Word a páginas Confluence con solo un par de páginas por sección y unos pocos párrafos explicando lo impresicindible. Como máximo!

He creado hace unas semanas otro pequeño proyecto en AWS para poner en práctica mis conocimientos en la arquitectura software con la nube de Amazon: una API serverless para la creación de cuentas y su jerarquía.

Este proyecto usa:
– AWS Lambdas con Python
– API Gateway
– Dynamo DB
– SNS para eventos de domino

En este enlace de GitHub puedes ver el código completo y el diagrama de la arquitectura: https://lnkd.in/eHNHFyf4

Hace eones construíamos una aplicación para una administración pública en la que el arquitecto software no se decidía nunca por ningún diseño para la aplicación. Y si múltiples usuarios se conectan a la vez? Y si se vende a otras administraciones y se multiplican los accesos? Mejor añadir más colas de mensajes, y throttling, y límites por cuenta, y…

Nada era nunca suficiente y la aplicación no se empezaba a desarrollar. La realidad es que el servicio solo tenía tres técnicos en Las Palmas. Quizás otros dos o tres más en Tenerife. Aunque todas las comunidades autónomas del país migraran a nuestro sistema, probablemente tendríamos menos de 170 posibles usuarios en total. Cuántos podrían estar conectados a la vez a las 9:35 de la mañana o a las 12:51? Cinco, diez?

Parálisis por análisis lo llaman. A veces los ingenieros software usamos la tecnología como excusa para no tomar decisiones, para no poner el cuchillo entre los dientes y empezar a programar. Era más importante que nunca evitar la complejidad innecesaria, la over-engineering, o aplicar el principio YAGNI (You Aren’t Gonna Need it).

Por más vueltas que les des no vas a evitar al 100% la posibilidad de cometer un error. Nunca. Siempre podrás mejorar el diseño 2 años después de haber propuesto el primer diseño. Y otros 2 años más tarde también pensarás que la nueva propuesta era aún bastante mejorable. Y así indefinidamente.

Haz un borrador, pruébalo, mejóralo luego y vuelve a probar. Todo diseño se basará en trade-offs. Todos son una apuesta. Si solo piensas en las desventajas, nunca aprovecharás ninguna ventaja.

Cuando tenemos que tomar un decisión y, o no nos terminamos por decidir, o tomamos la decisión incorrecta, estos son probablemente los 4 villanos que pueden haber intervenido:

1. Limitamos incorrectamente las opciones que tenemos. Mejor pensar, ¿puedo hacer esto Y también aquello? No limitarlo a opciones binarias: ¿debo ir a la fiesta o no? (puedes ir 30 minutos o puedes hacer otra cosa en lugar de ir a la fiesta). Si tienes que decidirte entre un equipo de música u otro, escoge el estereo más barato y la diferencia la compras en CDs para escuchar con el estereo (coste de oportunidad).
2. Sesgo de confirmación: buscamos información que apoye lo que ya opinamos (y descartamos aquella que no apoya lo que ya hemos decidido de antemano).
3. Pensamiento de corto plazo: ¿qué haría mi sucesor si me sustituyera? ¿Cierro el proyecto que está drenando recursos de la empresa? No lo haces porque llevas mucho invertido en él, pero si te sustituyen, tu sustituto ni pestañearía en darle carpetazo.
4. Tener mucha fé en tus predicciones. Estimas que ganarás un 20%, seguro que sí, y apuestas hasta la camisa a tus cálculos. Pero un baño de realidad puede dejarte frio luego.

Referencias: Libro Decisive de Chip and Dan Heath.

Les comparto las notas que tomé de uno de los libros de Taleb sobre lo que él considera un error: pensar que la educación lo es todo.

• La brújula de un barco parece que es la que dirige al barco, pero en realidad el barco tiene su rumbo y la brújula solo lo indica.
• Que la educación genera riqueza parece ser otro epifenómeno. Corea o Taiwán tenían hace décadas mucha menos alfabetización que Argentina o Filipinas, pero el PIB de los primeros multiplica ahora al de los segundos. Por la misma época el África Subsahariana aumentó sus niveles de educación, pero su riqueza bajó.
• La relación puede ser al revés. Genero riqueza -> los niños estudian.
• Ojo con pensar que la educación lo es todo en los negocios: los corredores de la bolsa de NY eran de origen obrero y no sabían dónde estaba Suiza. Los corredores de la bolsa de Londres eran cockneys que se emborrachaban al mediodía antes de que abriera la bolsa de NY.
• Un comerciante de éxito en la venta de maderas verdes (maderas cortadas que aún no se han secado) pensaba que estas maderas se llamaban así porque las pintaban de verde.
• Tony el Gordo hizo 18 millones invirtiendo 300K porque no hizo caso a todos los estudios de la economía que predecían que la guerra de Irak iba a multiplicar el precio del petroleo. Él apostó a que bajaba.
• La asunción de riesgos antifrágiles, no la educación y ni la investigación organizada y formal, da lugar a la innovación y el crecimiento.

Los problemas de agencias son aquellos ocasionados por un conflicto de intereses entre las personas involucradas en un negocio. Cuando en un empresa nos colocan como responsables de un producto o equipo, el dueño de la empresa o sus representantes están colocando un «agente» para que cuide de sus intereses en su lugar.

Pero lo hacemos bien? Hacemos siempre lo mejor para el producto o tomamos las mejores decisiones en lugar de los accionistas? Si tuviera que poner de mi bolsillo los 30K para desarrollar una nueva funcionalidad (el coste de varios desarrolladores programando unos meses) quizás decidía no hacerla, o sopesarlo mucho más de lo que lo hago ahora. Si no hubiera agente de por medio, si los 30K salieran de mi cuenta bancaria, estoy seguro de que el filtro para aprobar un nuevo desarrollo sería mucho, mucho más duro. Me haría y haría a los demás muchas más preguntas. Realmente vale la pena? Habrá quién pague por la nueva funcionalidad o es solo la idea feliz de quién piensa que va a quedar «cool» tener una nueva aplicación?

Al ver salir cada mes el dinero de mi cartera estaría realmente preocupado por si el equipo está trabajando en esto o están distrayéndose con otras tres prioridades al mismo tiempo y tardando el doble de tiempo (que me va a costar otros 30K). Si tuviera que pagarlo yo, no creo que convocase a 12 personas a una reunión de diseño dos veces por semana en la que solo hablan dos personas el 85% del tiempo (y solo lo hacen para llevarse la contraria).

«Algunas veces, la mejor manera de defender una posición, es exponer sus defectos«.

Creo recordar que encontré esta frase en el libro Decisive de Chip & Dan Heath. Cuando tengas que tomar un decisión, pocas habrá que solo tengan ventajas. Incluso si no las ves ahora, todas tienen su desventajas.

Busca esas desventajas, exponlas, explícalas, y si aún así toman la decisión, los que te hayan escuchado sabrán que las tuviste en cuenta y que a pesar de ello valoraste más los pros que los contras.

En caso contrario, si solo tratas de vender la idea explicando lo buena que es, no va a faltar quién te saque los colores a cada pequeño revés y te recuerde que quizás no lo pensaste demasiado.

Suele decirse que en épocas difíciles el mejor banco está en el estómago de tu vecino por aquello del hoy por ti, mañana por mí, pero parece que el ama de casa de la antropóloga Elizabeth Colson tenía teorías distintas en The Narrow Corridor. Interesante, cuando menos:

The Ghost in the Granary
In 1972, the anthropologist Elizabeth Colson was in the midst of her fieldwork among the Gwembe Tonga, a people of southern Zambia who had been stateless prior to the conquest of the region by the British (…). She was at a homestead collecting information when a woman entered and asked the resident housewife for grain. Both women were members of the same clan, but they lived quite far apart and only knew each other vaguely. In response to the request the housewife went to her granary and filled the visitor’s basket until it was overflowing and the visitor departed satisfied.
This type of generous sharing of food within clans, kin, or other types of groups is common among many stateless societies. It is interpreted by most anthropologists and many economists as a sign of deep-rooted customs and norms of cooperation and reciprocity. It also has a clear economic logic: today you help somebody from your clan, and tomorrow when you need it, they will help you. This is exactly how Colson initially interpreted this ostentatious generosity.
It was only later, when she observed a young man in the village receiving a disturbing letter from home, that Colson came to understand that the reality was rather different. She recorded in her field notes, “One evening, lights had been seen about his granary and his wives and brother had later found evidence that ghosts had urinated over the grain, an act which Tonga believe ghosts carry out only if sent by a sorcerer.” The likely aim of the sorcerer was to kill the man and his family. He lamented that “his ambition of the previous year—which had led him to work early and late in the large field he had planted—was now bringing him only a harvest of hate.” The same housewife, who was present, immediately grasped what was going on. Colson went on: “She thought someone must have visited his homestead and seen all the granaries, and she asked if he could remember anyone having stood to gaze at them or asking for food or making any comment about all that food.” The housewife concluded:
It is not safe to deny them. You saw me give grain to that woman who came the other day. How could I refuse when she asked me for grain? Perhaps she would do nothing, but I could not tell. The only thing to do is to give.
Not giving risked sorcery and violence. It was fear, fear from retribution and violence that would follow if she broke the norm, not some abstract notion of generosity, that made her give.

Hace unos años era la Universidad de Buenos Aires (UBA) la que incluía mi primer libro en la bibliografía de una de sus asignaturas. Para el curso que comienza ahora, será la Universidad de Vigo la que incluya mi libro entre la bibliografía básica de la asignatura de Aprendizaje basado en proyectos de su Grado en Ingeniería Informática en la Escuela Superior.
Muy contento!

Enlace a la Bibliografía de la asignatura de Aprendizaje basado en proyectos de la Escuela Superior de Informática en el grado de Ingeniería de la Universidad de Vigo.

Aquí un enlace al libro en Amazon: Gestión práctica de proyectos con Scrum.

Según los economistas, la pobreza y la prosperidad son como dos imanes. Si estás cerca de uno de esos imanes, te atrae hacia él.

Si eres pobre pero te dan un buen empleo, te separas un poco pero a poco que te rompas una pierna y tengas que pagar el seguro médico, o tengas que endeudarte para comprar un coche, vuelves rápido a la mala situación (el imán de la pobreza te atrae de nuevo). Es difícil despegarse de esa atracción y moverse hacia el campo del otro imán al otro extremo, el de la prosperidad.

Se demostró en Bangladesh con gente de extrema pobreza a la que se les dio una vaca a cada familia seleccionada en el estudio y se les dijo que no la vendieran o se la comieran en unos dos años. Su economía mejoró por un tiempo, pero al poco volvieron a su nivel de pobreza anterior.

En cambio en el lado del imán de la prosperidad, todo te ayuda a mantenerte próspero. Tienes un buen trabajo, y por tanto experiencia en alto nivel, o dinero para pagar títulos y certificados. Si lo pierdes, tienes más posibilidad de conseguir algo similar, y volver a tu nivel de vida anterior. Tienes contactos y amigos en puestos de responsabilidad que pueden ayudarte. Además tienes posiblemente más ahorros ya que has estado ganando más y así no tener que endeudarte hasta las cejas con cada crisis. Si caes en el paro, puedes pasar el bache, invertir en un máster, llamar a tus contactos en puestos de gestión. Hay un abanico de posibilidades que pueden ayudarte.

Con esa ayuda y un poco de suerte, el imán de la prosperidad volverá a atraerte hacia él.

Referencias:
– https://lnkd.in/d3ej3mtU

Cal Newport habla de la pseudo productividad: somos premiados por el exhaust (el humo o la polvareda) visible que producimos al trabajar y no por el valor real del trabajo producido:
– Los trabajadores que fuman con jefes que a su vez fuman también tienen más posibilidades de ser promocionados (como veíamos en Friends, se establecen relaciones más cercanas y se difunde más el trabajo que hacen los que fuman).
– Se sabe que los trabajadores remotos producen un 13% más de media que los que no trabajan remoto (tenemos menos distracciones quizás) y están más contentos con su trabajo por lo que lo abandonan menos. Sin embargo los trabajadores en remoto tienen un 50% menos de posibilidades de ser promocionados. Nadie los ve trabajar. No los vemos atareados todo el día y pensamos que seguramente no están haciendo nada.
– Los profesores universitarios tienen dos funciones: enseñar e investigar. Sin embargo, suelen ser considerados solo por la investigación. Es lo más visible, y se puede contar fácilmente los papers que producen, pero ¿quién se sienta a ver cómo da clase otro profesor y cómo engancha a sus alumnos?

Referencias:

• https://www.youtube.com/watch?v=cMNGFx7FzRc