Na primeira parte, analisamos sintomas alarmantes e possíveis maneiras de "tratar" o Product Owner em um scrum "mecânico". Continuamos a análise de função e o próximo da fila é a equipe.
No entanto, eles sabem o mantra de que a equipe deve ser auto-organizada e multifuncional, parece a parte mais simples do scrum: pegamos pessoas com as competências necessárias, dizemos a elas: “você é um time” e voou! Mas, na realidade, tudo é um pouco mais complicado.
Auto-organização
Sintoma : Há uma hierarquia explícita (envio de diretiva) fora ou pior dentro de uma equipe. I.e. de fato, um desenvolvedor de produto pode ter uma tarefa que não esteja diretamente relacionada às atividades da equipe. Ou, dentro da equipe, as pessoas não são livres para escolher um trabalho para atingir a meta do sprint, mas recebem tarefas do "líder".
O que é ruim :
Quaisquer limites - limit @ CEP
Quando uma pessoa é pressionada pela descrição do trabalho, hierarquia de submissão, etc., isso impede que ela seja revelada. A força da equipe scrum está em abrir oportunidades para as pessoas. Há uma tarefa, tenha coragem e seja responsável por sua implementação. Uma pessoa deve decidir por si mesma o que fará para alcançar o objetivo do sprint. Se eles lhe disserem o que fazer, então isso não é auto-organização e nem scrum.
Como tratar : para as pessoas da equipe, todas as descrições e hierarquias de trabalho são canceladas, a estrutura tende a ser plana.
Todos os que fazem parte da equipe são os
desenvolvedores do produto (o
guia scrum não permite outras funções ). Existe apenas liderança situacional, e as pessoas decidem como se sentem confortáveis em trabalhar para serem eficazes. Obviamente, existem regras gerais do jogo na empresa, a equipe não as viola de maneira alguma (
embora possa afetar a mudança no nível da empresa ), mas é responsável por todas as coisas internas. Se houver sérios obstáculos ao levantamento de restrições para desenvolvedores, vale a pena encaminhar o problema para aqueles que decidiram implementar a transformação scrum e ágil. Você pode tentar executar uma estrutura plana, como um experimento para vários sprints, e depois realizar uma extensa retrospectiva, na qual todas as partes interessadas discutem os resultados do experimento.
Sintoma : As pessoas, além de trabalharem em equipe, devem desempenhar outras funções funcionais na empresa. Por exemplo: 50% do tempo executa as tarefas da equipe, 50% - as tarefas do departamento (desenvolvimento, teste, etc.).
Que ruim : um dos valores no scrum é o foco. A equipe se concentra no objetivo do sprint e se move em direção a ele. Se, além de trabalhar em equipe, uma pessoa tiver que fazer outra coisa, o foco será perdido. Como resultado, o resultado será pior. É difícil manter o espírito de equipe nessas condições.
Como tratar : Precisamos garantir que as pessoas da equipe trabalhem SOMENTE nesta equipe. Para fazer isso, vale a pena entender a natureza do trabalho que caiu sobre os desenvolvedores da equipe de fora e encontrar maneiras de fazê-lo sem quebrar o scrum. Certamente este trabalho é necessário para a empresa; portanto, dependendo das especificidades do trabalho, você pode:
- coloque o trabalho na lista de pendências da equipe e será feito de acordo com um único fluxo de trabalho.
- ou transfira-o para outros funcionários fora da equipe. Por exemplo: nem toda a empresa trabalha no scrum, e você precisa fazer algum trabalho regular em um horário específico, então esse trabalho não é mais adequado para os funcionários do scrum.
- ou uma equipe especial pode ser criada e um produto selecionado que coletará todo o trabalho desse tipo.
- ou, se for uma função única que é executada por uma pessoa para várias equipes devido à falta de especialistas. Vale a pena tirar a pessoa de todas as equipes e criar outro processo para ele que não interrompa o restante do scrum ( por exemplo: uma fila de tarefas priorizada ), até que especialistas nessas equipes de scrum sejam encontrados.
Funcionalidade cruzada
Sintoma : as pessoas da equipe realizam apenas um determinado trabalho, há uma clara especialização. Pior ainda quando ainda está coberto por deveres, regulamentos e outras burocracias oficiais. A ausência (férias, licença médica, etc.) de um membro da equipe reduz a funcionalidade da equipe. Oi, fator de ônibus .
O que é ruim : se uma equipe depende das competências de um de seus membros, é instável a mudanças. É difícil construir comunicação com ela, porque você precisa entender sua funcionalidade atual e lembrar dos riscos associados a esse nível de tolerância a falhas. A estreita especialização dos desenvolvedores complica muito o trabalho organizacional da equipe: ao planejar, você precisa pensar muito sobre quem fará o quê; nem toda tarefa precisa de proporções predeterminadas de competências de equipe; portanto, é difícil montar um sprint equilibrado; nesse esquema, um "pescoço estreito" necessariamente surge, reduzindo a velocidade geral da equipe.
O que fazer : É necessário promover e apoiar habilidades em forma de t . Para manter a equipe flexível, é importante que uma função ou conhecimento específico não esteja concentrado em uma pessoa. É necessário estimular e incentivar o desenvolvimento contínuo. É importante garantir que a equipe melhore, procurando maneiras de melhorar os processos. Como opções de desenvolvimento em forma de t: realização de seminários internos, onde os membros da equipe compartilham conhecimento entre si; adotar a regra de execução de tarefas não essenciais a cada sprint de cada membro da equipe; par trabalhar em tarefas, etc. Você pode estimular artificialmente uma equipe “desligando” seus membros por um tempo: férias, seminários, treinamentos, viagens de negócios, etc.
Sintoma : na cadeia de valor, a equipe é responsável (influencia) por apenas uma pequena parte dela e, como resultado, a equipe não pode emitir incrementos por conta própria.
Que ruim : se a equipe tem pouco efeito na entrega do incremento ( lançamento do produto ), o scrum também perde sua essência: os lançamentos ocorrem com um atraso, o feedback ocorre com um atraso ainda maior. Em geral, não há ritmo e, portanto, velocidade. Sem velocidade - sem flexibilidade. Essa equipe não sente sua propriedade, é apenas um parafuso funcional em um carro grande. A funcionalidade da equipe deve ser suficiente para fechar a maior parte da cadeia de valor; caso contrário, a equipe simplesmente não fornecerá valor, mas simplesmente processará um tipo de “peça de trabalho” em outro e o transferirá ainda mais.
Ilustramos isso com um exemplo da web. Onde simplificada, a criação de um novo recurso inclui as seguintes etapas:
- Desenvolvimento de protótipo de UI / UX
- desenvolvimento de design
- criando uma API RESTful
- Criação de SPA
- escrevendo testes de integração
- montagem e fundição no ambiente de combate
Para estes trabalhos, são necessárias várias competências. Um exemplo de uma divisão malsucedida em equipes: para separar a
equipe A da UI / UX, designers e desenvolvimento de front-end, eles preparam seu incremento na forma de SPA; mas eles dependem de quando o back-end preparará a API para que a nova funcionalidade funcione; aguarde o controle de qualidade verificar tudo integralmente e escrever testes; e eles ainda esperam que o DevOps jogue tudo na batalha. É difícil para uma
equipe A ser responsável pela liberação e entrega de valor, apenas corta o "espaço em branco" - SPA.
Como tratar : Determinamos quais competências a equipe não possui para fornecer o incremento. Damos à equipe essas competências treinando os membros existentes ou adicionando novos jogadores à equipe. Porque encontrar / ensinar as pessoas não é a tarefa mais fácil e rápida, então você pode estabelecer comunicação com as equipes / departamentos vizinhos, explicando os valores de scrum e concordando com elas sobre regras / regras de interação especiais sob as quais elas não quebram o scrum para sua equipe. Vale destacar o processo de expansão da funcionalidade da equipe: após a primeira retrospectiva e identificação das competências ausentes, é possível imprimi-las e colocá-las na frente da equipe. Quando uma equipe lida com a falta de competência (
aprendida; um novo membro da equipe; estabelece uma comunicação eficaz com outra equipe etc. ), então penduramos uma solução em cima da competência anteriormente ausente. Com o tempo, a equipe deve se esforçar para expandir sua funcionalidade para cobrir completamente a cadeia de valor.
Equipe e produto
Sintoma : existe uma equipe, mas nenhum produto. Nenhum pedido, nenhum atraso. É só que as pessoas realizam tarefas que vêm de diferentes direções.
Do que ruim : Isso não é scrum. Quando um produto não é atribuído a uma equipe, é improvável que a equipe “se queime” com o trabalho. Quando existe um objetivo global ( visão / estratégia / roteiro do desenvolvimento de produtos ), você deseja ir para ele. Você faz o trabalho, obtém feedback, reflete e dá o próximo passo. Sem um senso de propriedade, você corre o risco de estar em uma rotina: você realmente não precisa de feedback, a equipe se torna apenas uma ferramenta para processar o TK em funcionalidade.
Como tratar : a equipe deve ter seu próprio produto com carteira de pedidos e pedidos, o que pode inflamar a equipe com o produto e carregá-lo junto - essa é a essência. Precisa entender por que você precisa do scrum? Entendeu de onde vem a equipe? Entendeu se existe um "produto" nesse fluxo? Escolha entre as equipes de “clientes” uma e torne-a proprietária do produto , dando-lhe o direito exclusivo de responder pela lista de pendências. Pode ser necessário dividir a equipe em uma equipe de scrum que trabalha com um PO ( pode ser uma equipe de scrum "piloto" ) e uma segunda equipe, enquanto trabalha da mesma maneira com o restante dos "clientes". Fornecendo a máxima transparência dos processos e resultados que ocorrem na nova equipe de scrum, você pode estabelecer as bases para uma maior distribuição de scrum e ágil na organização.
Sintoma : A equipe não tem influência sobre o componente do produto: não decide "como fazer?". A equipe apenas diz "o que fazer?" TK chega à entrada e a equipe é considerada como uma unidade funcional.
Que ruim : Esta é uma opção muito perigosa se a empresa realmente proclamar os valores de ágil e scrum. Geralmente, isso implica que todos os funcionários são profissionais legais que podem resolver quaisquer problemas que não tenham medo de tomar decisões e assumir responsabilidades. Mas se eles não têm permissão para tomar decisões sobre produtos, toda a liberdade criativa da equipe geralmente se espalha do produto para a tecnologia. Como a equipe não tem permissão para decidir como facilitar a vida do usuário, o mundo é melhor e o produto é mais útil; então a equipe começa a desenvolver uma base de código, experimentar novas tecnologias / ferramentas / estruturas etc. Há um conflito de interesses entre o OP e a equipe, a equipe começa a vender "refatoração", "otimizações", "balas de prata" na forma de uma nova pilha, etc. E isso é afetado principalmente pelo usuário e pelo produto. No processo de mudança dos modelos de gerenciamento de diretivas para o ágil, existe o risco de ficar preso ao entendimento da equipe como uma unidade funcional (a equipe não havia tomado uma decisão antes ). Isso é preocupante porque matamos a iniciativa da equipe ou chegamos a uma situação em que a equipe está mais interessada em tecnologia do que no produto.
Como tratar : você precisa identificar a causa da desconfiança da equipe ou sua indecisão: por que a equipe não está procurando uma solução, mas trabalha apenas com uma tarefa técnica detalhada? Tendo encontrado a causa, você pode eliminá-la gradualmente. Por exemplo:
- A equipe não possui competências ou experiência. : Alguém está trabalhando em soluções e escrevendo TK, você pode adicionar essa pessoa à equipe ou deixá-la trabalhar em algumas tarefas junto com a equipe, transferindo parte de suas habilidades e experiência para a equipe. Então, gradualmente, a equipe aprenderá e se acostumará a resolver problemas do produto.
- A gerência teme que a equipe cometa um erro. : Esse é o medo da pedra angular na transição para o ágil, mas sem superá-lo, você não será capaz de obter toda a força da equipe de scrum. A equipe está fadada a cometer um erro, porque todos estão enganados. Mas um erro é uma fonte de experiência e habilidade. É mais útil quando uma equipe comete um erro, porque assim o decidiu, e não por causa de um TK externo incorreto. Scrum é ritmo: rapidamente tomou a decisão de testar uma hipótese; Feedback recebido percebeu que eles seguiram o caminho errado; jogou fora a decisão. O custo de um erro é bastante reduzido ( passou um sprint, não um quarto / ano / seu período de lançamento ), o que permite que você evite o medo do erro.
Sintoma : Os membros da equipe não têm acesso livre aos artefatos da equipe. Por exemplo, nem todo mundo vê um sprint ou backlog geral, ou há dificuldades com a possibilidade de atualizar seu status.
O que é ruim : Scrum é baseado em transparência, artefatos ajudam a aumentar a transparência. Se os membros da equipe tiverem dificuldade em trabalhar com esses artefatos, os próprios membros da equipe não terão transparência no trabalho em equipe e, para outras partes interessadas, a situação será ainda pior: não está claro quem está fazendo o que e por quê. Não está claro onde a equipe está a caminho do gol.
Como tratar : É necessário determinar os formatos dos artefatos de scrum em uma equipe e criá-los ( você pode dedicar essa retrospectiva ) e, em seguida, colocá-los para que a equipe fique à vontade trabalhando com eles. É ótimo se você pode criar um espaço separado para a equipe, as condições sob as quais a equipe trabalhará lado a lado (ombro a ombro) ao mesmo tempo. Isso reduzirá a sobrecarga de comunicação. E no espaço comum é fácil visualizar tudo ( flipcharts, adesivos, marcadores são as ferramentas favoritas do Agile ), o principal é que é conveniente, não estressante para a equipe. Os artefatos devem ajudar, e não interferir no trabalho da equipe, não burocratizá-lo. A interação verbal é boa para o trabalho em equipe. Se houver dificuldades com a organização do trabalho local da equipe ( por exemplo, distribuído ou remoto ), você precisará maximizar o efeito do trabalho em equipe e da unidade. Por exemplo, canais de presença de vídeo, scrum boards interativos na visão direta de cada membro da equipe etc.
Conclusão
Na próxima parte, continuamos a considerar os papéis do scrum e, finalmente, chegamos ao scrum master. Lembre brevemente o que fazer com os sintomas:
- Selecione os sintomas que se aplicam à sua situação.
- Destes, escolha o mais nítido.
- Torne-se consciente dessa dor.
- Você cria uma solução de equipe ( você pode considerar os casos do artigo como ponto de partida ).
- Implemente sua decisão.
- Vá para o passo 1.
Obrigado pela leitura, gostaria de ver os "sintomas" conhecidos por você nos comentários.
Obrigado a Sai Kin pela ilustração.
A próxima parte sobre o Scrum Wizard