Maneiras eficazes de introduzir o Agile no local de trabalho?

Na sua experiência (anedótica ou não), quais são algumas maneiras eficazes de introduzir o Agile em uma organização ou empresa não-Agile?

ATUALIZADO: Alguém pode falar sobre casos em que você tentou apresentar o Agile, mas você foi "abatido"? Além disso, você agora tem um entendimento retrospectivo de por que foi "abatido"?

É DURO, MAS NÃO É IMPOSSÍVEL. A menos que você viva no paraíso. Para etapas específicas que você pode seguir, recomendo sinceramente que você pegue uma cópia da Fearless Change

• Primeiro, obtenha o apoio da gerência . Se você não fizer nada, isso compensará este. Se o nível superior for tudo 'O prazo é ontem ...', 'Trabalhando nos fins de semana pelos próximos 3 meses', 'Por que você está escrevendo testes quando deveria estar? codificação? ... podemos testar mais tarde. O dodo simplesmente não voa.
• Veja se a cultura da sua organização é adequada para o ágil. Isso foi algo que eu perdi .. Para pegar emprestada uma linha do livro .. O processo será mais fácil - mais rápido se a cultura apoiar e nutrir novas idéias, permitir tempo para as pessoas aprenderem e fazerem coisas novas, for paciente o suficiente para apoiar inovações com benefícios a longo prazo e não considera a falha uma sentença de morte
• Gente : identifique os inovadores: adotantes precoces: maioria precoce: maioria tardia: razão de atraso. Os três primeiros são o seu público-alvo inicialmente .. deve estar em torno de 30-40% .. isso fornece a massa crítica para começar a rolar. O problema é que o Agile chama a atenção para os elefantes na sala .. deficiências e problemas se tornam facilmente visíveis .. se você mora em um lugar que teve uma "Explosão de Bozo" (para citar o termo de Guy Kawasaki) , a mudança seria realmente lento e doloroso .. se for o caso. Temos a tendência de assumir que, se uma ideia for boa, ela será aceita. Não é verdade. Muitas razões sociológicas levantam suas cabeças.
• Em seguida, não tente muitas coisas ao mesmo tempo. Vá devagar .. vá com calma . O truque é usar uma abordagem semelhante à refatoração de código herdado. Encontre pequenas feridas aqui e ali e remende-as com um curativo ágil. Certifique-se de que as pessoas entendam a prática e os benefícios e os adotem com o tempo. Nem tudo vai ficar, mas logo se torna melhor no seu conjunto. A rapidez depende de várias variáveis, algumas das quais estão fora de seu controle.
• É um investimento pessoal enorme para fazer isso acontecer . Re-examine se você está disposto a fazer esse compromisso e passar pelos altos e baixos que ele traz. Além disso, você pode ter que entregar o bastão para outra pessoa ou alguém mais alto. Esteja preparado para abandonar a propriedade da mudança para um bem maior. Não caia na síndrome de 'É meu bebê'.
• O Agile é diferente para cada equipe, cada organização . Nem tudo que você lê / propõe funciona. Deixe a aceitação guiá-lo para as coisas que funcionarão no seu cenário. Encontre outras maneiras que compensem as práticas que não se enraizaram.

Espero que isso faça sentido .. como você deve ter adivinhado, eu estou nisso há algum tempo :)

Ouça a equipe, a gerência, as partes interessadas e ouça as pistas. Eles provavelmente estão sentindo dor em várias áreas que o Agile aborda diretamente.

Atenha-se a sugestões que possam aliviar diretamente essas dores. "Você não pode curar o que não pode sentir" - por assim dizer.

Isso leva muito tempo, mas construir confiança é de extrema importância. Com sucessos passados ​​e com a confiança de sua equipe e de seu gerente, eles o procurarão na hora de tomar decisões.

Eu já vi isso acontecer com meus próprios olhos, depois de anos de frustração ao tentar levar as pessoas a mudarem a maneira como entregamos software. E enquanto estou tendo sucesso agora, não estou nem perto de terminar. Existem toneladas de áreas a melhorar, e atualmente estou tendo mais sucesso ao introduzir pequenas mudanças que abordam diretamente algum tipo de dor que estamos sentindo.

Por fim, eu diria que é muito empático. Cometi o erro de descartar a maioria das idéias antes de realmente analisá-las, porque não li sobre isso no "livro ágil XYZ". Ouvir sua equipe e tentar implementar algumas de suas sugestões ajudará bastante.

Boa sorte!

Ignorando o técnico, descobrimos que encontrar um grupo dentro da organização que possa comprar metodologias ágeis e fornecer um 'ambiente de teste' era crucial. Tínhamos muitas pessoas em nossa empresa que não entendiam terminologia Agile diferente, estavam confusas com termos e processos e havia um medo geral.

Meu grupo de pesquisa estava muito interessado em tentar fazer o Scrum funcionar (junto com várias outras metodologias do tipo Agile). Nosso interesse nos permitiu formar uma cama de teste dentro da empresa para experimentar os vários elementos. Nós ensinamos muito - conversas no primeiro corredor com pessoas, apresentações para executivos da empresa, etc. Nós não nos esforçamos muito - nós educamos. Depois pedimos permissão para experimentá-lo com o nosso grupo.

Haverá muitas respostas sobre como mostrar empiricamente como coisas como programação em pares, desenvolvimento orientado a testes, Scrum etc. podem economizar tempo, mas no final do dia, sinto que a prova precisa vir de dentro da sua empresa. Encontre um grupo que você possa usar como banco de ensaio e peça que eles realmente o façam. Nada aliviará os medos melhor do que mostrar que o seu grupo que faz isso acontecer.

Enfie-os na garganta, mas sem eles perceberem;)

Eu tenho tentado lentamente implementar princípios ágeis (principalmente scrum) no meu local de trabalho nos últimos 6 meses. Eu apresentei stand ups diários, o que levou algum tempo para se acostumar com todos, mas está funcionando muito bem. Como todos trabalhamos em diferentes programas que fazem parte de um sistema, é um pouco difícil seguir o scrum por definição. Meu próximo passo é iniciar reuniões de sprint para acompanhar cada um de nossos lançamentos. Já realizamos um ciclo de um mês, portanto a duração do sprint não é um problema. Também planejo seguir totalmente os princípios do scrum durante nosso próximo grande projeto. Sou um dos dois desenvolvedores da equipe do projeto, e ele é todo para melhoria contínua. Minha esperança é que a administração veja os benefícios do que estou tentando realizar.

Eu acho que a chave é ir devagar. As pessoas que estão na mesma posição há anos geralmente são contra mudanças intrusivas, mas se você pode espreitá-las peça por peça, elas não devem perceber. Comece também com as pequenas reuniões frequentes. Ao mantê-los curtos, a gerência não deve ver isso como um desperdício de tempo.

Desenvolvimento orientado a teste. Demonstrando como os testes de unidade podem acelerar o seu desenvolvedor. O tempo ao mesmo tempo em que torna o código mais estável é um ótimo primeiro passo para beber o Kool-Aid ágil.

Melhore-se primeiro. Realmente. Exemplo é a maneira mais forte de falar sobre ágil. Além disso, como alguém já disse, evite definições técnicas e use apenas termos que os gerentes e executivos possam entender. Duas semanas em vez Sprint; Planejando o Sprint Planning ou Planning Game; Gerente de Produto em vez de Dono do Produto e assim por diante. Michele Sliger fez uma apresentação incrível sobre o Agile no Waterfall Enterprise . Realmente um deve ver o vídeo. Você também pode estar interessado em outros vídeos sobre adoção ágil .

Onde estou trabalhando, aprendo que o Scrum é uma boa maneira de começar a agilidade porque a gerência entende rápido. É simples e tem um bom nome. Mais tarde, ao fazer Retrospectivas, você poderia sugerir práticas do XP como melhorias e será muito fácil que as pessoas aceitem pelo menos experimentá-las.

Atenciosamente

Nós o introduzimos em nossas tarefas de 'Manutenção' (bugs, alterações de baixo impacto, etc.) como um sprint de 2 semanas. Portanto, os desenvolvedores que estavam trabalhando em projetos de longo prazo permaneceram como estão, mas tivemos um sprint de manutenção rotativo. Então, todo mundo começou a usar gráficos de queima e estimativas de pôquer sem interromper os grandes projetos.

Então, quando cada projeto principal terminava, começamos o próximo usando sprints ágeis de duas semanas. Todo esse processo levou alguns meses para que todos estivessem nos sprints, mas isso significava que havia menos interrupções e que todos poderiam "facilitar" o processo

Dentro da equipe de desenvolvimento, a introdução do Agile é muito mais algo sobre o qual você tem algum nível de controle.

No entanto, vejo que o principal problema é o requisito do Agile para exigir feedback contínuo do seu "cliente" ou representante do cliente.

Portanto, você realmente precisa se concentrar no lado educacional das pessoas que estão fora da equipe de desenvolvimento direto, pois é provável que elas precisem mudar a maneira de trabalhar de alguma forma (isto é, muito mais contato com a equipe de desenvolvimento).

