Como apresentar o Agile a uma equipe que usa métodos rígidos não-Agile?

Considere uma empresa que é orgulhosamente certificada por alguma metodologia não-Ágil e a usa como um ponto de venda para seus clientes para demonstrar responsabilidade.

Como você introduz o Kanban ou o Scrum progressivamente sem quebrar todo o sistema e ainda torná-los confiantes de que ele ainda pode ser responsável / auditável ?

Eu sei que isso está possivelmente relacionado a " Como você introduziria uma metodologia ágil como o Scrum ", mas aqui estou pensando em maneiras de contornar / contornar o fato de que a empresa impõe uma certa maneira de gerenciar o SDLC sob a falsa pretensão de que é a única maneira de ter uma trilha de auditoria.

Eu acho que é um mito que as equipes de projeto Agile não documentem suas aplicações e este é o primeiro ponto de resistência que você obtém em empresas certificadas para ter a melhor documentação de acordo com seus padrões.

Eu trabalho em uma empresa certificada ISO-9001, mas também fazemos Scrums em um grande número de nossos projetos. No nosso caso, a mudança veio dos responsáveis ​​pela entrega do projeto (ou seja, pessoas bastante seniores) e é por isso que é adotada - em oposição a um gerente de projeto ou desenvolvedor que tenta promover essa mudança.

Uma prática útil que seguimos é o documento suficiente, mas continuamente . Obviamente, isso significa que não seguimos todos os modelos prescritos para o projeto, mas existe um entendimento e um acordo conscientes sobre quais seções / documentos são necessários versus aqueles que são apenas despesas gerais inúteis.

Você precisaria socializar esse ponto de vista e obter a aprovação do grupo Qualidade ou da divisão de Padrões ou o que for chamado.

O princípio do Agile é a documentação 'apenas o suficiente'. Você pode tentar enviar do cliente para expressar para a equipe quanto é suficiente? O gerente de projeto pode conversar com o cliente e entender quais são suas expectativas e necessidades organizacionais e, então, documentar a decisão e atendê-las. Se é bom o suficiente para eles (ou seja, os clientes pagantes), pode ser o que você segue.

Se eles acham que o Agile não escala em grandes projetos, convença-os de que podem - por decomposição e esforço paralelo.

Em grandes organizações, o controle e a supervisão de grandes programas são realizados executando um PMO (Project Monitoring Offices) que conduz um planejamento convencional para gerenciamento de custos / contabilidade / recursos, etc. - portanto, eles exigem muita documentação, mas podem monitorar o progresso usando práticas ágeis. (o gráfico de queima de SCRUM para um). Eles precisam saber como técnicas como a integração contínua os ajudam mais cedo ou mais tarde e, portanto, é melhor para a produtividade de todos afastar os documentos gerais.

O Agile é um conjunto de habilidades que uma equipe pode aprender, em grande parte ortogonal às nossas habilidades técnicas tradicionais. Mas se você adicionar isso às habilidades existentes, é claro que poderá se tornar uma equipe mais eficaz. Standups diários (ou seja, reuniões do Scrum) não serão possíveis da noite para o dia - mas você teria reuniões regulares da equipe (digamos, quinzenalmente) no momento? Eu diria que comece convertendo aqueles para seguir a agenda de perguntas do Scrum (não muito sorrateiramente;) e mostre à equipe mais ampla por que essa abordagem pode funcionar e não significa documentação negligente / padrões ruins ou quaisquer outros mitos.

Eu separaria Scrum de Kanban primeiro.

Com o Kanban - e aqui está uma boa fonte de como fazê-lo corretamente - o princípio é que você respeita o processo de saída quando inicia. O Kanban não é o que você substitui pelo processo existente, mas o que você aplica a ele. Mapeie-o, visualize e configure certas condições para melhorias graduais.

Scrum é fundamentalmente diferente no sentido de que é algo que irá deslocar o processo existente.

Uma equipe que está acostumada a ciclos de SDLC em cascata de 12 meses (ou mais) enfrentará dificuldades para fazer a transição para o Scrum. A redução gradual do ciclo para trens de liberação de 6 ou 3 meses com escopo menor pode ser uma etapa intermediária útil.

Como qualquer coisa nova que você tente apresentar a uma organização, você enfrentará forte oposição. Você está pronto para ser criticado e ser o responsável se ele falhar? Você tem que ser uma pessoa forte. Esse é o preço a pagar quando se expõe.

• Pergunte a si mesmo por que você deseja usar o Scrum . Você precisa resolver um problema real?
• Garanta que VOCÊ está comprometido com isso, porque ninguém fará isso por você. Você será o dono da coisa. Pelo menos até trazer efeitos positivos na organização
• Treine-se . Livros e internet não são suficientes. Vá para um curso primeiro ou você aumentará drasticamente sua chance de implementar o Scrum incorretamente. O que provavelmente levará sua equipe a piores resultados do que antes
• Venda-o primeiro para a equipe . Você deve ter todo o seu apoio, obviamente
• Não proponha uma mudança, proponha um teste . E considere assim. O Scrum pode não ser adequado à sua organização (ou à sua equipe)
• Encontre um patrocinador na alta gerência

Isso é quase exatamente o que aconteceu em nossa empresa. Seguimos métodos rigorosos e não ágeis. Quando um novo Gerente Técnico Líder se juntou, que tinha alguma experiência com o SCRUM , ele achou que seria bom experimentá-lo.

A maneira como fizemos isso foi levar um pequeno grupo de desenvolvedores (e analistas) para formar uma equipe piloto do SCRUM. Seguimos a rigorosa metodologia SCRUM por cerca de 4 meses, após os quais a empresa refletiu sobre o que fizemos, como fizemos, analisamos os dados (você sabe, todas as coisas que os BAs precisam fazer).

O que eles descobriram foi que o piloto foi um grande sucesso. Então eles formaram outra equipe que segue Kanban, e eles também foram um grande sucesso. Acho que se fala que o restante dos desenvolvedores também está formando equipes SCRUM / Kanban.

Eu acho que o piloto foi fundamental. Dá ao lado estrito do negócio tempo para avaliar e ver se ele funciona primeiro.

Sou um treinador ágil e uma das chaves para mudar iniciativas é a adesão em todos os níveis! Isso inclui executivos, equipes de desenvolvimento, gerentes, etc. Antes de anunciar um esforço de mudança grande ou pequeno, sugiro que você convide as pessoas primeiro. Fazer isso através de uma conversa em terceira pessoa é a maneira mais fácil para as pessoas começarem a colocar em marcha novas idéias. O que é terceira pessoa? Um blog, vídeo do youtube, apresentação, ... etc. Dessa forma, essas pessoas podem começar a ter suas próprias idéias e, com a sua influência, embarcarão em uma iniciativa de mudança.

Aqui estão dois vídeos engenhosos que usei para despertar interesse em todos os níveis da cadeia alimentar.

Kanban: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI