Introdução ao desenvolvimento ágil após o início tradicional do projeto

Há cerca de um ano e meio, entrei em um local de trabalho que alegava fazer desenvolvimento Agile. O que eu aprendi foi que esse lugar adotou várias práticas ágeis (como posições diárias, planejamentos e revisões de sprint), mas nenhum dos princípios (apenas a tempo / mentalidade suficientemente boa, expondo falhas cedo, comunicação rica).

Agora, tenho a tarefa de tornar a equipe mais ágil e tenho certeza de que tenho total adesão dos desenvolvedores e da equipe de negócios. Como programa piloto, eles me deram um projeto que apenas completou 15 meses de coleta de requisitos, possui um documento de Análise e design de 110 páginas (a ser considerado como "escrito em pedra") e onde não tenho acesso ao final usuários (apenas para o comitê formado pelos gerentes dos usuários que não usarão o produto).

Comecei pequeno, fornecendo a eles uma lista de entregas esperadas para os 5 primeiros sprints (deixando os futuros sprints indefinidos), uma lista de objetivos para o primeiro sprint e dissecei o documento de A&D para obter histórias de usuário suficientes para atender aos objetivos do primeiro sprint .

Desde então, eles perguntam por que não temos todos os requisitos para todos os sprints, por que não comecei a trabalhar no material para o terceiro sprint (que eles consideram mais importante, mas se baseia nos resultados do primeiro 2 sprints) e estão pressionando por ainda mais documentação que minha equipe de TI inteira considera ocupada ou não relacionada a nós (como escrever o manual do usuário antecipadamente, documentar todos os campos de dados de todos os sprints iniciais e muito mais trabalho "inicial").

Isso tem sido bastante difícil para mim, como novo gerente de projetos, mas há melhorias que efetivamente implementei, como scrumban para gerenciamento de histórias, programação em pares e que a empresa nos dê testes de aceitação do cliente antecipadamente (como parte da documentação de requisitos) .

Então, minhas perguntas são:

1. O que posso fazer para introduzir mudanças de maneira mais eficaz em um negócio resistente?
2. Existem outras práticas que posso introduzir no lado de TI para ajudar a mostrar aos negócios os benefícios do ágil?
3. O ônus da documentação está nos estrangulando - a empresa ainda a vê como uma estratégia de gerenciamento de riscos, e não como um risco. O que podemos fazer para aliviar as preocupações e demandas da documentação (especificamente a quantidade de documentação e a necessidade de toda a documentação)?
4. Estamos em um prédio separado do nosso negócio, a cerca de 3 quarteirões de distância, e eles se recusam a ter seu pessoal no projeto co-habitado porque essa pessoa "não poderá trabalhar em outros projetos enquanto estiver em nosso construção." Eles esperam que sempre vamos até lá e agrupemos nossas perguntas para que possamos perguntar todas de uma vez e não desperdiçar o tempo dessa pessoa com "interrupções constantes". O que podemos fazer para obter uma comunicação mais rica deles?

Qualquer conselho adicional também seria apreciado.

Obrigado!

Tenho certeza de que tenho total adesão dos desenvolvedores e da equipe de negócios [...] não tenho acesso aos usuários finais [...]

Uma coisa a ser bem clara é a diferença entre ter a certeza verbal de que você "tem adesão ", por um lado, e por outro lado, o compromisso real de quem está patrocinando seu trabalho.

Meu melhor conselho para você é deixar de lado o rótulo "Agile". Proibir a palavra da conversa, na medida do possível. Em vez disso, concentre-se nas seguintes coisas:

• Quais são os resultados que você deve fornecer (você especificamente, não a equipe)
• Quais são os critérios de sucesso para sua missão (novamente, sua e não da equipe)
• O que significa que você tem à sua disposição (incluindo pessoas, acesso a pessoas, tempo, informações, orçamento de treinamento, o que for)

"Tornar a equipe mais ágil" não é um objetivo acionável. Não é específico o suficiente, não é mensurável, não tem condição final. O que você precisa é de algo específico: uma meta expressa em termos de X por cento menos defeitos, ou Y por cento das datas de entrega dos recursos realmente cumpridas, por Z data.

Para alcançar esses objetivos, pode ser necessário introduzir alterações. Agora, algumas regras práticas se aplicam. Toda melhoria é uma mudança, mas nem toda mudança é uma melhoria. Costuma-se dizer que as pessoas resistem à mudança, mas na verdade as pessoas resistem à mudança e sem saber se a mudança será uma melhoria.