A melhor maneira de dizer é focar nos benefícios inehrent de iniciar um processo Agile e transmiti-los claramente ao seu cliente. Obviamente, se você possui uma área de vendas / contas em sua empresa, o mesmo se aplica a ela.

Etapa 1: verifique se o seu projeto possui um backlog robusto e verifique se ele é priorizado

Etapa 2: introduzir práticas de SCRUM (iterações gerenciáveis, visualizações diárias, scrum-master, proprietário do produto, gráficos de burndown)

Etapa 3: cada iteração apresenta os resultados da equipe com o burndown

então ...
implemente o TDD / BDD, emparelhe a programação, as revisões de código (todas com muita delicadeza) e, se você tiver uma equipe boa o suficiente, co-localize todos (uma sala de equipe, se possível).

Acima de tudo, entenda que haverá resistência (SERÁ), portanto, esteja pronto para gerenciar isso.

Outro aspecto a ser lembrado é que, se você faz parte de uma organização (grande ou pequena) que, como um todo, não segue essas práticas recomendadas, pode levar um tempo (se houver) para sentir que está progredindo.

As pessoas sempre são resistentes à mudança e a mudança para o scrum é bem grande. Motivação e direção são fundamentais.

O primeiro passo é motivar as pessoas a dar uma chance ao scrum. Descobri que o Google Tech Talk, de Ken Schwaber, tem sido muito útil para fazer as pessoas reconhecerem os benefícios do scrum, ao mesmo tempo em que fornece uma boa introdução. Comece com pessoas que você acha que serão receptivas à mudança, sejam eles desenvolvedores ou gerentes, para que você possa criar algum impulso. Colocar os gerentes do seu lado será uma necessidade em algum momento, mas como você lida com isso depende do seu ambiente.

Depois disso, todos precisam ser treinados, seja lendo um livro ou fazendo uma série de palestras. A menos que as pessoas saibam como o scrum funciona, você não pode começar a tentar implementar o processo.

Uma vez que as pessoas estejam motivadas e tenham uma idéia do que precisam fazer, você precisará ter sua primeira reunião de planejamento e configurar as partes necessárias do scrum (scrummaster, reuniões diárias etc.).

Espero que a primeira reunião de planejamento não ocorra sem problemas e será uma experiência de aprendizado para todos. Além disso, os primeiros sprints serão muito difíceis e provavelmente atrasados. A parte principal agora é disciplina e persistência. Não deixe as reuniões diárias durarem muito tempo, mantenha as reuniões de planejamento em tarefas e verifique se todos estão cumprindo suas funções corretamente.

Eu acho que as pessoas mais resistentes são as que desenvolvem software há muito tempo, ou as pessoas que acham que, ao passar para o scrum, estão admitindo que estavam fazendo algo errado antes. É um obstáculo difícil de superar, mas acho que, mostrando a eles os benefícios, você pode convencê-los lentamente. Isso leva tempo. Na minha experiência, os gerentes de produto são realmente resistentes porque os obriga a ser mais claros sobre seus requisitos e o que desejam. Mas uma vez que eles vêem como o processo ágil os beneficia e facilita suas vidas, eles embarcam rapidamente.

Boa sorte!

• Demonstre sucesso - veja a resposta da marca
• Preste atenção especial aos princípios / técnicas que causariam o maior impacto na empresa
• Lembre-se de que trata-se de princípios ágeis, e não de uma lista de verificação de processos

Antes de pensar em introduzir o desenvolvimento ágil, primeiro explore qual é o mais adequado para sua organização / projeto. Se, por exemplo, você estiver olhando para o scrum, considere se o usaria estritamente ou se uma forma mais solta de scrum, ou mesmo outro método, pode se encaixar melhor. Minha resposta então está no scrum como seu método ágil.

O Scrum é ótimo para projetos que exigem inovação, onde pouco se sabe e é necessário experimentar. Não é o melhor ajuste para fazer coisas como manter produtos existentes ou lidar com trabalhos de manutenção recorrentes. Felizmente, porém, o scrum é uma estrutura frouxa e você pode usá-lo da melhor maneira possível.

Para o trabalho de manutenção, o Kanban pode ser melhor para você ou você pode tentar apenas alguns elementos do scrum para gerenciar o sprint e executar tarefas como standups diários. Eu chamo isso de "scrum-but", "sim, fazemos scrum em nossa empresa, mas ...". Tudo bem, não se sinta mal por isso.

Para introduzir o scrum adequado em sua organização, você precisa do envolvimento do proprietário do produto e do interessado. Se você é uma empresa pequena, esse cara pode ser uma pessoa, o chefe e, em uma empresa maior, um gerente de produtos e o chefe / chefe de departamento. Eu sugeriria duas rotas para a introdução do scrum:

