Welcome!

Hello and welcome to my page, the meeting point of my activities. My name is Fede Andino and I’m working at something that I’ve named Culture Crafting. It’s not something very solid yet.

There’s a classic book. the Cathedral and the Bazaar. In it, there are two models presented for something that is built: a Cathedral, an organized vision of a particular mind and a Bazaar, an organic aggregation of ideas and people over time. My art is not a cathedral, nor yet a bazaar but rather a well-attended Inn at the crossroads of IT work, Management, Mindfulness, Agile, Lean and Storytelling. In time, it is my hope that it may be a bazaar or its even better cousin, the Souk: a vibrant place with a lot of tradition. But it is not there, yet. It’s just a cozy inn, at this time.

In this site I’ll post my work ideas, my pics and videos and also all the social networks that I’m currently working on.

Come on in and have a seat!

I wrote another book!

Scientific Mindfulness is here!

🌟 I wrote a book. Here’s why. 🌟

For years, I’ve dedicated my research and teaching to mindfulness—from academic work at Sigeva, Cari, Rieb and Universidad del Salvador, to corporate mindfulness programs at IBM, to community workshops in schools, hospitals, and prisons.

One thing became clear to me: mindfulness needs to be both accessible and scientifically rigorous. Too often, it is presented either as mystical or overly simplified, missing the depth and evidence that support its transformative power.

That’s why I wrote Scientific Mindfulness.

This book is a four-week, evidence-based program that integrates breathing, body awareness, mindful eating, and mindful walking. Each practice is explained clearly and supported by peer-reviewed studies, systematic reviews, and decades of clinical research.

What sets this book apart:
🔹 Trauma-sensitive guidance – acknowledging that practices can surface difficult emotions, with options to adapt or pause.
🔹 Medical & psychological cautions – encouraging responsible and safe practice.
🔹 Inclusivity – adapting mindfulness for diverse bodies, backgrounds, and neurodiverse experiences.
🔹 Context for quotes & references – so readers know why voices like Thich Nhat Hanh or Jon Kabat-Zinn matter.
🔹 Normalizing challenges – because mindfulness isn’t always easy, and that’s okay.

My hope is that this book empowers readers to practice in a way that is not only effective but also safe, inclusive, and sustainable.

👉 It’s now available on Amazon:
https://a.co/d/9nYXIj9

If you’ve ever wanted to explore mindfulness backed by science—not just inspiration—this book is for you.

hashtagMindfulness hashtagScientificMindfulness hashtagMeditation hashtagEvidenceBased hashtagBookLaunch hashtagWellbeing hashtagTraumaSensitive

The CLEAR framework for Business AI

Based on Nick Saraev's approach

The CLEAR system by Nick Saraev

I’ve just seen a very interesting framework for creating good AI. The CLEAR system, as explained by Nick Saraev.

For me, it ticks a lot of boxes that I find useful. It is concise, useful, and portable.

Let’s review it:

C — Clarity

Define the problem precisely with measurable outcomes.

  • ❌ Bad: “Build me a lead gen system.”

  • ✅ Good: “Create a one-page lead qualification SOP for companies with 50+ employees in manufacturing that expressed interest in automation in the last 90 days.”

🔑 Tip: Always specify who, what, when, where, how many.


L — Logic

Break the task into clear, sequential steps with decision points.

Example: Lead scoring system

  1. Collect leads from LinkedIn ads + cold email.

  2. Score leads based on company size, industry, and engagement.

  3. Route high scores to sales reps, medium scores to demos, low scores to nurturing.

AI thrives on structured flows instead of vague instructions.


E — Examples

Provide scenarios and edge cases to guide consistent outputs.

  • If score ≥ 80 → Assign to senior sales rep + Slack notification.

  • If 50–79 → Auto-schedule a demo.

  • If < 50 → Send to 6-week nurturing email campaign.

🔑 Tip: Don’t just say “qualify leads”. Show AI the rules of the game.


A — Adaptation

Iterate with the AI instead of expecting perfection in one shot.

  • Start: Draft prompt for the workflow.

  • Refine: If output misses something, feed corrections back in.

  • Evolve: Adjust until the solution matches real-world constraints.

Think of prompting as conversation + testing, not a one-off command.


R — Results

Validate the solution against business goals & ROI.

Ask:

  • Does the workflow integrate into existing tools (e.g., HubSpot)?

  • Can we measure conversions or cost savings?

  • Does it solve a $50k+ problem (Nick’s benchmark for “valuable problems”)?

🔑 Tip: Always tie AI work to business outcomes (more revenue, more clients, lower cost).


🔍 Two Prompts Compared

Without CLEAR
“Build me a lead generation system.”

👉 Output = generic, inconsistent, AI picks random tools.

With CLEAR
“Create an automated lead qualification system for a B2B manufacturing consultancy.

  • Inputs: LinkedIn ads + cold email.

  • Scoring rules: 50+ employees = 30 pts, Manufacturing industry = 25 pts, Downloaded whitepaper = 20 pts, Booked demo = 40 pts.

  • Routing: ≥80 → senior sales rep (Slack notification), 50–79 → auto demo scheduling, <50 → nurturing sequence.

  • Integrate with HubSpot and track conversion rates.”

👉 Output = structured, reliable, ready to deploy.


🧩 Why CLEAR Matters

  • Clarity prevents vagueness.

  • Logic structures workflows.

  • Examples enforce consistency.

  • Adaptation makes results practical.

  • Results ensure business value.

In 2026+, those who master CLEAR will be the “translators” between business needs and AI capabilities—the real high-value skill.

Let’s take an example. Let’s say that we need to automate things for a mid-sized company.

What would CLEAR look like there?

C — Clarity

Define precise, measurable automation goals.

  • Example: “Reduce invoice processing time from 7 days to 2 days”

  • Example: “Cut employee onboarding steps from 10 forms to 5 digital workflows.”


L — Logic

Break processes into sequential steps with clear decision points.

  • Example: Expense approvals → Department Head → Finance → Automatic payment.

  • Example: Customer support requests → Categorize by urgency → Route to Tier 1 or Tier 2 support.


E — Examples

Provide edge cases to make automation robust.

  • If invoice > $10,000 → Require CFO approval.

  • If lead is from manufacturing sector + company size > 100 → Route to enterprise sales team.

  • If employee doesn’t upload ID during onboarding → Trigger automated reminder email.


A — Adaptation

Iterate with AI + staff feedback until workflows stabilize.

  • Test automation with small pilot group.

  • Adjust triggers (e.g., Slack notifications vs. email) if teams miss alerts.

  • Refine workflows monthly as new software or policies emerge.


R — Results

Tie automation to ROI & business outcomes.

  • Track: Hours saved per week, % faster onboarding, error reduction, cost savings.

  • Example: Automated invoice approval saves 200 hours/month = $15,000/month in labor.

  • Example: Onboarding automation increases employee readiness in first week by 30%.


For example, a Prompt could be:

Using the CLEAR framework (Clarity, Logic, Examples, Adaptation, Results), create a business automation strategy for a mid-sized B2B services company (~200 employees). The strategy should define measurable goals, break down workflows step-by-step, include real use cases with edge cases, suggest adaptation methods as the company grows, and deliver measurable results tied to ROI. Present it as a structured business plan.

This generates a very usable, point by point strategy that you can follow up, with metrics and KPIs aplenty.

What do you think of CLEAR?

Nuevas promesas, viejos políticos, One Piece

#Nepal y la situación de la nueva (vieja) política

Revuelta en Nepal (fuente: CNN)

Para más información, pueden consultar la página del Grupo de Trabajo de Asia del Sur en el Cari (del cuál soy miembro) o escuchar mis entrevistas en Radio Buenos Aires, Sputnik o ADN.

Ahora que están de moda de nuevo las brujas.

Ahora que Rosa Pascal (Venus Psíquica, en Instagram) es citada por todos los medios.

Ahora que el Tarot es una herramienta de estado.

Yo voy a hacer una predicción, con el más terrible de los oráculos: los procesos históricos.

Mi predicción es: hay algo que se esfuerza en nacer, en múltiples países. Hasta ahora viene siendo abortado, muchas veces de forma violenta. Pero sigue intentando.

Es algo que surge de los diferentes movimientos antipolítica y busca, de alguna manera, ser una nueva forma de política. Pero este movimiento es

“Un Estado multiétnico, multilingüe, multicultural, inclusivo y federal.”
Preámbulo de la Constitución de Nepal (2015)

El camino de Nepal hacia un sistema representativo moderno es uno de los más turbulentos y fascinantes de Asia.

Podemos resumirlo de la siguiente manera:

  • Acto 1: El pueblo Nepal se organiza en una sociedad democrática
  • Acto 2: Alguien de la oligarquía (generalmente, con apoyo externo) viene y les dice “No, esto de la democracia no es para ustedes, vamos a un gobierno autoritario”
  • Acto 3: El pueblo Nepalí se rebela y vuelve al acto 1

Desde la oligarquía Rana (1846–1951), pasando por el breve experimento democrático de 1959, la monarquía autoritaria del Panchayat (1960–1990) y las dos grandes revoluciones populares (1990 y 2006), el país ha buscado una y otra vez responder a la pregunta: ¿cómo incluir a todos en un Estado tan diverso y afianzar la democracia en una sociedad tan sacudida por el autoritarismo?

Veámoslo en acción

Acto 1

En 1951, tras la caída de los Rana, Nepal ensayó por primera vez el multipartidismo. B.P. Koirala fue elegido en 1959 como primer ministro en elecciones libres, peeeero

Acto 2

apenas un año después el rey Mahendra disolvió el parlamento y estableció el sistema Panchayat, un régimen “sin partidos” que concentraba el poder en el trono.

El Rey Mahendra. Fuente: Wikicommons

Durante treinta años, la representación política fue mínima. El rey se presentaba como garante de la “unidad nacional” frente a India y China, pero en la práctica anulaba cualquier pluralismo.

Acto 3

En 1990, la Jana Andolan I (Movimiento Popular) derribó el Panchayat y restauró el multipartidismo bajo monarquía constitucional. Sin embargo, la inestabilidad, la corrupción y la exclusión persistieron.

De este caldo de cultivo surgió la insurgencia maoísta (1996–2006), que denunció la marginación de campesinos, minorías étnicas y mujeres. El conflicto armado dejó más de 13.000 muertos, pero también abrió paso a una nueva transformación: el acuerdo de paz de 2006, la abolición de la monarquía en 2008 y el inicio de la república federal.

Las Protestas del 2006. Fuente: Wikicommons

Vamos de nuevo al Acto 1

Tras años de asamblea constituyente y fuertes disputas (particularmente con la comunidad madhesí en el sur), en 2015 se promulgó la Constitución de Nepal. Sus pilares representativos son:

  1. Federalismo: 7 provincias con gobiernos y asambleas propias, además de 753 municipios y consejos rurales.

  2. Sistema mixto electoral:

    • 165 diputados elegidos directamente (mayoría simple).

    • 110 escaños por representación proporcional.

  3. Cuotas de inclusión: en las listas proporcionales los partidos deben garantizar la participación de:

    • Mujeres (mínimo 33%).

    • Dalits (castas históricamente discriminadas).

    • Adivasi janajatis (pueblos indígenas).

    • Madhesíes, tharus, musulmanes y comunidades de regiones atrasadas.

  4. Comisiones de inclusión: instituciones autónomas para velar por los derechos de mujeres, dalits, indígenas, madhesíes y otros grupos.

Como escribió el constitucionalista Krishna Hachhethu:

“La Constitución de 2015 es más que una carta política: es un pacto social que reconoce la diversidad como fundamento del Estado.”

Peeero, Acto 2

Khadga Prasad Sharma Oli (conocido como K.P. Oli) fue la figura política dominante del período republicano. Líder del CPN-UML, ejerció como primer ministro en tres mandatos anteriores (2006, 2015–16, 2018–21) y nuevamente desde julio de 2024 en su cuarto mandato.

Su estilo se caracterizó por:

  • Nacionalismo: retórica fuerte frente a India, acercamiento estratégico a China (incluido un acuerdo de tránsito en 2019 para reducir la dependencia india).

  • Centralización del poder: tendencia a gobernar por decreto, debilitando instituciones colegiadas.

  • Autoritarismo legal: en 2020 y 2021 intentó disolver la Asamblea de Representantes, argumentando bloqueos parlamentarios. La Corte Suprema anuló ambas disoluciones por inconstitucionales, marcando un duro enfrentamiento entre el poder judicial y el ejecutivo.

Sharma Oli. Fuente: Wikicommons

Estas disputas minaron su legitimidad y consolidaron su imagen de “hombre fuerte” pero poco comprometido con el espíritu inclusivo de la Constitución.

Y ahora, nuestro Acto 3 actual

En septiembre de 2025, el gobierno de Oli ordenó la prohibición de 26 plataformas de redes sociales (Facebook, WhatsApp, Instagram, TikTok, YouTube, Reddit, etc.), alegando que no habían cumplido con el registro local exigido por la nueva Ley de Medios Sociales y que propagaban “desinformación”.

La medida fue vista como un intento de censura contra la generación más conectada digitalmente. La reacción fue inmediata:

  • Nació el lema #NepoKid, denunciando el nepotismo de los partidos, incluidos los “marxistas dinásticos”.

  • Las protestas juveniles se multiplicaron en Katmandú y otras ciudades, lideradas por activistas como Sudan Gurung (Hami Nepal).

  • La represión policial dejó 19 muertos y cientos de heridos.

Pese a levantar el bloqueo días después, el país ya estaba en llamas: residencias de líderes políticos fueron incendiadas y ministros renunciaron en masa. Finalmente, el 9 de septiembre de 2025, Oli dimitió afirmando que lo hacía “para allanar el camino de una resolución constitucional”.

Protesta en Nepal. Fuente: Aljazeera

Entonces ¿qué podemos observar del recorrido que hicimos?

Varias cosas:

  • La historia constitucional de Nepal es la de un péndulo entre exclusión y apertura. Si el Panchayat impuso un “silencio democrático” durante tres décadas, la Constitución de 2015 buscó lo contrario: un coro plural de voces.
  • Sin embargo, la experiencia de Oli demuestra que las reglas no garantizan la práctica: intentos de disolver el parlamento, concentración de poder y censura digital reavivaron el fantasma del autoritarismo.
  • Las protestas Gen Z y el grito #NepoKid marcan una nueva etapa: la exigencia de una democracia no sólo inclusiva en los papeles, sino ética, meritocrática y genuinamente representativa.

En el momento que escribo estas líneas, todo está en suspenso. Quizás figuras carismáticas como Sudan Gurun (sudangrg_haminepal en Instagram) pueda canalizar los reclamos y finalmente, establecer un sistema político más estable. Quizás se vuelva al Acto 1, una vez más.

Pero hay nuevos elementos, la lógica de las redes, símbolos que antes no aparecían.

La Bandera de Luffy como símbolo. Fuente: Mathurbhumi

La presión del reclamo, de lo nuevo que aún no es, se incrementa. Los ministros corriendo desnudos, escapando del pueblo que les reclama lo que prometieron y no cumplieron.

Los Straw Hat Pirates como símbolo de una revolución global.

Algo a pensar en el resto del Sur Global.

Lecturas recomendadas

  • Hutt, Michael (ed.) Himalayan People’s War: Nepal’s Maoist Rebellion (Indiana University Press, 2004).

  • Lawoti, Mahendra Towards a Democratic Nepal: Inclusive Political Institutions for a Multicultural Society (Sage, 2005).

  • Upreti, Bishnu Raj et al. Nepal Transition to Democracy: Politics of Constitution Making (Springer, 2012).

  • Whelpton, John A History of Nepal (Cambridge University Press, 2005).

  • Constitución de Nepal (2015) — disponible en inglés en la web del gobierno de Nepal.

Help me to create the Scientific Mindfulness course!

Hi, I’m Dr. Federico “Fede” Andino—researcher, Buddhist teacher (Lama Fede), and mindfulness practitioner with over 20 years of experience. I’ve spent my career studying meditation (BA, MSc, PhD, and postdoc work on Tibetan practices), teaching it globally—at schools, prisons, hospitals, and corporations like IBM, where I’m a researcher on Mindfulness—and building communities around it. I’ve written books, led studies, and even chaired the Tibetan Religion class at Universidad del Salvador for 15 years.

Now, I’m pouring all that into a new 4-week, science-based mindfulness course to help you sharpen focus, reduce stress, and thrive through practical techniques and community support.

 

Here’s the deal: I’m opening 10 free spots for my first group, starting soon. In return, I’d love for you to try it out and share a short, honest report on what worked, what didn’t, and how I can make it even better. That’s it—no strings attached. My goal? To refine this into something truly impactful, with your input.

If you’re curious about mindfulness, want to boost your well-being, or just love a good experiment, just sign up here: https://federico-andino-s-school.teachable.com/p/scientific-mindfulness-meditation-for-the-masses

First 10 get in, free. Let’s build something great together!

#Mindfulness #Wellbeing #Community #PersonalGrowth #ScienceBased

AIAA 3rd Jam – Sizing

