O SCRUM se tornou tão popular que agora eles estão tentando implementá-lo em quase todos os lugares. Nas grandes empresas, às vezes acontece que o SCRUM é implementado para fins de geração de relatórios ou para ser "progressivo" e "moderno". Como resultado, a situação, que parece ser um gerente responsável, estabeleceu a próxima marca de seleção, dizem eles, era necessário implementar a metodologia - implementada, bem-feita, mas em vez de algumas melhorias qualitativas, o chamado "Zombie SCRUM" aparece na saída. É quando a estrutura é formalmente implementada, mas ninguém trabalha normalmente nela. Daí o nome.
Meu nome é Oleg Egorkin, sou um treinador ágil na Rostelecom e, neste post, explicarei por que o zumbi scrum surge em geral, como evitar isso e como garantir que tudo esteja pronto para a empresa lançar uma equipe de scrum.
Abordagens existentes para executar comandos
Às vezes, eles tentam lançar uma equipe de scrum em TI, ou seja, de baixo para cima. É quando os próprios desenvolvedores e os chefes de departamento entendem que é hora, para este produto precisamos de uma cicatriz. A vantagem é que a iniciativa vem das pessoas no assunto. Menos - com essa abordagem, os negócios não estão envolvidos. E se o negócio não estiver envolvido, a própria estrutura organizacional com essa abordagem mudará muito levemente ou (com mais frequência) não mudará. Como resultado, a probabilidade de um scrum se tornar um "scrum de zumbi" é muito alta. Obviamente, não será tal que, no primeiro dia, tudo dê errado como se gostaria. Mas, após cerca de seis meses, as pessoas perceberão que todos os pontos negativos que estavam na inicialização não foram a lugar algum. Daí a frustração que sempre afeta, infelizmente, o produto.
Há uma história inversa - de cima para baixo. Também não é a coisa pela qual lutar. Como exemplo, lembre-se, há vários anos, no início do Agile, 50 novas equipes foram lançadas em um banco verde, sob as instruções das altas autoridades "até o verão" e até o final do ano - 5000. Essa é a própria abordagem do scrum por causa do scrum. O que acontece neste caso? As pessoas correm para fazer recados. Sob a tela, tudo o que não está ferrado começa a remar. O Scrum nesta história nunca é uma melhoria de desenvolvimento e novas metodologias, é apenas uma marca no KPI do gerente. O resultado é um "scrum de zumbi".
E existe uma terceira abordagem - a iniciativa é superior e inferior, de forma codirecional. Tivemos sorte e agora em Rostelecom. Uma coisa em quê. No nível de gerência superior, há assistência constante a todas as abordagens transformacionais nas equipes. Ao mesmo tempo, ninguém estabelece planos "ambiciosos".
Para empresas grandes e muito grandes, isso não é totalmente familiar. Funciona assim: uma vez por mês, dou um treinamento básico de um dia sobre o Agile. Tanto os funcionários de TI quanto as pessoas de negócios participam dos treinamentos, 25 pessoas no grupo. Eu tento falar sobre isso o mais amplamente possível e amplamente. Depois de algum tempo (pode levar de uma semana a vários meses), os colegas, digerindo o conhecimento adquirido, retornam com uma solicitação clara para criar uma equipe de scrum.
Sobre a lista de verificação
Existem dois tipos de solicitações para mim: iniciar uma equipe como parte da transformação de um produto existente ou uma equipe para um novo produto. Para processar esses pedidos, escrevi uma lista de verificação especial, com a ajuda da qual verifico todas as condições necessárias para executar. Se o aplicativo não passar por nenhum ponto e não atender aos requisitos preliminares, não executaremos a equipe. Essa é uma necessidade reconhecida - se você francamente marcar pelo menos um dos pontos e executar a equipe sem ele, ele ainda não trará resultados. Bem, além do fato de que não fraco, desmotiva todos os participantes.
Se alguém de TI me procurar com um aplicativo, peço que ele converse com os negócios e volte a se reunir. Porque os negócios na Agile são um componente-chave. A partir daqui, temos o primeiro item da lista de verificação:
1. A equipe ágil deve querer criar um negócio
Aqui, como acontece com os vampiros - eles não podem simplesmente entrar e entrar na casa, eles devem ser convidados. Com treinadores ágeis, a mesma coisa, no sentido de que uma mudança deve ser solicitada.
As pessoas de negócios e de TI percebem que alguns produtos funcionam em condições difíceis de mercado, entram em contato comigo e dizem - a abordagem precisa ser alterada. E aqui, se você tiver muita sorte, a solicitação chega desde o início, quando ainda não há equipe, mas há uma ideia sob a qual as pessoas podem começar a se reunir. Ao mesmo tempo, todos entendem que uma especificação clara para o produto não pode ser formada, ela mudará dependendo do modelo de negócios e não está claro qual modelo funcionará e o que não.
Em geral, é muito importante que o negócio esteja envolvido.
Também é importante que o condutor desse envolvimento seja algo tangível, e não apenas exagero. Portanto, verifico se os motivos dos negócios se enquadram mais ou menos no seguinte:
- reduzir o tempo de colocação no mercado se esse indicador for muito grande;
- aumentar a eficiência do trabalho em equipe;
- aumentar a capacidade de gerenciamento em face da mudança de prioridades.
Se algum desses três pontos estiver correto, tudo está bem, esse é um sinal claro de que a equipe começa com expectativas adequadas.
2. Deve haver um produto para lançamento
Em primeiro lugar, isso é lógico. É tolice administrar uma equipe de produtos quando você não possui um produto. E não importa o que todos nós começamos a fazer a respeito - de um produto ou serviço.
3. O proprietário do produto deve ter uma visão e um roteiro para o desenvolvimento
Além disso, o roteiro para um ano de antecedência é mínimo, na forma do mais alto nível de entendimento do que geralmente precisa ser feito. Mesmo que uma pessoa tenha de 3 a 5 hipóteses sobre quais modelos de negócios ela aplicará, o que ela deseja explorar. Se eu vir que há um roteiro, continue.
4. Os negócios devem ter dinheiro
Ou seja, o orçamento para uma equipe multifuncional. Como o produto deve ser contratado para uma equipe de tempo integral e os negócios devem estar prontos para pagar por isso no horizonte por cerca de um ano antes. Garanto que tudo isso seja feito, analiso qual centro de responsabilidade financeira está envolvido nisso, para que não haja uma ideia, que haja um desejo de lançar uma equipe, mas que não há dinheiro.
5. Deve ser o proprietário do produto na empresa
O dono. Não os donos. Um dono.
Uma pessoa que é 100% dedicada a este produto em particular. Houve um caso em que dois gerentes vieram e disseram - queremos criar um produto motivacional e educacional (algo interno para os funcionários). Eu digo a eles - ótimo, mas você tem um proprietário de produto? Eles respondem - sim, é claro, um proprietário do produto é para treinamento e outro - para motivação. O produto é motivacional e educacional.
Naquele momento, pedi para pensar e concordar com quem seria o responsável por todo o produto. Isso acabou sendo um assunto muito difícil e a equipe conseguiu ser lançada apenas seis meses depois.
Um produto - um proprietário do produto. Isso é importante.
6. Todos os participantes da equipe de desenvolvimento também devem ser 100% alocados para o produto.
Se alguém da equipe de desenvolvimento trabalha em 50%, 30%, 10% - isso não é imediato. É preciso estar completamente no produto. Mas, ao mesmo tempo, não exijo a presença de equipes localizadas. Em nossas condições, é uma raridade, o Rostelecom é muito grande, temos muitas subsidiárias e afiliadas (afiliadas), onde os desenvolvedores incluídos nas equipes trabalham. E eles podem se espalhar por Moscou, Peter, Krasnodar e outras cidades de nossa imensa pátria. Às vezes, é difícil e demorado reunir rapidamente uma equipe em Moscou, mas geralmente não funciona.
Portanto, continuo em frente, mas existe um requisito contrário - que a equipe se reúna nos primeiros 2 dias quando o treinamento estiver em andamento e, a cada seis meses, para manter contatos pessoais e discutir questões atuais.
7. Método de pagamento do produto
Isso também é importante, além de muito relacionado ao dinheiro. Quando o proprietário do produto tem um orçamento, ele é gasto mediante solicitação. Ou seja, TK está escrito no pedido, é realizada uma avaliação para sua implementação e, em seguida, os fundos no orçamento são alocados para este caso. Isso parece fácil. Mas existem nuances.
Quando você muda para o trabalho personalizado, no final da execução de pedidos deve haver procedimentos para aceitar e transferir o produto para operação. E como o TK já foi aprovado, é extremamente difícil fazer alterações. Todas as edições devem ser renegociadas, aprovadas. Esse é um processo muito complexo e lento, incompatível com uma reação rápida às mudanças.
O que fizemos para não nos enterrarmos nisso e não enlouquecermos?
Você pode trabalhar no Time & Materials quando um contrato for concluído e o tempo de toda a equipe for pago. Ou seja, existe uma equipe que trabalha para o proprietário do produto. Seus serviços são pagos mensalmente ou trimestralmente. Mas em nosso país isso não pode ser feito em sua forma pura, porque há restrições burocráticas.
Portanto, começamos a trabalhar como parte do desenvolvimento personalizado no nível de pedidos trimestrais com a fixação de roteiros (não TK), enquanto o pedido não detalha como o roteiro será implementado. O proprietário do produto tem a flexibilidade de geração de pendências. E quando o trimestre termina, descarregamos da dieta uma lista de tarefas realizadas e, com base nisso, formamos atos assinados e pagos. Acontece o mesmo tempo e material.
E aqui não é necessário cumprir claramente o TK, porque não há TK. Requisitos que não fazem mais sentido após o teste de hipóteses simplesmente não podem ser feitos.
8. A equipe não deve ter nenhum KPI, exceto aqueles associados ao produto
É importante precisamente porque os desenvolvedores são contratados por subsidiárias, onde os KPIs são usados para configurar a reciclagem (é quando o desenvolvedor deve estar constantemente ocupado com alguma coisa). De fato, quase todos os integradores funcionam assim - nas condições de escassez de um projeto (ou projetos concorrentes) do mesmo desenvolvedor, eles pintam em vários projetos. E então, para que a empresa fique no escuro, eles colocam o desenvolvedor no KPI de que ele deve estar sempre pelo menos 85% ocupado. Ou seja, ele realmente possui um determinado KPI, o que o motiva a se enquadrar no número máximo de projetos, a fim de adequar sua disposição aos números necessários.
Felizmente, a equipe de scrum não tem essa necessidade (de fato, é 100%). Garanto que as equipes não tenham outros KPIs além do mercado.
Total
Esta é a minha lista de verificação. Segundo ele, verifico todas as equipes antes de começar e, como temos uma abordagem co-direcional, posso exigir uma mudança nas condições se a equipe não passar por pelo menos um desses pontos. Portanto, o resultado são apenas as equipes que estão prontas para implementar os valores da abordagem ágil.
Se a inscrição para a equipe passar por todos esses pontos, a próxima etapa começa - treinando e lançando a equipe.
Sobre o qual falarei no próximo post =)