Bem-vindo aos negócios reais.
Existe um estilo de negócio antigo, que costumo chamar de "desenvolvimento tradicional" e depois há um novo estilo, "desenvolvimento ágil". Se eu tentar tratá-los como ideais opostos, veremos uma divisão direta no meio: os planos e os requisitos vão para a coluna tradicional, a descoberta e a evolução vão para a coluna ágil. É limpo, arrumado e errado.
Na realidade, o negócio é uma busca pelo meio feliz entre os dois. É fácil mostrar que ou o extremo realmente cai de cara no chão. Nós, que amamos o Agile, demonstramos ansiosamente todas as questões do puro ideal de desenvolvimento tradicional, e há muitos que podem mostrar as muitas maneiras pelas quais o Ágil puro se desfaz. As empresas ágeis de sucesso são aquelas que encontram seu equilíbrio particular entre as duas. As empresas tradicionais bem-sucedidas são aquelas que encontram seu equilíbrio particular entre as duas. Você não pode ter um sem o outro.
Até mesmo nosso processo SCRUM abençoado mostra um equilíbrio entre os dois. Embora exista uma tentativa clara de maximizar a agilidade, existem algumas compensações importantes. Por exemplo, o Product Owner tem o poderoso trabalho de defender todos os clientes. O SCRUM intencionalmente não especifica como essa interação funciona. Intencionalmente, tenta convencer o fato de que todos precisam ser pagos no final do dia. É o trabalho do Product Owner criar a ilusão de que isso não importa.
(É interessante notar que o agile puro funciona muito bem, desde que você não seja pago até que você produza um produto, e você não terá acesso a informações proprietárias até que você seja adquirido. Eu acho que os únicos engenheiros de software que estão confortáveis com este comércio são os empresários)
Portanto, o gerenciamento determinou quais recursos estarão lá e quando eles precisarão estar lá. Isso é bom. Uma frase que ouvi é "o cliente escolhe o que e o quando, o produtor escolhe quem e como." Você se inscreveu para o "o quê" e o "quando". Eles não declararam nada sobre quem ou o como, a não ser para lhe oferecer uma chance de usar "Ágil" como seu como. Tudo o que resta é ajudar o gerenciamento a entender quantas pessoas precisarão contratar para atender às suas necessidades.
Em um mundo perfeito, sua empresa é ágil de fora. Ele interage com seus clientes de maneira ágil, permitindo que os desenvolvedores se desenvolvam com agilidade para eles. No entanto, muitas vezes a empresa deve interagir com o exterior enquanto se desenvolve agily dentro. Entre sempre é um conjunto complexo de compensações, exclusivo para cada empresa.
Pessoalmente, trato essa situação como um caso de teste para qualquer um que acha que entende o desenvolvimento ágil. Em algum momento no futuro, você terá que desenvolver um produto para um prazo, e esse par produto / prazo será relativamente fixo.
Se um produto / prazo fixo quebrar seu processo, você pode realmente dizer que você era ágil?
Meu conselho: não pense nisso como uma cachoeira. Você ainda controla o "como". Você ainda pode fazer todo o rápido sprinting e prototipagem flexível pelos quais a Agile é tão famosa. Você apenas precisa estar ciente de que a borracha encontra a estrada, e você tem que entregar. Este é o mundo real, não o mundo ideal. Teria sido melhor para eles perguntar em primeiro lugar? Certo. Pode não ter sido seu chamado. Pode haver mil razões relacionadas a negócios para fazer do seu jeito que você simplesmente não entende completamente. Sinta-se à vontade para empurrá-los, mas entenda que eles podem ter uma boa razão para o que fizeram.