Explore todas las publicaciones en esta categoría
Son las 9:30. El equipo está reunido. Cada persona responde por turno a las tres preguntas: 'Qué hice ayer, qué hago hoy, cuáles son mis bloqueos.' Quince minutos después, todos regresan a sus pantallas sin que nada haya cambiado. Este daily no sirvió para nada.
Existe en la industria tecnológica un arquetipo admirado: el desarrollador brillante y solitario que produce más código que diez desarrolladores ordinarios. Este arquetipo influye en las contrataciones, justifica paquetes salariales desiguales y crea culturas de equipo disfuncionales. También es, en gran medida, un mito.
La base de datos de producción cayó el viernes a las 18h. El post-mortem tuvo lugar el lunes. En el informe: cinco puntos de mejora de procesos, tres acciones de remediación técnica y una mención discreta de que 'el incidente fue causado por un error humano durante la migración.' Esa frase es lo contrario de un post-mortem blameless.
¿Cuántos días pasa un nuevo desarrollador intentando poner en marcha el proyecto en local antes de poder contribuir realmente? En la mayoría de los equipos, la respuesta está entre dos y diez días. La documentación de onboarding existe, solo que es incorrecta.
¿Cuántas veces has tenido un 1-on-1 donde tu manager abrió Jira para revisar tus tickets en curso? Esa reunión podría haber sido un correo o una consulta al tablero Kanban. Un 1-on-1 que parece un reporte de estado es un 1-on-1 desperdiciado.
Tu equipo tiene una página de Notion con el plan del próximo trimestre. Fue redactada la semana pasada. Tres personas añadieron comentarios. Dos pusieron un emoji. El plan no ha cambiado. Nadie ha tomado una decisión. Eso es el async sin control: mucha actividad, poca resolución.
"Nuestra velocity es de 42 puntos por sprint." Esta frase se pronuncia con orgullo en cientos de reuniones de planificación cada semana. ¿Qué dice exactamente? Que el equipo cierra tickets a un ritmo constante. Lo que no dice: si esos tickets crean valor, si las estimaciones son realistas, si el equipo está bien.
"Como usuario, quiero poder iniciar sesión para poder acceder a mi cuenta." Este ticket se ha escrito millones de veces. No describe nada útil sobre lo que el desarrollador debe hacer. Ese es el problema central de la user story como unidad de trabajo.