1) você pode começar a usar o scrum de forma um pouco mais flexível para gerenciar as filas de trabalho existentes imediatamente. Mas veja também o Kanban.

2) começar a usar o scrum de forma mais rigorosa em algum projeto novo que exigirá inovação, feedback antecipado e onde muito é desconhecido. Você pode sugerir ao chefe / proprietário do produto que o scrum seria ideal para este novo projeto.

Mas lembre-se! não se trata apenas de código, o proprietário do produto tem uma parte crucial e deve entender e cumprir sua função. Isso significa, por exemplo, não escrever todas as especificações antecipadamente, começando pelo mínimo, iterando rapidamente, obtendo feedback, aprendendo e alimentando essas informações e assim por diante. Tente trabalhar com um gerente de produto que gostaria de introduzir o scrum como você, mas do lado do proprietário do produto e, idealmente, ele deve ser forte o suficiente para afastar as solicitações de gerenciamento e proteger o sprint.

Será necessário um esforço conjunto do desenvolvimento e gerenciamento de produtos para introduzir o scrum.

Em um projeto tão novo, tente fazer com que a nova equipe seja transferida para uma sala separada e use notas post-it para visualizar o trabalho nos vários estados, como atraso, andamento etc. Não fique atolado nas ferramentas eletrônicas nesta fase , mantenha as coisas o mais simples possível. Não se sinta tolo em planejar pôquer com cartas quando você começar também, uma vez que sua equipe estiver na velocidade, você provavelmente não as usará apenas digitando os números.

Na minha experiência, é mais fácil introduzir o scrum em uma forma pura e depois facilitar para mais filas de trabalho do tipo manutenção. É mais difícil o contrário.

Meu comentário final é tomar cuidado, pensando que scrum é uma panacéia de desenvolvimento, não é. O Scrum é uma estrutura útil e simples para inovação de produtos, mas explore outros métodos combinados conforme sua empresa o exija e não se sinta mal por isso.

Alguns anos atrás, eu era consultor em uma empresa muito grande (quase 20.000 funcionários) que estava executando muitos grandes projetos de software corporativo. Eu estava em um deles. Um bastante crítico.

Enfrentamos muitos problemas e a pressão foi fortemente pressionada sobre nós, a equipe de desenvolvimento. Os problemas eram comuns à indústria de software, mas o gerenciamento tinha uma experiência mais orientada à infraestrutura e muito pouca experiência orientada a software. Então, tudo estava focado em nós. Eu pensei que seria uma ótima idéia contar à gerência sobre o Scrum.

Fui confrontado com uma forte relutância, então deixei de lado a idéia por um tempo. Mas os problemas continuaram a somar, então, com o patrocinador do líder da equipe, finalmente decidimos fazer o Scrum de qualquer maneira.

Qualquer pessoa, inclusive eu, teve alguma experiência com o Scrum. Então descobrimos a estrutura fazendo ...

Hoje, o Scrum é generalizado para toda a empresa através de um programa administrado por um instrutor certificado. Não sei se nossa iniciativa foi o gatilho. Dito isto, sei que foi uma verdadeira revolução em uma empresa bastante rígida.

Penso que para introduzir algo em uma empresa como essa, você deve respeitar os seguintes princípios:

• Tem que mudar é necessário . Se não houver um motivo convincente para que a mudança deva ser feita, não há motivo para as equipes de gerenciamento implementarem riscos.

• Devemos focar nos problemas de gerenciamento e sem mencionar os problemas dos desenvolvedores, a menos que eles façam parte das preocupações de gerenciamento. Em outras palavras, você deve vir com uma solução para eles, não para você. Coloque-se no lugar da gerência. Quais são as preocupações deles?

• Você não deve propor a mudança de toda a organização de uma só vez . Você deve propor um projeto piloto que você assumiria a responsabilidade. Aconselho que você forneça objetivos realistas, como o aumento significativo da visibilidade do que está acontecendo no projeto. É, IMHO, a principal contribuição do Scrum para o gerenciamento de software. Permite que o senso comum humano opere e, assim, avance.

• Finalmente, é imperativo garantir que pessoas experientes estejam no controle desta introdução. Não basta ler um livro ou dois. Você tem que ir ao treinamento e eu diria que é bastante necessário o uso de um treinador experiente. Obviamente, isso pode ser feito sem, mas será doloroso :)

