Está tendo datas de entrega fixas para os elementos uma maneira “Ágil” de trabalhar?

Existe uma diferença entre cumprir o prazo e cumprir todos os requisitos. É como o velho ditado "rápido, bom ou barato, escolha dois".

Então, aqui você tem datas fixas para entrega - isso é bom, significa que você tem o prazo na entrega do que no final do seu último sprint será o produto final. Você se lembra de que você sempre tem que liberar o software de trabalho no final de cada sprint, não é?

O que pode acontecer é que o software final não terá alguns recursos. Bem, isso acontece com todas as metodologias de desenvolvimento, incluindo a cascata. Tudo o que vai acontecer é que você será encarregado de produzir uma versão do patch depois, ou uma versão 2. Isso pressupõe que sua entrega final seja boa o suficiente, é claro!

Portanto, datas fixas não são uma maneira não ágil de trabalhar. Ágil não significa que haja um orçamento ilimitado para você jogar com suas novas ferramentas de planejamento. Isso significa que você terá que se concentrar na entrega, isso nunca é uma coisa ruim.

Não. Esse é o tipo exato de coisas que empresas sem software tendem a fazer. Existem planos, prazos e orçamentos. E isso inevitavelmente falhará, já que os humanos são ruins em prever o futuro.

Vamos passar pelos vários pontos aqui:

We keep being told we are going to be working in an agile way on a new project by senior management.

Se você fosse ágil, teria equipes auto-organizadas, sem saber como trabalhar pela gerência.

However, they have now come up with a plan detailing all work they want us to deliver with dates against each element and showcase dates again with what will be demoed in each one.

Não. Isso é basicamente a antítese do desenvolvimento iterativo. Algo acontecerá (alguém fica doente, alguém sai, alguma exigência foi esquecida, seus servidores morrem, o que seja) e então você perde um desses objetivos. Agora, a administração pode recalcular o plano inteiro ou quebrar o chicote no desenvolvimento.

none have been estimated by the dev team.

Então, como a gerência sabe que este plano é viável em tudo ? No Agile, o trabalho é uma negociação. Negócios diz: nós gostaríamos disso. Engineering diz: ok, assumindo XYZ, isso levará 3 semanas. Não há colaboração com o cliente no que você está descrevendo. Não há indivíduos e interações.

To me this seems senior stakeholders have not bought into Agile and therefore we are doomed to fail implementing it at a lower level.

Você não está necessariamente condenado, mas se não for, é apenas uma coincidência. Quando todo o trabalho aparecer porque o gerenciamento não pode ver o futuro, você perderá suas datas (ou produzirá código de má qualidade ou exigirá mais recursos do que o esperado). Essa será então a sua falha sua . A gerência provavelmente pressionará você a trabalhar mais horas para acertar a data, ou talvez lançar as pessoas ao problema.

Melhor caso , o gerenciamento é realmente ágil e inteligente o suficiente para reduzir o escopo. Significa que eles gastaram todo esse tempo construindo um grande plano detalhado que é inútil.

Se houver uma expectativa de que conjuntos específicos de recursos sejam entregues em datas específicas, não, isso não é um gerenciamento ágil de projetos. O gerenciamento ágil de projetos é empírico por natureza. As projeções não são feitas com base nos desejos dos executivos, mas sim na análise do desempenho anterior.

Sua descrição combina com o que eu considero ser agile de carga. O foco está nos processos e cerimônias específicos e não nos conceitos básicos de gerenciamento de projetos baseados em evidências. Você pode ter alguma sorte em conseguir que as pessoas de negócios entendam se você relacionar isso com Lean ou TPS . O problema real que você precisa resolver aqui é fazer com que a gerência ultrapasse o medo do desconhecido. A resposta certa para os executivos é "não podemos lhe dizer agora quando as coisas serão feitas, mas uma vez que começamos a entregar valor, podemos construir projeções com base em nossa experiência". Os desenvolvedores tendem a dizer coisas como "está feito quando está pronto" e "não sei quando isso será feito". Os gerentes não dizem coisas desse tipo para os executivos, isso faz com que pareçam bobos. Eles estão simplesmente fazendo o que sabem.

O mais provável é que o plano falhe e precise ser revisado. O maior risco para a equipe é que haverá um grande esforço para atingir os prazos e a qualidade será prejudicada. Em algum momento você não estará no alvo (provavelmente, será o primeiro prazo) e haverá um empurrão para atingir essa data. As horas extraordinárias serão esperadas e haverá pressão para cortar custos (pular testes de unidade, revisões de código, etc.) Esta é uma pista escorregadia e uma vez que você comece a percorrer este caminho, é um pouco espiral descendente e as coisas ficarão feias. A produtividade irá piorar à medida que o projeto continuar dessa maneira.

