Cuando dejé de permanecer en mi carril
El punto de inflexión fue una noche en la que activé el "modo fiesta" de BMAD.
El modo fiesta reúne a un elenco de agentes: gestor de producto, analista, arquitecto, desarrollador, probador, Scrum Master, y los suelta en un chat compartido. Escribí un concepto descabellado para una aplicación de coaching sobre las posturas de Scrum, pulsé enter y vi cómo estallaba la sala.
En cuestión de minutos, los agentes estaban haciendo preguntas más agudas que en la mayoría de las reuniones reales:
"¿Quién es el real Scrum Masters dentro de las organizaciones".
"¿Quién paga si la gestión es parte del problema?"
"¿Es esta una herramienta de junta, o una herramienta de desarrollo de posturas?"
"¿Es esto realmente SaaS empresarial, o una herramienta comunitaria de código abierto disfrazada?"
Entré "sólo" probando un marco de IA. Me fui dándome cuenta de que el sistema había reflejado mi propia confusión y me había ayudado a limpiarla. No se trataba de convertirse en un ingeniero 10x. Se trataba de convertirse en un más honesto, más útil persona producto por entrar en la construcción, no sólo facilitando a su alrededor.
¿Por qué "Business-se está convirtiendo en un lastre
Durante la mayor parte de mi carrera, permanecer en el lado de los negocios me hacía sentir responsable. Mi trabajo consistía en orientar, aclarar, priorizar y traducir. Cuando las cosas se ponían "demasiado técnicas", pasaba el testigo a un desarrollador o arquitecto y confiaba en que ellos rellenaran los huecos.
Eso tenía sentido cuando el cuello de botella era la construcción. Los humanos escribían todo el código. La documentación era cara. Pedir "un experimento más" suponía semanas de esfuerzo.
La IA robótica rompió esa ecuación. Ahora:
Un pequeño enjambre de agentes puede redactar un documento de arquitectura en minutos.
Un agente de desarrollo puede crear una aplicación web completa mientras usted se llena el vaso de café.
Un agente analista puede desmontar tu PRD y reconstruirlo con restricciones más estrictas y mejores puntos de referencia.
Lo lento ya no es teclear. Lo lento es pensar:
¿Estamos resolviendo un problema real o un problema de vanidad?
¿Nuestras restricciones son reales o sólo hábitos?
¿Cuál es el coste económico de "una dependencia más" o "un modelo más"?
Si te quedas puramente en el lado de los negocios, haces grandes llamadas sobre el alcance, el riesgo y el valor sin sentir esas decisiones en el código, la arquitectura o el gasto. Eso no es más seguro, es simplemente estar ciego. Yo ya no quería estar ciego.
BMAD: Ruedas de entrenamiento para no-Developers
BMAD envuelve su trabajo en una forma de equipo familiar:
Persona del gestor de productos para cuestionar la visión y el alcance.
Personaje analista para PRDs y briefs.
Personaje arquitecto para las pilas y las restricciones.
Desarrollador persona para la aplicación y refactorizaciones.
Personaje probador para los criterios de aceptación y la cobertura.
Personaje Scrum Master para insistir en el "dev-ready" frente a las ilusiones.
Hablas con ellos en un lenguaje sencillo. Ellos responden con artefactos: documentos markdown, historias, pruebas, código, flujos de trabajo. Para alguien como yo, eso hace dos cosas:
Reduce la barrera de entrada. No tengo que conocer la sintaxis de cada herramienta. Puedo decir: "Ayúdame a diseñar una aplicación de facilitación Cynefin que borre los datos después de 72 horas", y los agentes se encargan del andamiaje mientras yo dirijo.
Eleva el listón de mi pensamiento. Los requisitos débiles, los usuarios confusos y el pensamiento mágico del MVP quedan al descubierto rápidamente. Los agentes siguen preguntando: "¿Para quién es esto? ¿Qué significa "hecho"? ¿Qué significa esa elección para la arquitectura y las pruebas?".
BMAD no me convirtió en un ingeniero full-stack. Convirtió mis instintos de producto en algo comprobable, e hizo que la parte de construcción se sintiera menos como una caja negra.
Manos-Momento sucio #1: Una aplicación Cynefin en una tarde
Como facilitador, me encanta el marco Cynefin. Explicarlo en diapositivas se sentía plano. Quería una pequeña aplicación web para utilizar en los talleres: capturar ejemplos, clasificarlos en dominios y luego hacer borrón y cuenta nueva.
Pre-AI, esa idea habría vivido en un tablero de "algún día". Con BMAD, yo:
Abrí un repo limpio e instalé el framework.
Le dije a los agentes lo que quería: una simple aplicación React, respaldada por una base de datos que auto-elimina los datos después de ~ 72 horas.
Dejé que las personas de desarrollo y arquitectura propusieran una pila y conectaran los elementos básicos.
En una sola tarde, tenía:
Un front-end funcional.
Un backend en la nube con las tablas y la retención adecuadas.
Una aplicación ligera pero real que podía montar, utilizar con un equipo y desmontar.
Todavía tenía que revisar el código, retocar la copia y ajustar los detalles de UX. Tuve que aprender lo suficiente para corregir el comportamiento de la información sobre herramientas y mover el texto donde realmente ayudara a la conversación.
Pero, mi dolor de facilitación se convirtió en un producto realno sólo una historia de usuario. Una vez que has visto un prototipo desechable convertirse en una aplicación utilizable en un día, es más difícil pedir a un equipo de tres sprints en algo que nunca ha tratado de ponerse de pie a ti mismo.
Manos a la obra-Momento sucio # 2: Ser llamado por mi propio PRD
En otro experimento, se me cayó BMAD en un repo de investigación brownfield: un proyecto multimodal neural-net. Yo ya tenía un PRD. Se sentía sólido. Entonces le pregunté a la persona analista para revisarlo. La respuesta me dolió, en el buen sentido:
Enunciados del problema más claros, menos palabras de moda.
Objetivos explícitos de hardware y formación: "En esta clase de GPU, el objetivo es este número de horas, este número de parámetros, este tipo de rendimiento".
Un panorama competitivo que no había definido del todo.
Un desafío a una dependencia externa "agradable de tener" que realmente pertenecía a una fase posterior.
No necesitaba convertirme en un experto en CUDA. Tenía que aceptar que mi PRD original estaba más cerca de un memorándum de visión que de un documento de ingeniería. Desde entonces:
Hago preguntas más agudas cuando alguien propone "sólo una biblioteca más" o "un modelo más".
Hablo de limitaciones en términos concretos: tiempo, memoria, rendimiento, precisión, no sólo "más rápido" y "mejor".
Respeto el coste del "trabajo de investigación" de una forma que no lo hacía antes de haberlo visto cableado hasta el final.
Se puede hacer una versión reducida de esto en cualquier producto:
Coge un PRD del que estés orgulloso.
Pídele a un analista que lo desmonte y lo reconstruya.
Devuelve esos bordes más afilados al refinamiento y la planificación.
Manos a la obra-Momento sucio #3: Convertir Scrum-Scrum en un producto
El experimento más personal fue la aplicación Scrum-stances. Como Scrum Master y coach, he tenido cambios incómodos entre posturas. Pasar de entrenador a maestro, o de facilitador a agente de cambio, no siempre es elegante. No siempre perjudica al equipo, pero sabes cuando cae mal.
Un día, dejé esa torpeza y me puse en modo fiesta: "Tengo una idea alocada para una aplicación de Scrum que ayude a los Scrum Masters a practicar posturas, no sólo a mover tarjetas. Usemos scrum.org como fuente canónica y construyamos lo que me hubiera gustado tener al pasar de PM a Scrum Master". Los agentes:
Enmarcado un planteamiento del problema en torno a la brecha entre la certificación y la práctica vivida.
Señaló cómo el acceso a los mentores está realmente basado en la suerte.
Desafió mi lenguaje de "primero en mover" y lo replanteó como "primero en operacionalizar el desarrollo de posturas".
Martillado privacidad y la seguridad psicológica: reflexiones sólo ayudan si Scrum Masters se sienten seguros escribiéndolos.
Luego se centró en algo que había estado bailando alrededor:
Esto quiere ser de código abierto, impulsado por la comunidad, y adoptado individualmente.
Los Scrum Masters deben ser capaces de inscribirse sin el apoyo de la dirección.
El crowdfunding y el patrocinio encajan mejor con mis valores que la búsqueda de ingresos por licencias.
En otras palabras, convirtieron mi historia de origen en una estrategia de producto. No me fui con una aplicación terminada. Me fui con:
Un resumen más nítido.
Una pila que invita a las contribuciones en lugar de asustarlos.
Una forma más honesta de explicar mi "por qué" a otros Scrum Masters.
Mi torpeza vivida dejó de ser una historia de guerra y se convirtió en una aportación de primera clase al producto.
Cómo esto cambió mi trabajo diario
Sigo siendo un Scrum Master / Product Owner / BA / PM, pero ahora soy diferente porque he pasado tiempo en el lado de la construcción con los agentes:
En el refinamientoNo acepto historias difusas o criterios de aceptación. No porque lo diga un libro, sino porque he visto a los agentes agitarse con entradas vagas e inventar soluciones que yo no pretendía.
En la planificaciónhablo concretamente de compensaciones. Me pregunto: "¿Qué aporta esta elección de herramienta a nuestra IC? ¿A los demás colaboradores? No estoy haciendo más arquitectura que nadie; estoy intentando comprender el riesgo y el coste que les estoy pidiendo que acepten.
En coachingno me limito a decir a los equipos que "se acerquen más a la compilación". Puedo decir, "Vamos a sentarnos con un desarrollador agentic durante una tarde y hacer una pequeña cosa juntos. Verás lo que las historias limpias y las restricciones hacen a la velocidad".
Sobre todo, tengo más empatía. Cuando los desarrolladores se oponen al alcance, he sentido esa tensión en mis propios experimentos. Cuando el departamento de control de calidad pide mejores criterios de aceptación, he visto la diferencia en las pruebas automatizadas. Cuando los arquitectos preguntan "sólo una integración más", puedo imaginarme el árbol de dependencias, no sólo la hoja de ruta.
Sigo siendo la persona del lado empresarial que bromea sobre "hacer de desarrollador en la tele". Pero ese acto tiene consecuencias reales: me convierte en un mejor socio para las personas que viven en el código cada día.
Cómo empezar: Un pequeño libro de jugadas para las empresas-Side Folks
Si eres un Scrum Master, Product Owner, BA, PM, o cualquier miembro del equipo centrado en el negocio, aquí tienes una forma pequeña y concreta de empezar.
1. 1. Elige un problema que te que*
Que sea pequeño y egoísta:
Una herramienta de facilitación (como la aplicación Cynefin).
Un micro-cuadro de mando que desearías que existiera.
Un pequeño compañero para un taller o formación que ya diriges.
2. 2. Comprométete a construir durante un fin de semana
Establece un marco de trabajo agéntico (BMAD o algo similar).
No persigas la "pila perfecta". Deja que los arquitectos/personas de desarrollo propongan una predeterminada.
Tu objetivo no es "listo para producción". Es "algo en lo que pueda hacer clic y de lo que pueda aprender".
3. 3. Apóyate en las conversaciones, no en el código
Pide al analista un brief o PRD.
Pide a la persona PM que cuestione a tus usuarios y tu propuesta de valor.
Pregúntale al arquitecto qué compensaciones implican tus elecciones.
Deja que el agente de desarrollo haga el andamiaje, luego lee y cuestiona el resultado.
4. 4. Devuelve un artefacto a tu equipo
Preséntate el lunes con:
Una pequeña cosa en marcha, o
Un PRD/brief más nítido, o
Una visión más clara de las limitaciones y los costes.
Luego di: "He intentado construir este fin de semana. Esto es lo que he aprendido sobre cómo escribimos historias / hablamos de restricciones / razonamos sobre costes". No hace falta que te conviertas en desarrollador, pero sí que tocar la construcción. Porque al fin y al cabo:
Somos personas resolviendo problemas para personas.
Somos personas que hacen negocios con personas.
Somos personas que utilizamos IA generativa para crear productos para las personas.
La confianza lo cambia todo.
Una de las formas más rápidas que he encontrado para ganarme esa confianza es pasar un poco de mi propio tiempo en el mundo del equipo: manos en el teclado, agentes a mi lado, aprendiendo construyendo.
¿Listo para tender un puente entre el negocio y la construcción? Póngase en contacto con Improving para ver cómo la IA agéntica puede acelerar sus equipos de producto.