Se você seguir os princípios e apresentar fatos, funcionará. Sobre fatos, você encontrará muitos no livro Software em 30 dias: como os gerentes ágeis superam as probabilidades, encantam seus clientes e deixam os concorrentes no pó . É o livro mais recente dos criadores do Scrum, Ken Schwaber e Jeff Sutherland .

Em um post de Ken sobre o livro, você pode ler:

Jeff Sutherland e eu conseguimos. Escrevemos um livro juntos, nossa primeira redação conjunta desde a publicação inicial do Scrum em 1995. O que nos levou? A pergunta que frequentemente fazemos:

Como vendemos Scrum para nossa gerência?

Eu sempre fiquei intrigado com esta pergunta. Por que você precisaria vender mais previsibilidade, produtividade, qualidade, valor, controle de riscos, clientes satisfeitos, funcionários engajados e menos desperdício para qualquer pessoa na gerência? No entanto, conversei com Jeff e descobrimos que onde havia fumaça, deve haver fogo.

Passamos o último semestre de 2011 escrevendo o livro. Qualquer gerente, de cima para baixo, pode facilmente ler e ler este livro.

[...]

Vemos isso o tempo todo. (divulgação completa: estou desenvolvendo um aplicativo de gerenciamento de projetos). O problema é que as metodologias ágeis introduzem uma tensão inerente às organizações gerenciadas tradicionalmente. Normalmente, a alta gerência deseja planejar com antecedência. Eles querem planos de três anos; eles querem projetos adequadamente estimados; eles querem poder orçar a contratação de novas pessoas; eles querem se comprometer com marcos significativos quando se trata de parceiros / clientes.

Mas então o departamento de P&D decide que será ágil. Não se trata mais de planejar com antecedência por dois meses antes de escrever o código. Os sprints serão curtos e, além dos sprints, você obtém estimativas de resolução muito baixa das coisas que estão no backlog / roadmap. A P&D percebe que os requisitos mudam com muita freqüência para que a cascata clássica seja eficaz, mas os gerentes de produto desejam uma visão clara, bem pensada e bem orçada da aparência do produto em 12 meses.

O problema, então, é reconciliar os dois. Como eu disse, vemos isso o tempo todo acontecendo com nossos clientes. Nossa solução é, portanto, unificar as ferramentas usadas para fazer sprints e planejar a longo prazo. Ok, agora aqui vem a parte do plug descarado, então fique à vontade para levá-lo com um pouco de sal. Um de nossos recursos exclusivos é o uso de uma interface de usuário com zoom para gerenciar tarefas. Isso significa que é muito fácil detalhar algumas histórias / tarefas do usuário e elaborá-las. (você pode ver como fica aqui ). Na verdade, não existe nenhum conceito de "projeto" em nosso sistema. São todas as tarefas que contêm outras tarefas, vinculadas a outras tarefas (um fractal, na verdade). Isso cria um bom desfoque entre histórias de usuários, tarefas, projetos, épicos etc.

Na prática, o que muitos de nossos usuários que praticam metodologias ágeis fazem é criar um plano telescópico que mescla o roteiro de longo prazo (ou lista de pendências) com o gerenciamento de sprints (ou iterações) de curto prazo. Os gerentes ainda veem um bom roteiro estimado dos principais recursos que aguardam inclusão, e os desenvolvedores simplesmente aumentam o zoom e lidam com as tarefas de trabalho reais. Uma vantagem disso é que ela reduz a quantidade de "pechinchas" que ocorre quando os gerentes revisam o plano de trabalho. Em vez de a equipe de desenvolvimento fornecer apenas estimativas muito aproximadas (ou seja, "4-6 semanas!"), Elas têm a chance de ampliar cada história de usuário em questão e dividi-la em partes menores. Quando você faz isso, de repente há menos espaço para discussões. Você gasta 10 minutos dividindo uma história de usuário de cinco semanas em partes com tamanho de aproximadamente um dia, e de repente o argumento não é "não, você pode fazê-lo mais rapidamente. não, nós não podemos. sim, você pode". mas "eis o que ocorre nesse esforço, incluindo todo o trabalho oculto que a estimativa inicial não considerou. O que você sugere que eliminemos? Garantia de qualidade? Testando? Treinando o novo profissional? Configurando o ambiente de construção?".

Essa abordagem funciona desde que você esteja usando uma ferramenta que permita alterar os planos tão rapidamente quanto os rascunha inicialmente. Qual é a verdadeira razão pela qual as pessoas hoje em dia detestam a cachoeira. A maioria dos sistemas torna extremamente difícil refazer completamente os planos existentes e as pessoas se recusam muito racionalmente a perder tempo com essa atividade.

Ok, eu sinto que isso está se transformando em um discurso de vendas, então vou parar agora. :)