Se você puder fazer com que a equipe de desenvolvimento apresente uma frente unificada, você realmente deve empurrar para trás e manter a linha na qualidade. Minha experiência é que os gerentes de projetos tendem a pensar que a saída de software é linear. Ou seja, cada período X irá produzir Y 'precentage complete'. Isto é, se você não estiver "50% completo" até a metade do tempo permitido, os klaxons começarão a soar. Na realidade, se você estiver fazendo certo, o primeiro recurso tende a demorar muito mais do que o 50º recurso (de tamanho similar). Se você conseguir passar pelo período inicial da crise de perigo ("o que está acontecendo?", "Eu não" não vejo nada sendo feito! ") você provavelmente ficará bem.

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.

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.

O Agile não impede que você planeje marcos (por exemplo, lançaremos V 1.0 em 3 meses), mas o que entra em cada etapa não pode ser corrigido.

Eu penso como você deve reagir depende da natureza do projeto. Se o projeto for enviar um homem para a lua no segundo trimestre de 2017, todos concordarão que está fadado ao fracasso. Se você acha que pode entregar um MVP até o final do segundo trimestre de 2017, trabalhe nele como sprint.

Se a gerência achar que sua equipe está fazendo o melhor possível e você pode mostrar progresso em cada sprint, você deve ser capaz de negociar mais tempo.

CADA projeto relevante de negócios tem restrições:

• Tempo
• Recursos
• Um conjunto de recursos mínimo esperado

Isso não é mais nada. Desenvolver ágil não significa que "as pessoas nos pagam dinheiro, para que possamos desenvolver o que quisermos para quando estiver pronto" - você sempre terá algum tempo. Sempre haverá alguma data com alguns requisitos mínimos e, se eles não forem cumpridos, o projeto será cancelado e será chamado de falha. Às vezes, elas podem estar implícitas - portanto, o gerente sabe "Se eu não tiver uma interface do usuário em funcionamento com esses recursos depois de quatro semanas, esse projeto está fadado ao fracasso" - ou pode haver acionistas que definiram uma meta.

Existem muitos projetos resultantes da legislação. - Se o governo decidir implementar o Recurso X até 2017 para respeitar uma nova lei, você terá um prazo inegociável e um conjunto de recursos que precisam estar prontos. A única variável é a quantidade de recursos que o gerenciamento pode alocar para a tarefa. - E nesses projetos, em que o prazo é uma decisão externa, eles precisarão acompanhar seu progresso, ouvir seu prognóstico e contratar equipes ou terceirizar parte do trabalho para atingir suas metas.

Tudo isso não se opõe ao desenvolvimento ágil. Você ainda terá seus sprints, desenvolva seus recursos em seu próprio tempo. Você sempre obterá suas prioridades de recursos de um cliente - e trabalhará para fornecer o máximo possível desses recursos até o prazo final.

Se o prazo realmente for atendido com os recursos disponíveis, isso é um problema de gerenciamento. Você pode dar seu prognóstico e atualizações de status semanais / diárias e eles podem decidir se eles precisam de mais recursos. Caso contrário, você continuará trabalhando em sprints e entregando runnables - o mesmo que qualquer projeto.

Como alguém já apontou antes do manifesto dizer:

Individuals and interactions over process

Eu sugiro que você dê uma olhada no plano apresentado e sugira mudanças nele. Lembre-se que o Manifesto diz que o backlog nunca é final, continua evoluindo.

Então você pode levar suas sugestões para a equipe. Se você tiver um raciocínio válido e a equipe concordar com isso, qualquer proprietário de produto que se preze considerá-lo-á e avaliará o backlog para refletir a opinião de toda a equipe.

Este é o ponto em que poderia seguir dois caminhos.

1. O proprietário do produto e a empresa concordam com seu raciocínio e podem aumentar os recursos para cumprir o prazo se isso for uma opção OU podem optar por deixar alguns recursos para cumprir o prazo.

2. Eles ainda podem querer manter sua própria versão contra a opinião coletiva da equipe.

Se o resultado for # 2, isso não é Agile.

Se você acabar em # 1, eu diria que a equipe está no caminho certo, porque o Agile não é apenas sobre os desenvolvedores "Respondendo à mudança", mas também sobre o negócio ser capaz de responder às mudanças.

Imagine pedir a alguém para pintar uma parede, uma casa e depois uma rua inteira para você, quanto tempo você daria a essa pessoa para fazer isso?

Qualquer que seja sua resposta, você estará errado. É isso.

Não há como eles estarem certos sobre as datas se não perguntarem às pessoas que precisam fazer o trabalho o que pensam.

A propósito, se você (como uma equipe) aceitar essas datas, você está errado.

Você deve pedir algum tempo para trabalhar nesse planejamento junto com as partes interessadas, para que você possa definir prioridades dependendo de como é fácil e rápido fazer as coisas.

Por exemplo, talvez o trabalho final leve o dobro do tempo que eles pensavam, mas eles poderiam usar um beta muito antes do esperado.

Em suma, você não pode deixar que as pessoas pensem que você será capaz de fazer X em tempo Y se você não puder ou puder ser mais rápido. É sua responsabilidade deixar claro o que você precisa em termos de detalhes e tempo.

Não é o seu planejamento de planejamento.

Mas se você prentend você não sabe o plano e apenas trabalha sprint por sprint. Poderia estar agly trabalhando.

Sempre haverá datas e orçamentos. Sempre há um risco de que eles sejam perdidos ou superados e, quando isso acontece, você sempre terá que recorrer a um plano B.

Se você tem trabalhado de forma ágil, então o plano B é a última demonstração do sprint