Trabalho com / in / for ágil na área de desenvolvimento web há mais de 10 anos. A maioria deles teve que lidar com a estrutura ágil mais popular - scrum (de acordo com o VersionOne ). Quero compartilhar com você as observações e conclusões acumuladas.
Vou começar com uma metáfora, pois às vezes eu tinha que ver a introdução do scrum nesse cenário:
- Antes do scrum : “desenvolvimento” quando bebê - ela é decidida, mas não sabe andar normalmente, mas realmente quer aprender para alcançar a meta.
- Introdução : um professor vem ( treinamentos de scrum, cursos, treinador ágil etc. ) e mostra como andar. O garoto está feliz, ele se move em passos! Top-top-top. Temos sprints - vamos!
- Após a introdução : as partes interessadas dos pacientes dizem: “Ok, nós dirigimos até a meta”, para a qual eles chegam “não empurre a equipe, vamos!”. O desenvolvimento escreve trajetórias interessantes e gosta do processo, mas o objetivo é esquecido.
- Scrum-no : aprimore a pílula da verdade do negócio, o scrum “muda” e permite que o negócio obtenha algum tipo de produto no desenvolvimento. E, infelizmente, a marca de seleção "trabalhamos no scrum" está marcada formalmente, mas o potencial real da equipe de desenvolvimento ainda não foi revelado e eles dizem que "o scrum não é real".
Na minha opinião, isso ocorre devido ao fato de que o scrum é frequentemente implementado “mecanicamente”, sem perceber a essência da estrutura e seus elementos. Eu gostaria de tentar revelar os sintomas do "scrum mecânico"; entender quais são as desvantagens dessa abordagem; entender o que poderia ser melhor com “scrum real com ágil”; e encontre maneiras de ajudar a combater os sintomas do scrum. Dedicarei alguns artigos aqui a isso e ficarei feliz em seus comentários e perguntas.
Para começar, vamos definir o que é um "scrum mecânico". Do meu ponto de vista, é quando todos os papéis, eventos e artefatos do scrum estão formalmente presentes, mas valores e objetivos são esquecidos; quando não houver cultura ágil ( ou seja, um alto grau de conscientização e aceitação de manifesto e princípios ágeis ). Quando não há entendimento ou mesmo uma tentativa de descobrir por que esse artefato é necessário ou qual é o objetivo dos eventos no scrum. É como um robô em um vídeo que sabe torcer cambalhotas, mas quem o chamará de ginasta? Ao implementar o scrum, é importante transmitir à equipe seus objetivos e valores, e não apenas a mecânica. A cultura ágil fortalece o scrum e o torna "real". O Scrum é útil para fornecer valor regularmente e receber feedback imediato. Scrum é sobre velocidade e desenvolvimento de produtos. Parece banal em teoria? Vamos tentar descobrir como trabalhar no scrum e não perder a cultura e os valores scile ao longo do caminho.
Ao analisar os elementos scrum no ScrumGuide, as funções são uma das primeiras a serem analisadas , e faremos o mesmo. Porque Como resultou em muito material, para dar a oportunidade de realizá-lo, ele é dividido em três partes ( Parte 2 , Parte 3 ). Vamos começar a análise com o Product Owner.
Dono do produto - Dono do produto (PO):
O proprietário do produto é a pessoa responsável pelo produto, ele "possui" o backlog do produto. A principal ferramenta do PO é a visão do desenvolvimento do produto, e a principal tarefa é maximizar o valor do produto produzido pela equipe. Tudo parece simples: “Se você é corajoso, hábil e hábil ...”, mas há nuances. Eles não nos ensinam na PO, mas ensinam na PM (gerente de projeto), e geralmente a PM se torna PO, acreditando que isso é apenas uma mudança de nome, e você pode manter as antigas abordagens de trabalho. Mas o ágil não funciona assim. Como é necessário?
Interação entre pedido e produto, Backlog
Sintoma : O PO não é responsável pela composição do backlog, apenas trabalha com as histórias recebidas de outros participantes no processo. Ou o PO não é responsável por priorizar os elementos da lista de pendências. Seu trabalho é levar o backlog ao padrão aceito pela equipe e ele não determina o conteúdo e as prioridades do que a equipe fará.
O que é ruim : se um pedido não tiver coragem ou capacidade de criar um produto ( formar uma lista de pedidos pendentes, priorizar, realizar experimentos etc. ), este não é um pedido, mas algum outro tipo de atividade. E sem PO scrum, não scrum. Sem formar um Backlog, a PO não pode ser responsável pelo produto. Se o PO não for responsável pela lista de pendências, a adoção de decisões do produto requer comunicações adicionais - esse é um tempo extra gasto, o que afeta negativamente a velocidade da equipe.
Como tratar : você precisa dar à PO o direito exclusivo de tomar decisões sobre o produto e a responsabilidade pela composição do backlog. Se um tomador de decisão não é uma ordem estabelecida, é difícil mudar a situação da noite para o dia. Quando PO é um proxy, então
- Ou removemos da equação e tornamos o OP realmente quem é responsável pela composição e priorização do backlog. Tanto a equipe de desenvolvimento quanto a equipe especial de descoberta de produtos podem ajudar os POs a trabalhar no backlog, mas a responsabilidade pela composição e qualidade do backlog deve permanecer com apenas uma pessoa - PO.
- Ou gradualmente aprendemos / permitimos / nos forçamos a assumir a responsabilidade e a tomar decisões (a composição dos elementos da lista de pendências, a prioridade dos elementos, etc. ) da OP atual. As iterações são importantes: consolidando o sucesso, obtendo feedback.
Sintoma : a OP não tem uma visão para o desenvolvimento de produtos, não possui uma estratégia global, não há objetivo de onde trazer o produto e por quê.
O que é ruim : A principal força do PO é a visão do produto, entendendo por que e para quem ele é criado. Com essa visão, ele pode motivar e "infectar" as pessoas ao seu redor. Se não houver visão, é improvável que o produto seja necessário e bom. A equipe não será "cobrada" com o resultado.
Como tratar : PO é importante primeiro formular uma visão do produto. Ele deve ser capaz de dizer em formato de tom de elevador que tipo de coisa legal ele faz, para quê e para quem. Um dos valores ágeis é a transparência. Ao visualizar vários artefatos de desenvolvimento de produtos, estamos trabalhando na transparência. O PO pode articular sua visão e publicá-la na frente da equipe. É melhor que o trabalho na formulação da inclinação e da visão do elevador seja feito com alguma frequência - como outros eventos de scrum ( planejou um novo feedback coletado de iteração - realizado - ).
Sintoma : o pedido de compra não elabora os elementos da lista de pendências, não os traz para os acordos adotados pela equipe, não atualiza os elementos da lista de pendências, não os limpa, não realiza a limpeza dos pedidos pendentes .
O que é ruim : se atualmente o PO não prestar atenção suficiente ao backlog regularmente, ele ainda precisará fazer isso (os sprints precisam ser coletados ), mas será mais estressante e dispendioso ( por exemplo: limpeza coletiva do backlog no planejamento de sprint ). A sobrecarga da comunicação será compensada com o tempo alocado para o desenvolvimento. O PO começará a perder a confiança da equipe: não investe no backlog - a equipe não investe no incremento. A lista de pendências incorreta / irrelevante reduz a transparência de todas as partes interessadas. E scrum sem transparência não é scrum.
Como tratar : Antes da PO, você precisa transmitir a importância de trabalhar no backlog - artigos, livros, treinamentos etc. Precisamos desenvolver regras / regulamentos para conduzir o PBR (Product Backlog Refinement) para que essas reuniões sejam úteis e eficazes, realizando uma mini-retrospectiva após o PBR. Em algumas iterações, você pode melhorar qualitativamente esse evento. A equipe precisa melhorar o mecanismo para conduzir a RBR, alcançando a sinergia máxima entre o OP e a equipe de desenvolvimento. A lista de pendências precisa de limpeza regular. Para obter as informações mais recentes, além de adicionar novas histórias ao backlog, lembre-se de limpar as histórias que perderam relevância. O backlog deve conter elementos que sejam compreensíveis para a equipe e elaborados ( dentro da estrutura dos acordos de uma equipe específica ) para 2-3 sprints; um backlog mais aprofundado pode perder relevância. Em geral, a lista de pendências deve conter o Roteiro por pelo menos um ano, para que todas as partes interessadas sintam que o produto tem futuro. Manter uma lista de pendências interrompida por incrementos aproximados ajudará a equipe a pensar antecipadamente sobre as metas do sprint .
Sintoma : a PO trabalha em vários produtos não relacionados ou com várias equipes. Como opção - além do PO principal, ele também desempenha um papel diferente no processo de scrum (desenvolvedor ou SM).
O que é ruim : Ser um PO não é uma tarefa fácil, exige grandes retornos. Se o papel da OP for combinado com outras atividades, com um alto grau de probabilidade, isso afetará gravemente a qualidade do resultado. OPs experientes e maduras podem executar simultaneamente vários produtos e trabalhar com várias equipes se esses produtos estiverem "relacionados" ou fizerem parte de um grande produto com funcionalidade próxima. Provavelmente, apenas pessoas muito, muito únicas, podem, simultaneamente, criar um editor gráfico para dispositivos móveis e um simulador de vôo do exército. Para ser eficaz, você deve se concentrar em um objetivo antes de manipular vários.
Como tratar : A OP deve analisar criticamente seus produtos: quão bem desenvolvida e formulada a visão? Como as equipes entendem e aceitam essa visão? Quão bem desenvolvido é o backlog? É transparente para todos os envolvidos? Existe um roteiro do produto, é claro para todos? A equipe entende o que os próximos 2-3 sprints farão? Quão bem conhecido é o usuário e o mercado? Qual é a qualidade da interação com a equipe de desenvolvimento? Se em algumas dessas questões houver espaço para melhoria da qualidade, você deve deixar um produto e se concentrar nele.
PO e interação da equipe
Sintoma : a diretiva PO controla a equipe, na verdade trabalhando no esquema de MP clássico. PO toma todas as decisões, mesmo as menores, a equipe corre para ele em qualquer questão.
O que é ruim : se a OP está envolvida em microgerenciamento dentro da equipe, participa ativamente do desenvolvimento e, por um lado, desmotiva a equipe e impede que ela se desenvolva ( não há auto-organização, porque a responsabilidade pelas decisões locais permanece com a OP ), por outro, é ruim para o produto, porque os esforços da OP são direcionados dentro do processo, e o produto pode ser deixado sem sua atenção.
Como tratar : O PO precisa matar o PM em si mesmo, tentar abordagens de gerenciamento não diretivas e parar de perceber as pessoas como um recurso. Se um esquema de gerenciamento de diretiva for construído entre o OP e a equipe de desenvolvimento, vale a pena envolver um facilitador externo ou interno que possa ajustar a interação. Os limites de responsabilidade entre o OP e a equipe de desenvolvimento precisam ser claramente definidos - isso é transparência. Deve haver uma relação de confiança entre o OP e a equipe: a equipe confia na maior parte do pedido e em suas soluções de produtos, e o pedido de confiança na equipe e nas decisões que a equipe toma para implementar os elementos da lista de pendências. Todo mundo entende que o trabalho está sendo feito para um único propósito. Uma das ferramentas possíveis para a OP pode ser sua equipe de "produtos", que inclui analistas. Quando as hipóteses são baseadas em números e dados, elas são mais credíveis. O principal para o PO é não esquecer de compartilhar esses dados com a equipe de desenvolvimento. Se a equipe não for independente, o OP precisará aprender a delegar. Em seguida, a equipe será forçada a tomar decisões, como resultado da responsabilidade, e gradualmente se tornará uma equipe de scrum.
Sintoma : PO e a equipe de desenvolvimento conflitam regularmente, há um confronto constante, não há entendimento mútuo.
O que é ruim : o PO e a tripulação navegam no mesmo barco; se não forem estabelecidas comunicações efetivas entre eles, é improvável que esse barco possa navegar para longe. Muita energia será gasta no estabelecimento de interação, e não no desenvolvimento de produtos. O objetivo do OP e da equipe é o mesmo, o que significa que não deve haver conflitos regulares.
Como tratar : Precisamos de um facilitador experiente que possa identificar a essência do conflito, removê-lo e construir uma relação de trabalho. Se todos os esforços não levam ao entendimento mútuo, talvez valha a pena mudar de tandem.
Sintoma : a PO quase não se comunica com a equipe. Por exemplo, ele está disponível apenas como parte de reuniões obrigatórias (planejamento, revisão de sprint).
O que é ruim : a equipe cria um novo produto complexo (o Scrum é uma estrutura para desenvolver, fornecer e manter produtos complexos ) . Portanto, ele trabalha em condições de grande incerteza. Para oferecer o máximo valor, eles precisam de informações que, na maioria dos casos, apenas a OP possui ( é o trabalho dele ). Na ausência de informações, suposições e decisões incorretas podem ser tomadas, como resultado, um tempo valioso será perdido em sua correção.
Como decidir : o pedido deve estar disponível para a equipe, mas a equipe não deve abusar dele; caso contrário, o tempo do pedido será gasto apenas em perguntas ad hoc. Deve-se elaborar um formato de interação que seja confortável para todos, em que a equipe receba oportunamente da OP as informações e decisões necessárias que a equipe realmente não pode tomar por conta própria. Você pode telefonar para retrospectivas de pedidos com certa regularidade e discutir a questão da frequência, ferramentas e formato de comunicação.
Sintoma : a OP não inculca ou promove uma cultura de feedback da equipe. Ou o PO fornece feedback unidirecional, filtrando elogios ou críticas.
Por que é ruim : quando o OP não fornece feedback honesto e regular à equipe, isso desmotiva a equipe. Sem sincronização de expectativas e resultados. A equipe não sente cumplicidade, na verdade eles não são os criadores do produto, eles simplesmente desempenham sua função. “A equipe fornece regularmente incrementos. A equipe recebe regularmente um feedback honesto sobre seu trabalho ”- parece ser um acordo justo.
Como tratar : O PO, é claro, não deve cobrar à equipe toda a quantidade de informações com as quais ele trabalha, tudo o que recebe de usuários e analistas. Ele deve agregar e emitir informações que já são importantes e compreensíveis para a equipe. É bom criar formatos diferentes para feedback, e não apenas com base em números secos ( por exemplo: testes ao vivo, entrevistas etc. ). A própria equipe deve lembrar ao PO a necessidade de feedback: faça perguntas, crie um processo regular para receber feedback. Se você tornar o PO o "proprietário" do evento de revisão de sprint e confundir com o fato de que a equipe precisa de feedback, ele lembrará pelo menos o trabalho do feedback e poderá levar a uma abordagem mais criativa da organização.
Interação entre OP e usuários do mercado
Sintoma : o PO não conhece o usuário "his"; o produto vê um conjunto de recursos. O pedido ignora solicitações e informações de usuários existentes. Não se comunica com usuários ativos.
Por que é ruim : primeiro, o produto é criado para o usuário que tem ( talvez ainda não o saiba ainda ) a necessidade satisfeita pelo produto. E se você não conhece e entende o usuário, é impossível "assumir a responsabilidade de atingir o valor máximo do produto", conforme exigido pelo guia de scrum.
Como tratar : Existem muitas ferramentas diferentes para a realização de pesquisas qualitativas, por exemplo, entrevistas detalhadas, um retrato de um usuário, um mapa da jornada do cliente , ferramentas para coletar análises qualitativas (versus quantitativas) , etc. etc. Você precisa experimentar várias ferramentas e deixar útil / trabalhando para o seu produto. A maioria dessas ferramentas na saída tem uma visualização do resultado, vale a pena colocá-las na frente da equipe para aumentar a transparência. Vale a pena atualizar esses artefatos de tempos em tempos. Você pode organizar uma equipe de descoberta de produtos para ajudá-lo a realizar pesquisas de qualidade. Se o PO conseguir estabelecer interação com o usuário, ele poderá usar esse contato, por exemplo, para revisão do sprint: dando ao usuário um novo incremento e a equipe examinará como o usuário lidará com a tarefa, a ajuda na solução que eles estabeleceram no incremento.
Sintoma : O PO não estuda o mercado / concorrentes.
O que é ruim : o produto vive como se estivesse no vácuo e está divorciado da realidade, você precisa ser um visionário para criar um produto valioso nessas condições.
Como tratar : Existem várias práticas para os proprietários de produtos, como estudar e criar mercados, vale a pena experimentar várias delas e deixar outras benéficas. Nesta atividade, os OPs podem ser ajudados por analistas ou uma equipe. É útil procurar " oceanos azuis " de tempos em tempos. E, claro, você deve inspirar-se em treinamentos, reuniões de comida e conferências.
Conclusão
Uma análise das funções restantes aparecerá nas seguintes partes. Agora vamos ver como essas informações podem ser úteis para você. Examinamos alguns dos possíveis sintomas, dizendo que algo está errado no scrum e opções para mudar a situação. Se você quiser, uma lista de verificação no final:
- Ao ler quase todos os itens, você se reconheceu ( sua equipe / organização ), ou seja, você tem um scrum com entendimento não canônico. Então vale a pena fazer perguntas: você precisa de scrum? Por que você precisa do scrum? Que tarefas você define para ele? A cultura corporativa está pronta para valores e princípios ágeis? Se você tiver respostas e entender por que o scrum é necessário, e realmente apostar nele, prossiga para a segunda opção. Caso contrário, pare de praticar auto-engano.
- Lendo alguns pontos, você pensou que não era sobre você. Alguns pontos o levaram a raciocinar e você se lembrou da sua situação. Nesse caso, selecione os itens que podem ser aplicáveis à sua situação. Imprima-os na forma de cartões. Discuta os sintomas com a equipe: eles são justos para você? Discuta os riscos, você concorda com eles ou talvez veja consequências mais perigosas dos sintomas. Em seguida, pegue o cartão que mais preocupa a equipe, o sintoma mais perigoso no momento. Considere a solução proposta, é ideal para você? Coletivamente, invente como você pode melhorar a situação, como aliviar o sintoma. E aja! Depois de lidar com um sintoma, prossiga para o próximo, retornando periodicamente à revisão geral, para garantir que os resultados que você já alcançou não tenham caído.
- Se você leu tudo e não reconheceu suas realidades nessas situações, temos tudo certo. Existem realmente essas organizações? Vocês são grandes companheiros, não deixe de compartilhar nos comentários como você conseguiu isso!
PS Espero que o artigo forneça uma ferramenta de trabalho para as equipes scrum se auto-aperfeiçoarem.
PPS Muito obrigado pela ilustração Sai Kin
UPD Parte 2 e Parte 3 .