Or how we use AI to check maturity of estimations

I’m going to be excommunicated from Agility for this.

But, in this article, I’m going to propose a way to leverage a maturity level assessment based on a relative estimation that will increase the ease of working between cells/squads/pods/teams in an Enterprise Environment by a significant degree.

How am I going to do it?

It relies a lot on groundwork and consensus.

What do I mean? Let me explain.

The Assumptions

We all know how to do an estimation via Planning Poker in Scrum, right? I’m going to assume that yes, we do. Also, I’m going to assume that you’re following a system based on the Scrum Bible at scrum.org, in an Enterprise setting. You have cells doing work in User Stories, Features and Epics, in two-week Sprints.

You’re also using User Story Points to measure them in the usual changed Fibonacci: 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Do this make sense? If not, tweak it to your preferred values.

The Consensus

We need to set a consensus. It’s going to be arbitrary, but it will help have a frame of reference.

Our consensus is twofold: we can set all the Sprints for two weeks. We will also do this: we’ll assume that 8 User Story Points are the maximum that a single person can produce in a Sprint. Taking this into account, 8 USPs are two weeks. 3 USPs is roughly one week, 5 means a week and some days, 2 more than a couple of days but less than a week and 1 a couple days at most.

Yes, these are rough estimates; that’s the idea. We cannot, at the estimation point, be so precise that we zero in an exact number of hours. When we will know how much it costed? We will know how much the User Story costed after we finish it.

As a bonus point, we can come back later on to check on the cost of the User Story later on.

So, if we follow the usual distribution for Scrum, we can think of a User Story as something that’s going to be taken care in one Sprint (ideally). Therefore, for a 5 person squad/cell, the maximum ideal length of a User Story should be 40 USP (8 USP per person times five).

If we use the 3 Sprints for a release, then Features will be in the 100-120 USPs range (40 times three). And Epics, being worked within quarters, will probably be between 120-240 USPs.

(of course, adjust to size and capacity)

Where does this leaves us? We can use it to check that User Stories, Features, and Epics are estimated, sized, and split correctly.

The Prompt-craft

This is going to take some work. I’ve created a list of Epics, Features and User Stories.

You can download it here.

Now, let’s see if we can get the AI to do the work for us. But this is going to take some explaining.

I’m going to use ChatGPT (on version 4o with Canvas) to get it to understand what we want.

I am an Agile Coach trying to understand if the Epics, Features and User Stories at my work are correctly sized. For that, I have reached this consensus in which a person can only produce 8 User Story Points per Sprint, and a user Story can only take one Sprint. Therefore, the maximum a User Story can be sized is 40 User Story Points for a Team of 5. I also have reached a consensus that a Feature should be produced between one Sprint and three Sprints, therefore, between 40 User Story Points and 120 User Story Points for a team of 5. And an Epic is at most Two Features, that are produced each Quarter, so between 80 and 240 User Story Points for a team of Five. I have the following list of Epics, Features and User Stories. Can you analyze it and let me know which Epics, Features and User Stories are mis-sized? Take into account the team size relative to the sizing. Write an output explaining those who are not acceptable.

Whew! That was a mouthful, wasn’t it? But we can see that we use the role-playing that we introduced last time and now we’re introducing another concept: assumptions.

What does this produce?

Not only a list of the specific issues, and recommendations…

…but a list of general recommendations.

This produces a workable, actionable list of our next focus.

If we run this, we can have some idea of the maturity of our Backlog in terms of sizing.

Hope this is useful and let me know how it works!

#aiaa #ai #agile #backlog #automation

 

 

AIAA Jam 2

Epic Rockin'

Have you ever wondered why you are working in Agile?

This should be a simple question to answer; hopefully, it is because you can increase value meaningfully.

But is it easy, though?

Have no fear! If you struggle to find that answer, in my experience the answer lies in one place: the Epics.

Don’t limit the Epics to just being a collection of user stories and features. It should provide a place to answer a simple question: Hey, I’m giving you this much $$$. How can this result in a profit for the company?

In real-world Agile, this isn’t true. The most underdeveloped part is the Epics. The purpose is to proceed to the development part quickly. Instead of moving towards a Technological Business, a badly done Epic reinforces the idea of standalone areas.

Well done Epics foster visibility and meaning.

Badly done Epics obscure.

Then, we ask ourselves: how can we determine if our Epics are good enough?

Let’s try to do so again using AIAA.

For this example, I will use a very simple approach. I will use another AI tool (Google Gemini Advanced) to process a list of Epics that I wrote, which you can access here.

You can see that they are six Epics, which I wrote in a descending order of correctness. The first two are good, the next two are okay, the fifth one is bad, and the last one is messy. But in order to read them, of course, you will need context. Let’s explain the fundamental technique we’ll be applying today, specifically the Roleplaying point of view. To generate value, User Stories require contextualization; instruct the AI to adopt a viewpoint. In these examples, I’ve used the point of view of a Leasing Product Owner, working to generate products for individuals in a Chilean Bank. How can we make Gemini understand this?

Let’s try this: “First, imagine yourself as an Agile Coach working in a bank in Chile.”

This creates a scenario in which Gemini comments on what could be the major challenges. Ok, we can work with that.

Focus on what we want to do: “I have this list of epics. As an Agile Coach working in the Leasing Product Cell, what would you say about them? Are they all well written?”

This is what Gemini says:

“As an Agile Coach in the Leasing Product Cell, here’s my assessment of the provided epics:

Overall Impression: The list presents a mix of well-structured epics and some that need refinement to truly embody Agile principles. It’s evident that there’s a drive towards digital transformation and customer-centricity, which is positive. However, some epics lack the clarity and conciseness that facilitate effective Agile execution.

Specific Feedback on Each Epic:

Epic 1: Digital Leasing Application for Individuals: This is a well-structured epic. It has a clear business case, a concise description, and measurable success criteria. The inclusion of sizing, team composition, and risk mitigation demonstrates a good understanding of Agile planning.

Epic 2: Leasing Customer Loyalty Program: Another well-defined epic with a strong business case and clear objectives. The focus on customer retention and lifetime value aligns well with the bank’s strategic goals.

Epic 3: Quick Approval for Returning Customers: This epic, while capturing a valuable idea, lacks the structure of the first two. It’s presented more as a casual conversation than a formal epic. It needs a clearer business case, more specific success criteria, and a better definition of scope.

Epic 4: Leasing Mobile App: Similar to Epic 3, this one needs more structure. While the idea is sound, the ‘Why’ and ‘What it needs to do’ sections are quite broad. Defining specific features, target audience, and measurable outcomes would enhance its effectiveness as an epic.

Epic 5: Online Lease Calculator: This is a straightforward epic with a clear objective. However, it might be too small to be considered an epic on its own. It could potentially be incorporated as a feature within a larger epic related to enhancing the online leasing experience.

Epic 6: Leasing Chat: This is the least defined epic. It’s essentially a request to explore a solution rather than a well-articulated epic. It needs a clear problem statement, potential solutions, and measurable goals to guide its development.

Recommendations for Improvement:

Consistent Structure: Ensure all epics follow a consistent format, including a clear business case, description, scope, success criteria, and risk mitigation.

User-Centricity: Frame epics in terms of the value they deliver to customers. Use user stories and personas to capture user needs and expectations.

Measurable Outcomes: Define specific, measurable success criteria for each epic to track progress and demonstrate value.

Right-Sizing: Ensure epics are appropriately sized for Agile development. Break down large epics into smaller, more manageable user stories.

Collaboration: Involve cross-functional teams in epic creation and refinement to ensure diverse perspectives and buy-in.

Overall, while the list contains some promising ideas, refining the less structured epics will significantly improve the Leasing Product Cell’s ability to deliver value through Agile practices.”

Excellent, what do we have now? We have both an assessment of them and a way to improve them. We can try to get them to do a report.

“Create a report for the Epics using a maturity scale, where 5 is written very well and 1 is poor. Include also the main actions where do you think the stories beneath 4 in the scale could be improved”

This is what Gemini creates.

There you have it. An easy, hassle-free way to create a report on the overall health of your Epics.

Next time: sizing!

Gen AI and Agile: a concrete proposal – AIAA Jam 1

Or how will GenAI impact in the real world

GenAI, right?

At this point, you probably are tired of hearing it. Yes, it’s going to change the world. But you’d rather have more clarity on how it’s going to do it, right?

So, I’m going to do the opposite of what most consultants do. Instead of starting high, on strategy and vision, I’m going to start very small and concrete and try to explain how I think GenAI can impact positively your day to day.

The obligatory disclaimer: this is basically me future-telling. So take this with a grain of salt.

Shall we drill down?

Let’s think on how GenAi can impact Agile.

But do not stop there. I’ll try to think how to apply GenAI to a concrete problem and I’ll try to provide a concrete solution.

To do that, I’m going to do some fortune-telling. Break out the tarot cards and crystal balls!

My future-assumption

My general view is that Agile is going to change in just a couple of years, going from Agile 2.0 (Scaled Agile) to Agile 3.0, which I call AIAA: AI Augmented Agility.

I think that most teams will quickly migrate to Low code / No code (LcNc) team members, with a lot of the development process, be it tech or business, relying on AI tools. Promptcrafting will become the main skill needed, and you will have small, more mobile teams focusing on Jobs-to-be-Done rather than traditional Scrum roles. Special, dedicated teams of engineers will continue to exists for super-specialized situations, but most work will be done by changeable, mobile teams.

Ok, Fede, you might say. That sounds well and good, but it’s very abstract. Can you give me an example?

I’m going to focus on one problem that today exists, and try to improve it with GenAI.

The Problem

In most of the Enterprise Agility situations (think SAFe, LeSS, etc.) one of the major concern is dependencies. Since Scrum allows a flexible approach to Roadmapping, how does change in which User Story Team A does impacts in Team B? And does Team C suffers any impact?

This, in any major enterprise, becomes quickly a pain, especially once chapter, tribes and other major groupings start to pile up. Suddendly you have 37 teams, with criss-crossing interdependencies that make following the changes a chore. Yes, PI Plannings or Quarterly Plannings can help mitigate the impact, but these are very high-cost, once-a-quarter solutions. Once they are finished, you either rely on people communicating their whole backlog change and other people understanding the impact or you run the risk of impacting the other teams.

Often, this leads to meeting-itis and people investing a lot of hours in trying to understand different backlogs. How can we mitigate this with GenAI?

The Solution

Some general guidelines: I’m going to be as agnostic as possible regarding tools. You can do this with Jira, Rally, ServiceNow or any backlog tool and with most GenAI offerings. I’m going to use for this one plain good-old Excel and ClaudeAI, but feel free to swap them.

I’ve created an interlocking backlog, which you can see here:

User Stories with Dependencies.pdf

There are 8 User Stories (based on a Banking implementation) that have dependencies. I’ve also created the same document without the dependencies there, to mimic a Backlog that hasn’t been analyzed, that you can access here, with 3 teams:

User Stories.pdf

What would be our objective? To find a way to have a first analysis of dependencies that we, as members of Team A, can use to understand if Teams B or C have a dependency with us or vice-versa, and if we see any change on the stories that impact either us or them, have a meeting. That way, we could quickly mitigate the risk of a bottleneck, without the need to wait for a Quarterly Planning meeting or involving dozens of people.