Concentre-se em práticas que você acha que serão vitórias fáceis, frutas baixas. Concentre-se nas práticas que estabelecem uma estrutura não apenas para implementar a mudança, mas para avaliar os efeitos da mudança e garantir às pessoas que elas estão resultando em melhoria, e não em regressão. Os "radiadores de informação" são bons, assim como as retrospectivas.

Algumas dessas mudanças podem ser necessárias e percebidas como ameaçadoras, como ter mais acesso a pessoas que possuem informações importantes. Não se comprometa com isso: "buy in" significa um processo de negociação em que você realmente tem a chance de entregar o que é solicitado, não sendo levado como um cordeiro ao abate político.

Tente organizar as coisas para que seja difícil transferir a culpa para você, se as coisas não derem certo (e muitas provavelmente darão errado). Esteja ciente de que isso pode acontecer e esteja preparado se acontecer: conheça sua estratégia de saída.

Para introduzir uma coisa nova sem problemas, você precisa garantir que as pessoas não a vejam como uma ameaça e permanente .

Muitos de nós estão naturalmente conectados para evitar qualquer tipo de coisa nova. É biológico. As pessoas que procuram novidades nunca causam problemas. Você precisa garantir que as pessoas mais ansiosas não vejam sua sugestão como uma ameaça para o conforto atual.

A maneira ideal para uma equipe adotar uma prática ou idéia é garantir que a idéia seja proveniente deles, e não de pessoas externas, como a gerência ou, pior ainda, alguns consultores aleatórios. Para que isso aconteça, crie reuniões de brainstorming com toda a equipe com apenas um tópico. O tópico deve ser o problema. Na reunião, você terá que trazer cuidadosamente as idéias e vir com argumentos e fatos.

Não gostamos de tomar decisões sobre coisas permanentes. Já estamos ansiosos pelo efeito de uma mudança potencial. Esse comportamento é bem conhecido pelas lojas de animais. Comprar um cachorro é uma decisão muito grande e provavelmente mudará radicalmente sua vida. Quando você está na loja, o vendedor geralmente propõe que você o leve de volta para casa e devolva-o se você mudar de idéia. Como você pode esperar, há muito poucos retornos. A proposta tem apenas um objetivo: reduzir a ansiedade que impede as pessoas de tomar decisões. Sugira à sua equipe que tente por um período fixo de tempo após o que avaliará seu efeito.

Em relação à sua segunda pergunta, sugiro que você traga uma coisa de cada vez.

Seu problema de documentação merece seu próprio post aqui no P.SE e não vejo nenhum problema com o fato de você estar em dois edifícios diferentes se ambos estiverem dispostos a se encontrar regularmente. Há situações em que um dos lados não quer se encontrar;)

Ágil não é para todos, parece que sua empresa gosta de dizer ágil porque é a palavra de ordem mais quente. Antes de tudo, provavelmente teria sido uma boa ideia pressionar por um novo projeto ou projetos de manutenção menores para começar a tornar seu processo mais como verdadeiras metodologias ágeis. Tentar redesenhar uma metodologia usando um projeto que já está em andamento é como tentar trocar um pneu no meio de uma estrada de 8 faixas. Você precisa de uma maneira de mostrar que seu negócio ágil pode funcionar, mas precisa de um ambiente em que ele possa funcionar, mas com base no que você disse que o ágil provavelmente não funcionará bem com a cultura estabelecida.

Dependendo do que eles desejam para a documentação, você poderá mostrar a eles que isso é gerado automaticamente a partir de uma ferramenta que você está usando ou é redundante e o documento B tem o documento de informações A que foi solicitado a mostrar. Você também precisa ajustar seus planos de documentação, informá-los por que suas estimativas estão mudando e solicitar que reduzam a quantidade de documentação solicitada ou dediquem recursos como um analista de negócios para criar a documentação.

Since then, they've asked why we don't have all the requirements for all the sprints, why I haven't started working on stuff for the third sprint (which they consider more important but is based off of the deliverables of the first 2 sprints) and are pressing for even more documentation that my entire IT team considers busy-work or un-related to us (such as writing the user manual up-front, documenting all the data fields from all the sprints up front, and more "up-front" work).

Esse é o seu problema. Eles não entendem. Alguém não pode pedir para você ser mais ágil e não estar disposto a ir junto. Eles têm expectativas erradas. As coisas estão quebradas, na frente, antes mesmo de começar. Corrija as expectativas ou você irá falhar. É como eu pedir para você dirigir 150 MPH e eu lhe dou uma Chevette para fazer isso.

Crie o tempo / recurso / custo da documentação que eles desejam e deixe-os ver até que ponto isso atrasa o cronograma.

Isso pode ajudar a mostrar a eles o quanto eles estão trabalhando na equipe do projeto e como isso pode ser reduzido se eles não estiverem fazendo isso.