Sabes que después de trabajar en varios productos y construir cosas durante un tiempo, siempre he estado pensando en esta cosa de sprint que todo el mundo está haciendo. Como cualquier empresa, cada equipo sólo sigue este ciclo de sprint de dos semanas porque eso es lo que está haciendo todo el mundo, y simplemente me hace pensar mucho como lo que realmente obtienen de hacer cosas como esta. Porque honestamente la mayor parte del tiempo estos sprints no tienen realmente ningún impacto en su productividad real o su calidad de producto, es sólo una forma de organizar el trabajo que alguien decidió es el "modo correcto" y todo el mundo simplemente lo sigue. Usted tiene la planificación del sprint, usted tiene los standups diarios, usted tiene retrospectivas, usted tiene todas estas ceremonias que toman su tiempo cuando realmente podría estar construyendo algo. y no estoy diciendo que las reuniones son malas, pero la mayoría del tiempo estos rituales de sprint no tienen ningún peso, es como si la gente tuviera que hacerlo porque ese es el proceso, no porque realmente les ayude a enviar mejores productos. Así que descubrí algunas maneras de diseñar ciclos de ejecución cortos sin todo este sprint, y ha estado funcionando muy bien para mí: Work in Natural Cycles Based on Actual Tasks El mayor problema con los sprints es que te obligan a entrar en este ciclo artificial de dos semanas independientemente de lo que realmente estés construyendo. como si una función tarda 3 días en construir, ¿por qué lo planeas en un sprint de dos semanas? y si algo tarda 3 semanas, lo estás dividiendo artificialmente sólo para encajar en el sprint. Lo que hago en cambio es que divido el trabajo en ciclos naturales basados en la tarea real. Algunas tareas tardan 2-3 días, algunas tardan una semana, algunas tardan más tiempo. Y sólo trabajo en ellos hasta que estén terminados, los envío y paso a lo siguiente. No hay un plazo artificial que no tenga ninguna conexión con el trabajo real. Esta es la parte más importante porque te permite centrarte en la calidad de envío en lugar de encajar las cosas en cajas de tiempo arbitrarias. Ship Continuously Instead of Batch Releases Sprints te hacen batir todo en estos ciclos de lanzamiento. Terminas 10 características en dos semanas y las lanzas todas a la vez. Pero esto no tiene sentido para la mayoría de los productos, especialmente para los productos SaaS en los que puedes desplegar en cualquier momento. Envío funciones tan pronto como estén listas.Si algo se hace el martes, lo empujé el martes.Si otra cosa está lista el viernes, eso se acaba el viernes.De esta manera los usuarios obtienen valor más rápido, y puedes obtener un feedback más rápido.Y el feedback es la parte más importante porque así sabes si has construido la cosa correcta o no. Focus on One Thing at a Time En los sprints, los equipos planean como 5-10 cosas diferentes para trabajar en el mismo tiempo.Y luego todo el mundo salta entre tareas, el contexto cambia todo el tiempo, y nada realmente se hace correctamente. Lo que funciona mejor es simplemente centrarse en una cosa principal a la vez. Elija la característica o problema más importante, trabaje en ella, termine, envíe, y luego pasa a la siguiente cosa. Esto no significa que no pueda tener pequeñas tareas al lado, pero su foco principal debe ser una cosa. Use Deadlines Only When They Actually Matter Las Sprints crean estos plazos artificiales cada dos semanas. Pero la mayoría de las características no necesitan realmente un plazo específico. Como si estás construyendo una nueva función de dashboard, ¿no importa si se entrega el lunes o el miércoles? En lugar de imponer plazos a todo, solo los uso cuando realmente hay una razón. Como si estás lanzando algo para una conferencia, o prometiste a un cliente una fecha específica, o hay una razón competitiva para enviar por un tiempo determinado. Estos son plazos reales que realmente importan. Keep Communication Lightweight El mayor overhead de los sprints es todas las reuniones. Planificación de reuniones, standups diarios, revisiones, retrospectivas. Todo esto agrega hasta horas cada semana donde no está realmente construyendo nada. Lo que hago es mantener la comunicación realmente ligera. Si estoy trabajando solo, sólo tengo notas para mí mismo sobre lo que estoy trabajando y qué es lo siguiente. Si estoy trabajando con un equipo, solo check-in cuando es necesario, no en un horario fijo. Alguien tiene una pregunta? Ellos preguntan. Alguien terminó algo? Ellos lo comparten. Alguien está bloqueado? Ellos hablan. No requiere una reunión diaria a las 10 de la mañana todos los días donde todo el mundo dice lo que están trabajando en cuando usted ya sabe lo que todo el mundo está trabajando en. Plan Only What You Need to Plan La planificación del sprint te hace planificar dos semanas de trabajo de antemano.Pero la cosa es que no sabes realmente lo que va a venir en esas dos semanas.Puede que aparezca un bug, tal vez el feedback del usuario cambie tus prioridades, tal vez te das cuenta de que algo es más importante que lo que planeabas. Tal vez planeo 2-3 cosas por delante, así que siempre sé lo que viene, pero no planeo el mes entero o el trimestre entero en detalle. Esto me permite permanecer flexible y responder a lo que realmente importa en lugar de estar encerrado en un plan que se hizo hace semanas cuando tenías menos información. Measure by Outcomes, Not by Process Los sprints te hacen medir cosas como la velocidad, los puntos de la historia, los gráficos de quemaduras, pero estos son sólo métricas de proceso. Lo que realmente importa son los resultados. ¿Has enviado algo? ¿los usuarios lo usan? ¿ha resuelto el problema que estabas tratando de resolver? ¿ha ganado dinero si ese es el objetivo? Estas son las métricas reales que te dicen si tienes éxito o no. El proceso no importa si el resultado es bueno, y el proceso no ayuda si el resultado es malo. Lo principal que he aprendido es que no necesitas sprints para enviar buenos productos. sólo necesitas un enfoque claro, giros de retroalimentación rápidos y la disciplina para terminar las cosas antes de pasar a la siguiente cosa. Y esto no significa que la estructura sea mala.Todavía tienes que planificar, todavía tienes que comunicarte, todavía tienes que priorizar.Pero puedes hacer todo esto sin forzarte a estos rígidos ciclos de dos semanas que no tienen realmente sentido para cómo funciona el desarrollo real del producto.Sólo construye, envíe, aprenda, repita.Este es el ciclo que realmente importa.