So, let’s go to Claude’s page (https://claude.ai/) and upload the file (User Stories.pdf) with the following prompt:

I have an Excel of User Stories for Banking. I want you to read the User Story Number (column A), User Story (column B) and Acceptance criteria (column C) and then tell me which User Story has dependencies with each other, keeping in mind that stories might have more than a single dependency

As you can see, the AI quickly reads and identifies several dependencies. But this can also be difficult to follow up.

So, let’s refine a little bit our Promptcrafting. What should we focus on?

Using this information, which stories could be a high-impact bottleneck?

Ok, using this promp, the AI can rank the importance of the User Stories based on dependency and priority (which I agree).

So we have a list of stories that we have to monitor, but this is not really a comfortable way to do so. Can, perhaps, find another way to do it?

create a dashboard to follow up on these stories

Of course, this is a static dashboard. I wonder if we can implement it via Javascript into a dynamic page?

implement this dashboard in javascript

And there you have it. A dynamic Dashboard that takes the input from a spreadsheet and makes following it a trivial matter.

Bear in mind that I’m doing this in a bare-bones way. Any kind of tool beyond Excel (like Jira, or ServiceNow) will also include the ability to export the contents, but more importantly, the ability to connect via an API. This means that you can have a bot in any kind of embedded AI (like Microsoft’s Copilot) constantly trawling the different backlogs and alerting the teams about unmet dependencies.

Is this perfect? No, it will probably require some fine tunning, and you should always double-check the results (you can do so with my file User Stories with Dependencies.pdf to see which stories I thought have dependencies with each other).

Will this save you time and effort? Absolutely.

How much? Well, let’s do something. Let’s map total hours (i.e. hours per participant) in all the Scrum of Scrum or Sync meetings that your RTEs, ATFs, etc. go to. Let’s tally them up.

How much do you think that they will save if, instead of going through their backlog, they just meet to check the points that they already have? Shall we say, a conservative 60% savings of time?

Now, let’s go back to our organization of 37 teams. That, plus RTEs and Portfolio Managers means that if you have 2 hours of sync per sprint, will mean that you will average around 185 hours (2.5 people x 37 teams, which is 92.5 people per hour of sync, times two, which is 185 hours). This will mean that you will save 111 hours per sprint. If you’re using two weeks for your sprint, this is 222 hours per month. This is more than a FTE of a high salary.

And we’re being conservative here. Once this is fine-tuned, the cost of missing a particular dependency is probably less than the cost of running the meeting.

Does this make sense? Of course, this is just a very brief way in which you can implement AIAA, but I’ll be exploring how to Augment Agility in further articles.

Let me know what you think!

#agile #ai #genai #safe #scrum #less

FECHO’S FIELD GUIDE TO DIGITAL CONSULTANCY

Since I’ve been pumping out articles, one of the most common questions that I’ve been getting is: hey, what exactly is what a Digital Transformation consultant does?

This probably is too complex a question for me to answer, but I’m going to take a stab at it, anyway.

The thing is, I’ve been a consultant most of my professional adult life.

I don’t mean to brag about it. It just means that I’m old, to be honest. But in the 27 years (to date) that I’ve been working in corporations, I’ve alternated being a lead of different things such as Architecture , Agile Transformations, Industrial Transformation, etc. i.e. gaining experience in an Area and then doing Consultancy on it.

So, from all the job roles that I’ve done, “Consultant” is the more constant label.

I’m still learning; I’ve had some incredible mentors (which are key to learn something on the job) and I’m lucky to be working right now with some of the best consultants that I know.

So, bearing in mind all these caveats, this is:

FECHO’S FIELD GUIDE TO DIGITAL CONSULTANCY

Table of Contents:

  1. Introduction
  2. Understanding Digital Transformations
  3. Management Consultancy: A Key Player in the Process
  4. Enterprise Agility: Accelerating the Transformation
  5. The Role of the Consultant in Digital Transformations
  6. Key Responsibilities and Deliverables
  7. Essential Skills for Success
  8. Conclusion
  9. Introduction

As the world continues to embrace digitalization, organizations need to adapt their business models to remain competitive and innovative. This adaptation requires a comprehensive understanding of digital transformations, incorporating both management consultancy and enterprise agility. Fecho’s Field Guide aims to provide a detailed overview of the work involved in digital transformations consultancy with a focus on management consultancy and enterprise agility.

  1. Understanding Digital Transformations

Digital transformations involve the integration of digital technologies into all aspects of a business, changing the way it operates and delivers value to its customers. It requires organizations to rethink their entire business model and processes, enabling them to become more agile, innovative, and customer-centric.

Key components of a digital transformation include:

  • Business Model Innovation
  • Customer Experience Enhancement
  • Operational Efficiency Improvement
  • Workforce Empowerment
  • Digitization of Products and Services
  • Data-Driven Decision-Making
  1. Management Consultancy: A Key Player in the Process

Management consultants play a crucial role in driving digital transformations by providing expert guidance and support throughout the process. They help organizations to:

  • Assess their current digital maturity and identify gaps
  • Develop a comprehensive digital transformation strategy
  • Implement the transformation plan, including change management initiatives
  • Monitor and measure the impact of the transformation efforts
  • Continuously refine the transformation strategy to ensure long-term success
  1. Enterprise Agility: Accelerating the Transformation

Enterprise Agility is the ability of an organization to adapt quickly to changes in the market and maintain a competitive advantage. It is a crucial component of successful digital transformations, as it enables organizations to respond effectively to evolving customer needs, emerging technologies, and new business models. Enterprise agility involves:

  • Adopting Agile methodologies and practices
  • Implementing Lean principles to streamline operations
  • Developing a culture of continuous improvement and learning
  • Fostering cross-functional collaboration and communication
  • Leveraging data and analytics for informed decision-making
  1. The Role of the Consultant in Digital Transformations

As a consultant in digital transformations, your work (and mine) entails providing expert guidance and support to clients throughout their digital journey. This involves:

  • Analyzing the client’s current state and digital maturity
  • Identifying opportunities for improvement and growth
  • Developing a tailored digital transformation strategy
  • Facilitating the implementation of the transformation plan
  • Ensuring the alignment of the organization’s strategy, culture, and processes
  • Monitoring and measuring the impact of the transformation efforts
  • Providing ongoing support and guidance to ensure long-term success
  1. Key Responsibilities and Deliverables

As a digital transformation consultant, your key responsibilities and deliverables include:

  • Conducting digital maturity assessments
  • Developing comprehensive digital transformation roadmaps
  • Assisting with implementing digital technologies and solutions
  • Facilitating change management initiatives
  • Providing training and coaching on Agile methodologies and Lean principles
  • Ensuring alignment between business strategy, technology, and operations
  • Measuring and reporting on the impact of digital transformation efforts
  • Identifying and mitigating risks associated with the transformation process
  1. Essential Skills for Success

To be successful in your role as a digital transformation consultant, you need to possess a combination of technical and interpersonal skills, including:

  • Strong analytical and problem-solving abilities
  • Deep understanding of digital technologies and trends
  • Familiarity with Agile methodologies and Lean principles
  • Excellent project management and organizational skills
  • Effective communication and presentation abilities
  • Strong interpersonal and relationship-building skills
  • Ability to adapt to and manage change effectively
  • Sound understanding of various industries and business models
  • Experience in implementing and managing digital initiatives
  1. Conclusion

In conclusion, as a consultant in digital transformations with a focus on management consultancy and enterprise agility, your work entails guiding organizations through their digital journey by providing expert insights, developing tailored strategies, and facilitating the implementation of digital initiatives. You play a crucial role in helping businesses adapt to the rapidly changing digital landscape, ensuring they maintain a competitive edge while embracing innovation and customer-centricity.

By leveraging your skills and expertise in digital technologies, Agile methodologies, and Lean principles, you support organizations in achieving their digital transformation goals, ensuring they remain relevant and successful in today’s increasingly digital world.

I hope this makes sense to you!

Embracing LeSS: A Comprehensive Guide to Large Scale Scrum

Do LeSS!

Introduction

So, we’ve discussed SAFe enough, yes? Probably more than what you wanted, to be honest. I love SAFe, I do, but sometimes it seems it is the only Enterprise Agility framework that exists. But that’s not the case. There’s LeSS, for example.

LeSS, or Large Scale Scrum, is an agile framework specifically designed to streamline the process of scaling Scrum across multiple teams working on a single product. As organizations grow and undertake more complex projects, it becomes increasingly important to ensure that teams collaborate effectively and deliver high-quality products within budget and time constraints. LeSS provides the necessary tools and techniques to achieve these goals by emphasizing lean thinking, systems thinking, and empiricism.

Where does it comes from?

LeSS was created by Craig Larman and Bas Vodde, two experienced Scrum practitioners who sought to address the challenges of scaling Scrum without compromising its core principles. Drawing on their extensive experience coaching organizations in agile practices, Larman and Vodde developed the LeSS framework as a response to the growing need for a scalable Scrum solution that maintains the simplicity and agility of the original methodology. Their main philosophy could be seen as Keep it Simple as much as Possible, but no more. Compare and Contrast to SAFe Wall of Acronyms.

Key Principles of LeSS

Leverage Scrum’s Simplicity

LeSS retains the simplicity of Scrum by focusing on the essential elements that make Scrum an effective framework for product development. It avoids adding unnecessary complexity or bureaucracy, emphasizing that the same Scrum principles and practices apply to teams of all sizes.

Systems Thinking

LeSS emphasizes the importance of systems thinking in understanding how teams, products, and organizations interact. By considering the entire system, rather than individual components or teams in isolation, LeSS helps organizations identify areas for improvement and potential bottlenecks, ensuring smoother collaboration and more effective decision-making.

Empirical Process Control

Empiricism, or learning through experience, is at the core of LeSS. The framework encourages organizations to experiment, inspect, and adapt their processes, enabling them to continuously improve and respond to change effectively. LeSS also emphasizes the importance of transparency, inspection, and adaptation as the three pillars that support empirical process control.

Lean Thinking

LeSS incorporates the principles of lean thinking, which focus on maximizing customer value while minimizing waste. By identifying and eliminating non-value-adding activities, organizations using LeSS can increase their efficiency, reduce costs, and deliver better-quality products faster. Still, it incorporates principles rather than full-on practices like SAFe.

Key Practices of LeSS

One Product, Multiple Teams

LeSS emphasizes that all teams working on a product should be part of a single, unified effort. This approach ensures that teams share a common goal and that their work is coordinated and integrated, reducing the risk of duplicated efforts or misaligned priorities.

Feature Teams

LeSS promotes the use of feature teams, which are cross-functional teams capable of delivering end-to-end product features. This structure encourages collaboration, reduces handoffs, and allows teams to work more autonomously, increasing their ability to adapt to changing requirements.

Coordinated Sprint Planning

In LeSS, multiple teams participate in coordinated sprint planning, aligning their efforts and synchronizing their work. This practice ensures that teams are working towards a common goal and that dependencies are identified and managed effectively.

Shared Product Backlog

A single, shared product backlog is used across all teams working on a product in LeSS. This approach simplifies backlog management, ensures that all teams have a clear understanding of the product’s priorities, and promotes collaboration and coordination.

Ok, Fede, that’s all well and good. But how does it compares with SAFe?

And when should you choose one over the other?

LeSS and SAFe (Scaled Agile Framework) are both popular frameworks designed to help organizations scale their agile practices across multiple teams. While they share some similarities, such as their emphasis on lean and agile principles, they also differ in several key aspects. The following comparison will help illuminate the differences and similarities between these two approaches.

Philosophy and Complexity

LeSS is grounded in the simplicity of Scrum and focuses on retaining its straightforwardness while scaling. It emphasizes minimalism and aims to avoid adding unnecessary complexity, bureaucracy, or layers of management. LeSS strives to maintain the agility and adaptability of Scrum, even as the organization grows.

SAFe, on the other hand, is a more prescriptive and comprehensive framework. It provides a detailed blueprint for scaling agile practices and offers a wide range of roles, artifacts, and processes. While SAFe also seeks to maintain agility, its structure and complexity make it more suitable for larger enterprises with multiple layers of management and a higher degree of organizational complexity.

Implementation

LeSS is easier to implement in organizations that are already using Scrum or are familiar with agile principles. Its lightweight nature and focus on the core concepts of Scrum make it a suitable option for those who want to scale their existing agile practices without introducing a significant amount of new processes or roles.

In contrast, SAFe requires more substantial organizational changes and a higher level of commitment from the entire organization. Implementing SAFe often necessitates restructuring teams, roles, and processes to align with the framework’s structure and principles. This may involve a steeper learning curve, but it can provide more guidance and support for organizations seeking a comprehensive approach to scaling agile practices.

Hierarchy and Decentralization

LeSS promotes decentralization, self-organization, and autonomy within teams. It aims to reduce dependencies and handoffs between teams, encouraging cross-functional feature teams that can work independently to deliver end-to-end product features.

SAFe, while still encouraging autonomy and self-organization, incorporates a more hierarchical structure, with specific roles and responsibilities defined for different levels of the organization. This structure is designed to coordinate efforts across teams, programs, and portfolios, but it may also result in a more top-down approach to decision-making and planning compared to LeSS.

Continuous Improvement

Both LeSS and SAFe emphasize the importance of continuous improvement and learning through regular inspection and adaptation. However, LeSS places a stronger focus on empirical process control and systems thinking, encouraging organizations to experiment, learn, and adapt their processes based on real-world experience.

SAFe also values continuous improvement but places more emphasis on its structured and prescriptive framework for implementing agile practices. This structure can provide more guidance for organizations, but it may also limit experimentation and innovation to some extent.

So you go for LeSS when you have LeSS of an Enterprise structure and more of an Agile Mindset in place. Fintechs, Startups, etc. are great LeSS candidates. But for hierarchical institutions like Banks or Utilities companies, SAFe is often a safer bet. #sorrynotsorry

Conclusion

LeSS provides a powerful and effective solution for organizations looking to scale their Scrum practices while maintaining the agility, simplicity, and effectiveness of the original framework. By focusing on lean thinking, systems thinking, and empiricism, LeSS helps organizations to overcome the challenges of scaling, enabling them to deliver high-quality products more efficiently and effectively.

How to keep good sync: Two-speed IT and the CM

Last week’s article on Two-speed IT brought a lot of interest. But also one repeated question. Ok, you have an hybrid model between Agile and Core ways of working. How do you keep both in sync?

Well, by having a sync-layer and a new role: the Communication Manager.

In Two-Speed IT, a communication manager is a role responsible for developing and implementing communication plans to ensure effective communication between the core IT team and the agile IT team. The communication manager works to establish communication channels and protocols and ensures that all team members are aware of the communication plan and understand their roles and responsibilities. He or she is the main role of the Sync layer.

The communication manager plays a critical role in ensuring that communication is clear and effective between the core and agile IT teams. They are responsible for establishing communication channels, such as email, instant messaging, or video conferencing, and ensuring that all team members are aware of these channels and how to use them. The communication manager also establishes protocols for communication, such as frequency and format, and ensures that all team members understand these protocols and follow them.

CMs are also responsible for monitoring communication channels to ensure that they are working effectively and that team members are communicating with each other in a timely and efficient manner. They also provide feedback to team members to ensure that communication is effective and efficient, and to identify areas for improvement.

The communication manager is typically a highly skilled professional with experience in communication, project management, and IT. They have excellent communication skills, both written and verbal, and are able to communicate effectively with a variety of stakeholders, including business leaders, IT professionals, and end-users.

Overall, the communication manager plays a critical role in ensuring that communication is clear and effective between the core and agile IT teams in Two-Speed IT. By establishing clear communication channels and protocols, and monitoring communication channels to ensure that they are working effectively, the communication manager helps to ensure that the benefits of the Two-Speed IT approach are realized.

The CM populates a layer with a mixture of Agile roles (Scrum Master, PO, etc.) and traditional roles (PM, PMO, etc.) which is used for synchronicity. By enabling a series of intersecting communications between GANTTs, Epics and holding Quarterly Planning meetings, the CMs in an organization keep the work on path.

But which are the other roles of Two-speed it?


The Agile IT Team: The agile IT team is responsible for developing and implementing new systems and technologies that are more flexible and adaptable to change. To achieve this, they need to work collaboratively with business units and stakeholders to understand their needs and requirements. The agile IT team is responsible for communicating the status of their projects, sharing updates on their progress, and collaborating with the core IT team to ensure that the new systems are integrated with the existing core systems. The main Agile roles are Scrum Master, Product Owner, Team Member and Kanban Coach.

The Core IT Team: The core IT team is responsible for maintaining the stability and reliability of the organization’s foundational IT systems. They need to communicate with business units and end-users to understand their needs and requirements, and provide support to resolve any issues or problems that arise. The core IT team is responsible for communicating the status of their projects, sharing updates on their progress, and collaborating with the agile IT team to ensure that the new systems are integrated with the existing core systems. The main roles are Business Analyst, Programmer, Tester, Project Manager.

Together with the CMs, and roles that vary depending on which flavor of methodology you are using (i.e. Agile Coaches, PMOs, etc.) but which can be slotted into one of the three layers:

  1. Agile IT
  2. Core IT
  3. Sync layer

I hope this helps to clarify this aspect of Two-speed IT!