¿Cuál es la mejor manera de convencer a un fundador de que ágil no es la mejor manera de hacer todo para una startup efectiva?

¿Explicaría por qué cree que ágil no es la mejor manera en su caso?

Agile es una herramienta que puede ser efectiva en un caso y menos efectiva en otro. Enumere las razones por las que cree que no es efectivo para su situación.
¿Sería la falta de planificación presupuestaria o planificación a largo plazo, lo que es mortal para esta startup específica? No creo que ágil sea tan estricto que el propietario no pueda hacer una planificación de alto nivel.

¿O son los gastos generales de comunicación / reuniones lo que le preocupa? nadie prohíbe controlar el número de reuniones. Por otro lado, la comunicación frecuente en un equipo fuerte puede ser fundamental para el éxito de la startup.

¿Quizás es el método de describir los requisitos funcionales como historias? Pero muchas personas que conozco lo encuentran realmente adecuado para todo tipo de proyectos, incluso aquellos realizados con enfoque en cascada.

Así que da tus razones. Le ayudará a comprender su situación y a encontrar los argumentos.

¡Tienes que convertirte en un vendedor astuto que puede vender de manera convincente algo que no está bien!

Aunque no insisto en que es la mejor manera para cada cosa que sucede en el planeta, Agile tiene todo lo que mejor se adapta a un entorno de inicio para entregar de manera efectiva. Lo que no encaja es la ignorancia, la falta de voluntad y / o la falta de conocimiento.

La mayoría de las veces he visto obstáculos organizativos desde arriba, sin embargo, en su caso, parece que tiene suerte de que su fundador ya esté pensando en Agile. A menos que se encuentre en un escenario poco común, compartir sus obstáculos puede brindarle la ayuda adecuada para resolverlo.

El argumento que haría es que:

1. No hay una opción binaria y mutuamente excluyente entre Agile y Waterfall ”como mucha gente parece pensar. Es muy posible combinar los principios y prácticas de ambos enfoques en las proporciones adecuadas para adaptarse a cualquier situación.
2. Debe ajustar la metodología a la naturaleza del problema en lugar de ajustar a la fuerza un problema a una metodología particular (sea lo que sea, ágil o no).

Existe mucha polarización sobre “Ágil” versus “Cascada” y es necesario desactivar algunos de los mitos, estereotipos y conceptos erróneos que existen sobre ambas áreas para ver esos dos enfoques objetivamente en una nueva perspectiva como complementaria a cada uno. otro más que competitivo.

Quizás bajo las siguientes circunstancias. Expertos ágiles: corríjalos si estoy equivocado

1) Donde puede modelar su producto o sistema mínimo viable que utilizará para validar la idea, únicamente sobre la base de talleres y trabajos de análisis. Si este es el caso, es posible que tenga un conjunto concreto de requisitos por adelantado y pueda evitar el uso de Agile
2) Donde no tiene suficiente presupuesto para armar un equipo ágil desde el inicio o usarlos de manera eficiente
3) Cuando el equipo carece de comprensión de Agile, requiere capacitación profesional de Agile y donde esto demostrará ser una sobrecarga
4) Cuando reunir un equipo ágil resulte ser una exageración debido a la distribución geográfica de los miembros del equipo, las diferencias de tiempo, los puntos de control variados y otras razones

Orando

Haga que hablen con otros fundadores de startups. Pedir –

• ¿Cómo se ha beneficiado su negocio del uso de Agile?
• ¿Cómo ha sufrido su empresa el uso de Agile?

Aquí de primera mano cómo Agile ha beneficiado a otros, y para qué áreas los fundadores consideran que Agile es más útil. Al final del día, depende de los fundadores y su equipo.

Concéntrese en el liderazgo más que en el proceso. He visto que casi todos los procesos aceptados funcionan bien siempre que:
1. está definido
2. todos lo entienden y lo siguen
3. no es más proceso del necesario para realizar el trabajo (con advertencias sobre cambios, documentación, etc.)
4. el liderazgo del equipo sabe cuándo deben tomar medidas y cuándo deben salir del camino
5. el liderazgo del equipo entiende que son facilitadores, no policías

Donde los tipos de procesos tienden a fallar es cuando se vuelven demasiado difíciles de manejar, demasiado difíciles de seguir o el proceso se interpone en el trabajo o lo contrario, demasiado mal definido, no entendido o demasiado ad hoc. En marketing (mi área), Agile rara vez se puede implementar en la medida que exigen los evangelistas, debido a la falta de propietarios de productos para una cosa. Los clientes no quieren el rol y tampoco quieren pagarle a alguien de la agencia para que cumpla el rol. Sin embargo, Agile todavía tiene muchos elementos que son realmente útiles. Por ejemplo, gráficos de carga, velocidad, retrasos, centrándose en entregar un producto de trabajo completo (incluso si no tiene todo lo que se desea en función de las características) para cada iteración, los conceptos de prueba, etc.

El beneficio de trabajar con una startup es que, en general, son más pequeños, por lo que puede salirse con la suya con menos procesos, especialmente si todos están en la misma ubicación. Con organizaciones más pequeñas, también tiene una mejor oportunidad de asegurarse de que el equipo sea correcto, esté debidamente motivado, etc. y que el liderazgo sea menos teórico, más personal.

Tengo cuidado con cualquiera que diga que una filosofía debe implementarse al pie de la letra para que tenga algún beneficio, o que solo un tipo de proceso funcionará para cada configuración. Cada situación es diferente. Lo que aportan los paradigmas de gestión de proyectos es un punto de partida definido y listas de verificación de áreas que deben considerarse. La filosofía justo a tiempo y lo suficiente que comenzó a rodar la bola Agile es la clave, no si lo llamas Scrum.

Por cierto, como alguien de la Commonwealth, Scrum y Sprints suenan terriblemente horribles, es como si alguien que nombrara estas cosas nunca viera Rugby. Un scrum real es principalmente conflicto: desordenado, sudoroso y sangriento. Ser tomado en serio por cualquier persona de la alta gerencia siempre será un problema con esta convención de nomenclatura, al menos en países familiarizados con el juego.

Hay una ironía de que Agile fue concebido para reducir el BS de gestión, pero los gerentes mediocres (dudo en decir líderes) aprovecharon la oportunidad de cargar TLA, terminología de ardilla secreta y montones de documentación, solo para definir un sistema diferente al anterior. . Si comenzamos hablando inglés (o el idioma que elija), estamos muy por delante, sin importar el sistema de gestión.

Déjelo en claro con casos de uso y escenarios en los que ha fallado.
Me gustaría saber qué te hace pensar que ágil (suponiendo que el scrum ágil) no sea para el inicio. Es un marco de trabajo de gestión. No debería ser una preocupación donde se implementa, sino que debe implementarse de manera efectiva.
Siempre y cuando las personas sepan cómo hacer las cosas que deben hacerse. Ágil es tan bueno o mejor que la mayoría de los marcos de gestión. Si lo ves ágil, sé flexible y trabaja como desees. Lea y siga las etapas para obtener resultados.