9 vantagens de usar Scrum em seus projetos

700x395xteam.jpg.pagespeed.ic.f9By3MZ2aODesde 13 de novembro de 2001 pra cá, quando o Manifesto Ágil foi assinado por 17 das mentes mais brilhantes da indústria de software à época, que o hype em torno de métodos ágeis só cresce. Em parte pelo demérito dos métodos tradicionais de desenvolvimento que priorizam muitas vezes a burocracia em detrimento do resultado, mas gosto de pensar que a principal razão é porque Scrum e cia realmente funcionam.

No entanto, para quem é novo nesse mundo ágil e apenas ouviu falar em buzzwords (e bizarrices) como planejamento com Poker, reuniões em pé e equipes sem chefe, fica difícil entender porque alguém adotaria tais excentricidades no seu ambiente de trabalho.

Por que eu realmente devo utilizar métodos ágeis em meu ambiente de trabalho?

Por que usar Scrum?

Quais as vantagens?

No post de hoje falarei de 9 vantagens inerentes à aplicação de Scrum no seu time, embora os métodos ágeis compartilhem de praticamente as mesmas premissas.

#1 – Adaptabilidade

O controle de processos empíricos e a entrega iterativa fazem com que os projetos sejam adaptáveis e abertos à incorporação de mudanças.

Enquanto os métodos tradicionais de desenvolvimento, em especial o cascata, valorizam análise extensa e definições rígidas de requisitos, visando “segurança” (ou a falsa sensação dela), o Scrum abraça a imprevisibilidade que um projeto longo possui ao inserir mais resiliência em projetos.

Isso não é apenas algo etéreo, está lá, documentado no Scrum Guide como o terceiro pilar do framework!

bruce-lee

Como diria Bruce Lee, abrace a mudança, a imprevisibilidade, seja como a água, meu amigo! Não apenas o chinês está muito certo como outro dito oriental, desde vez japonês, do Karatê Goju-ryu, fala sobre resiliência quando cita que os pinheiros que duram mais tempo são aqueles que “aprendem” a se vergar nas tempestades. De nada adianta uma árvore imponente se ela for rígida e “imóvel”, sempre haverá uma tempestade forte o bastante para quebrá-la, e o mesmo acontece com projetos.

Como diria a equipe dev do Spotify, construa princípios sólidos e metas claras, mas adapte a execução conforme a necessidade. Isso é ser ágil.

#2 – Transparência

Todos as fontes de informações, tais como, o quadro de tarefas (Kanban) e o gráfico Burndown, são compartilhadas gerando um ambiente de trabalho aberto.

Na administração tradicional a Gestão à Vista não é algo novo e comprovadamente vantajoso para as organizações. Isso porque permite que todos vejam o que está acontecendo e consigam tomar atitudes em relação à isso.

Scrum fala de adaptação, mas não há como se adaptar ao que não se consegue ver, e por isso que o primeiro pilar da metodologia é a transparência. Tudo começa com ela.

Sem transparência não há:

  • inspeção adequada
  • adaptação
  • engajamento
  • confiança
  • evolução do time
  • sucesso no projeto

Gerentes temem expor informações que possam gerar medos e conflitos no time. Ao fazerem isso, impedem que o time amadureça e realmente “abrace a causa”. John Maxwell diz que não tem como o time saber se está ganhando se ele não pode ver o placar!

John-Maxwell-Quotes-3-1024x678

Tem um ditado que diz também o seguinte (adoro eles!): se você não sabe para onde está indo, qualquer lugar serve. Um projeto não fracassa se não havia um objetivo para o mesmo, certo?!

#3 – Feedback Contínuo

O feedback contínuo é fornecido através de processos denominados como a Reunião Diária e a Sprint Review.

O Scrum fornece diversos mecanismos de feedback, o que garante o segundo pilar do framework: inspeção.

Feedback contínuo não é dar tapinhas nas costas na reunião de final de ano da empresa. Feedback contínuo tem a ver com transparência, pois o time precisa saber se suas ações estão gerando resultado. Você precisa saber se está no caminho certo. O seu colega precisa saber como pode lhe ajudar e você precisa saber se ele precisa de ajuda também.

Inspeção leva à adaptação, em um ciclo virtuoso que gera a melhoria contínua.

4# – Melhoria Contínua

As entregas melhoram progressivamente, Sprint por Sprint, através do processo de refinamento do Backlog do Produto e do processo em si.

Na metodologia de inovação em startups denominada Lean Startup, existe um ciclo chamado construir-medir-aprender (build-measure-learn no original) que trabalha da seguinte maneira:

  1. Você constrói um incremento de produto
  2. Você mede o desempenho dele
  3. Você aprende com os erros e refina-o
  4. Volte ao passo 1

E assim o é também no Scrum.

O framework é enxuto, apenas 19 páginas. Talvez não cubra nem sequer 10% da “ciência” da gestão de projetos. Mas os seus princípios fundamentais te ajudam a pensar de uma maneira diferente, com o mindset correto. Ele próprio te ensina que a inspeção vai te levar inerentemente ao aprendizado (adaptação) e com isso à melhoria contínua dos processos e produtos.

Esqueça aquela ideia que alguns métodos pregam que você deve apenas confiar cegamente em um livro e seus problemas estarão resolvidos!

#5 – Entrega Contínua de Valor

Os processos iterativos permitem a entrega contínua de valor tão frequente quanto exigido pelo cliente.

Tenha em mente que ninguém compra software. Ninguém.

“Como assim?” você deve estar se perguntando agora… Sim, as empresas que usam softwares nunca quiseram ter aqueles programas instalados em seus servidores ou nas máquinas dos funcionários. Eles sempre quiseram soluções para seus problemas, sempre quiseram ser mais produtivas, mais assertivas, mais competitivas, etc.

Só quem gosta de software é programador. Cliente gosta de solução que entrega valor. Se o seu time não entrega valor, ele não vai ir muito longe. E se ele demora demais para entregar valor, também não.

A chave aqui é entregar valor continuamente, em pequenas porções mas frequentes, deixando sempre o cliente satisfeito e com um “gostinho de quero mais”. A cada iteração do Scrum (sprint), um incremento de produto é entregue ao cliente, um que gera valor ao mesmo. É assim que tem que ser em todos os projetos.

Você nunca terá como entregar tudo o que o cliente quer, no prazo que ele quer e dentro do orçamento dele. Isso não existe!

Mas o processo de criar e priorizar um Backlog de Produto garante que as exigências de maior valor ao cliente sejam atendidas primeiramente e que o valor que ele tanto busca (não confunda valor com custo) seja entregue em partes, à cada iteração.

Uma abordagem colaborativa com stakeholders (como a do Scrum) e a ênfase no valor de negócio, garantem uma estrutura orientada para o cliente. E não orientada ao software.

Lembre-se: seus clientes não querem seus softwares. Eles querem o valor gerado pelos mesmos. Eles querem ser “melhores” do que eram antes de comprar seu software.

#6 – Eficiência

O Time-boxing e a minimização de trabalho não-essencial conduzem a níveis mais altos de eficiência.

Eu sou obcecado por eficiência. Admito.

Já escrevi aqui no blog sobre como conduzir reuniões mais eficientes, sobre como ser uma pessoa mais eficiente e muitas outras dicas nesse mesmo sentido. E o Scrum, o meu framework ágil favorito prioriza a eficiência, por isso que o amo. S2

As coisas mais excêntricas existentes no Scrum são em prol da eficiência. E por isso que seguir o Scrum à risca é tão importante, principalmente em equipes imaturas do ponto de vista de agilidade.

Pense nas time-boxes: restrições pétreas quanto à duração de eventos no ciclo de desenvolvimento. Sprints de x semanas. Reuniões de x horas. E por aí vai. Isso não é algo negociável. Esse tipo de restrição estimula os desenvolvedores do time a pensar no que é mais importante ser desenvolvido HOJE rumo ao objetivo de AMANHÃ. Não há tempo a perder com coisas que não gerem valor à meta da sprint. Estimula o Product Owner a manter o backlog priorizado com o que realmente deve entrar no produto na próxima sprint, deixando para um futuro incerto o que não é essencial à aplicação.

Todos sabemos (ou deveríamos saber) que a falácia da próxima feature e a over-engineering são alguns dos piores maus que podem arruinar um projeto de software e até mesmo uma empresa. As restrições de tempo do Scrum (e as demais também) te ajudam a não cair nessas tentações, como essa outra, de reescrever todo o código da sua aplicação para que fique “melhor”, por exemplo.

#7 – Motivação

Os processos de conduzir a Reunião Diária e de Retrospectiva da Sprint conduzem a níveis mais altos de motivação entre os colaboradores.

Uma das chaves para a motivação é o que Simon Sinek chama de Golden Circle, neste brilhante vídeo. Conforme evidenciado não apenas nesse trabalho (do vídeo) mas em muitos outros, é necessário um ambiente de alta confiança para que o time se sinta motivado a seguir em frente em prol dos objetivos gerais da sprint.

Processos do Scrum (sim, ele ajuda nisso também) como a Reunião Diária e a Retrospectiva da Sprint promovem a transparência (pilar 1, lembra?) e a colaboração, resultando em um ambiente de trabalho de alta confiança, e garantindo baixo atrito entre os colaboradores, além de uma alta motivação, uma vez que o time tem o suporte e aval necessários para que consiga avançar sem impedimentos (né, sr. Scrum Master?!).

Quando os times confiam sem si mesmos e seus líderes confiam no time, a motivação se torna algo inabalável, gerando a responsabilidade coletiva e o comprometimento, que é o que todo gerente quer da sua equipe e toda empresa quer ver nos seus funcionários.

O processo de aprovar, estimar e comprometer-se às tarefas (ou histórias de usuário, casos de uso, etc) permite que os membros do time se sintam responsáveis pelo projeto e por seu trabalho, resultando em uma qualidade muito maior. Não importa se você vai usar planning poker ou não, mas se não houver confiança no time para tomar essas decisões, não haverá motivação para executar as tarefas.

Tudo começa na confiança!

#8 – Alta Velocidade

Uma estrutura de colaboração permite que os times multifuncionais atinjam o seu pleno potencial e alta velocidade.

Se o seu time vem vencendo nos demais quesitos como motivação, entrega contínua de valor, transparência, adaptação, etc você terá o que todo gerente de software almeja: alta velocidade!

Pausa para aquele momento em que uma música de cornetas toca e as nuvens se abrem para os céus porque você atingiu a iluminação.

Não, agilidade não é entregar software, pura e simplesmente, mais rápido. É sobre entregar valor mais cedo. Mas quando você entrega valor mais cedo, a percepção que TODOS tem (interna e externamente) é que o time está avançando mais rápido.

Pense comigo: o que vale mais, eu (um professor sedentário) correndo em linha reta por 100m ou o Usain Bolt correndo em zigue-zague para chegar no mesmo destino que está 100m à frente? É o mesmo para software!

Se você não está trabalhando com um backlog priorizado, não está entregando software com foco no cliente (ou seja, entregando valor pra ele), você está “andando em zigue-zague” rumo ao mesmo objetivo que poderia estar perseguindo em linha reta!

A alta velocidade obtida com o Scrum não está na quantidade de linhas de código que seu time vai escrever por sprint. Mas sim nas linhas certas que serão escolhidas para serem escritas. Aquelas que trarão os maiores resultados para o cliente em menos tempo.

Ponto.

Isso é velocidade, de maneira inteligente!

#9 – Ambiente Inovador

Os processos de Retrospectiva da Sprint e de Review da Sprint criam um ambiente de introspecção, aprendizagem e adaptabilidade, que levam a um ambiente de trabalho inovador e criativo.

Não custa repetir: transparência, inspeção e adaptação. Os três pilares do Scrum.

Esse ciclo virtuoso é a chave para a inovação. A inspeção e adaptação frequentes do Scrum levam o seu produto sempre aonde ele deve estar, agora, neste momento. E não conforme foi planejado um ano atrás com a diretoria em um lindo restaurante estrangeiro com todo mundo em seus belos ternos sob medida.

Ninguém sabe o amanhã, e embora seja extremamente válido (e aconselhável) definir as estratégias e médio e longo prazo, é a execução em curto prazo (aliado aos pilares do Scrum) que vão garantir a existência do projeto para TALVEZ chegar no destino desejado. Se ele ainda fizer sentido um ano depois de traçado.

A chance de revisitar o processo e ajustá-lo a cada sprint é única e dá ua vantagem muito grande ao time frente às metodologias tradicionais: a vantagem de poder errar. Mas errar rápido e aprendendo com esse erro, acertar.

Ninguém tem as respostas sobre como os softwares tem de ser desenvolvidos em todos os casos. Nem o Scrum. Mas se ele tem algo de valioso e memorável são que a inspeção e adaptação às mudanças devem ser o cerne dos projetos.

Be water, my friend!

Os 6 princípios mais importantes do Scrum

chicken-n-pigTrabalho com métodos ágeis desde 2010. De lá pra cá, nestes 7 anos de estrada, vejo muitas equipes falharem na adoção do framework, seja pela disciplina inerentemente necessária à essa tarefa, seja pela displicência das equipes em realmente “fazer acontecer”.

Sinceramente não acredito que o “Scrum flácido” seja o principal causador dessas falhas, mas sim uma “mentalidade flácida”. Não são raros os times que acham que colocar o Scrum Guide embaixo do braço vai resolver todos os seus problemas de entregas fora do prazo, escopo indefinido, falta de comprometimento e muito mais.

Muito mais do que decorar as regras do Scrum, neste post sugiro que você se foque em entender os 6 princípios mais importantes por trás dessa famosa metodologia. O Scrum não funciona apenas por ter reuniões de 15 minutos em pé todos os dias. Ele funciona por causa dos princípios por trás de cada um dos seus eventos, papéis e, porque não dizer, “excentricidades”.

Resumidamente, os princípios são:

  1. Empirismo
  2. Auto-organização
  3. Colaboração
  4. Priorização baseada em valor
  5. Time-boxing
  6. Iterativo-incremental

Princípio 1: Empirismo

Você sabe o que é algo ‘empírico’?

É algo advindo do conhecimento prático, o oposto de algo que só funciona na teoria, entende?

Scrum é um framework empírico, criado com base em décadas de experiência dos seus fundadores à frente de projetos de software e essa é a filosofia central dele. Não apenas você deve acreditar nos anos de experiência dos srs. Ken Schwaber e Jeff Sutherland como Scrum enfatiza que você aprenda com a sua experiência ao longo das sprints.

Transparência, inspeção e adaptação, os três pilares do Scrum, lembra?.

Após rodar algumas sprints (da maneira correta, fazendo reviews e retrospectivas), você começará a gerar o seu próprio conhecimento empírico, realimentado o framework e aumentado a qualidade dos seus processos.

Princípio 2: Auto-organização

Esse aqui talvez seja o ponto mais falho, uma vez que nem todo mundo tem a disciplina de se auto-organizar. O fato é que as pessoas entregam significativamente um maior valor quando são auto-organizadas e isto resulta em times mais satisfeitos e responsabilidade compartilhada; e em um ambiente inovador e criativo que é mais propício ao crescimento.

Lembra da fábula da “galinha e o porco” (ilustrada no início desse post)? #oldbutgold

A galinha queria abrir um restaurante com o porco, sugerindo o nome “Ovos com Presunto”. No entanto o porco recusou. Isso porque ele estaria comprometido, enquanto a galinha estaria meramente envolvida.

Auto-organização requer um comprometimento altíssimo com os demais membros do time e com a empresa. É um princípio fundamental não apenas para o Scrum, mas para a vida da gente.

Princípio 3: Colaboração

Esse princípio concentra-se nas três dimensões básicas relacionadas com o trabalho colaborativo: consciência, articulação e apropriação. Também defende o gerenciamento de projetos como um processo de criação de valor compartilhado, com times trabalhando e interagindo em conjunto para atingirem melhores resultados.

No livro As 17 incontestáveis leis do trabalho em equipe, de John Maxwell, a primeira lei é a Lei do Monte Everest. Ninguém jamais conseguiu subir o monte Everest sozinho. Sabe por quê? Porque quanto maior o objetivo, maior a necessidade de se trabalhar em equipe, de maneira colaborativa.

Quando o time é competitivo e/ou quando os membros são egoístas, o objetivo do grupo não é alcançado, e muitas vezes os pessoais também não.

Princípio 4: Priorização Baseada em Valor

Esse princípio destaca o foco do Scrum em entregar o máximo de valor de negócio possível, durante todo o projeto.

Quando falamos que Scrum é um framework para desenvolvimento de produtos complexos, que seu cerne é entregar valor de maneira frequente e com qualidade, não estamos falando necessariamente de software. Esse é apenas o uso mais comum do framework.

Entregar valor é atender a demanda do seu mercado. É resolver o problema do seu cliente.

Não tem nada a ver com fazer over-engineering ou escovar bits. Lembra-se do Manifesto Ágil? Software funcionando é mais importante do que documentação abrangente. Eu diria mais, cliente satisfeito é mais importante que usar a linguagem de programação da moda. Que valor é mais importante que tecnologia.

Princípio 5: Time-boxing

O tempo é considerado uma restrição limitada em Scrum, e que ele deve ser usado para ajudar a gerenciar o planejamento e execução do projeto com eficácia. Os elementos Time-boxed em Scrum incluem os Sprints, as Reuniões Diárias, a Reunião de Planejamento da Sprint, e a Reunião de Revisão da Sprint.

Na verdade não só no Scrum, mas o conceito de time-boxing deve ser levado para toda a vida, se você deseja ser mais produtivo.

O princípio de eventos com prazo e duração limitados norteia-nos para que os objetivos sejam atingidos de maneira eficaz e eficiente.

É duro dizer a um colega do time que ele estourou o tempo que tinha para falar na reunião diária. Mas tenha a certeza que da próxima vez ele será mais objetivo, se quiser ser ouvido por completo.

É triste muitas vezes o time falhar na entrega porque faltava “apenas” mais um dia para terminarem as features. Mas tenha a certeza que na próxima sprint eles aprenderão com esse erro e estimarão melhor as tarefas. Ou se descuidarão menos com distrações e imprevistos.

Princípio 6: Iterativo-Incremental

Muita gente confunde iterativo com interativo. E não é um typo, existe um ‘n’ a mais na segunda palavra.

Iteração é uma execução de um laço, uma repetição. Um desenvolvimento iterativo-incremental é aquele cujas etapas se repetem indefinidamente, e a cada iteração, um novo incremento do produto é entregue pronto.

Mesmo que não use Scrum, desenvolver produtos de maneira iterativa-incremental é sempre uma boa ideia. Iterações e colaboração com o cliente garantem uma entrega alinhada com a percepção de valor do cliente, o que por sua vez gera uma maior qualidade no projeto como um todo.

Mesmo que não use Scrum, aplicar estes princípios em seus projetos não faz mal à ninguém, muito pelo contrário, faz muito bem.

Até a próxima!

Como contratar um profissional ágil para sua empresa? – 11 perguntas

Desde que conheci Scrum em 2010, vejo um grande movimento no mercado de desenvolvimento de software em torno da adoção de metodologias ágeis e cada vez mais a procura por profissionais com o mesmo mindset e até mesmo experiência com Scrum e cia. Vagas para Scrum Master, principalmente, mas para outros papéis do Scrum, têm aparecido em sites de empregos com cada vez mais frequência, embora o próprio framework diga que Product Owner, Scrum Master e o Developer Team são papéis e não cargos.

Mas aí surge uma dúvida, como descobrir se a pessoa que estou entrevistando tem perfil ágil para trabalhar em meu time? Claro, dependendo de qual papel ela irá assumir no time, existem diferentes características desejáveis, como a figura abaixo ilustra bem (acho que tirei do SBOK, não lembro).

Capturar

E, para ajudar a identificar candidatos que possuam o potencial ágil que você busca, as perguntas abaixo podem ser realizadas durante a entrevista. Note que  a maioria delas não possui uma única resposta correta, mas todas ajudam a entender como o candidato raciocina sobre agilidade.

As perguntas são:

  1. Em primeiro lugar, qual o propósito de ser ágil?
  2. Como você caracterizaria o seu papel como______?
  3. Quando foi a última vez que você disse ‘não’ para outro membro de equipe? Como você lidou com a situação? Qual a razão disso?
  4. Como seu papel se relaciona com os demais do time Scrum?
  5. Sua organização recentemente decidiu implantar o uso de metodologias ágeis no desenvolvimento de produtos. Que implicações isso pode trazer aos stakeholders?
  6. Como você organiza/gerencia a colaboração entre o time e os stakeholders?
  7. Uma nova feature atrasou drasticamente devido a um débito técnico. Os stakeholders querem-na entregue mesmo assim, devido à quantia que já foi investida. Como você lida com isso?
  8. O departamento de vendas têm vendido novas features sem falar com seu time, responsável pelo produto, primeiro. Como você lida com isso?
  9. Como é sua abordagem para lidar com roadmaps de produto?
  10. Como você refina a si mesmo e o seu papel dentro do time?
  11. Como você lida com bugs + débito técnico vs novas features no dia-a-dia?

#1 – Em primeiro lugar, qual o propósito de ser ágil?

A resposta mais comum aqui, e a mais errada também, é: entregar os projetos mais rápido. Pessoas leigas no assunto tendem a confundir agilidade com velocidade. Ser ágil não é programar mais em menos tempo, isso é ser eficiente. Ser ágil é realizar entregas de maneira mais frequente e com mais qualidade.

#2 – Como você caracterizaria o seu papel como __________?

A lacuna que deixei na pergunta é para você colocar o papel que o candidato irá assumir: Scrum Master, Product Owner ou Team Dev. Você pode emendar outras perguntas na sequência, dependendo do papel, como segue:

Scrum Master: qual a diferença entre um Scrum Master e um gerente de projetos tradicional? Como seria um dia típico nessa função?

Product Owner: qual a diferença entre um PO e um gerente de produtos tradicional? Como você gerencia seu product backlog?

Team Dev: qual a diferença entre um dev Scrum e um dev “normal”? À quem você deve reportar suas atividades?

Nestas perguntas, a ideia é ver se o candidato realmente sabe do que se trata o papel ao qual ele está se candidatando. Essa pergunta é mais importante para o Scrum Master e o PO, mas entender o quão auto-gerenciável é um Dev no momento da contratação também pode ser muito útil.

#3 – Quando foi a última vez que você disse ‘não’ para outro membro de equipe? Como você lidou com a situação? Qual a razão disso?

Novamente uma pergunta importantíssima para entender se os candidatos a PO e Scrum Master possuem as virtudes necessárias para esses papéis, como foco e disciplina. Dizer ‘não’ é importantíssimo dentro de times Scrum para garantir que os objetivos serão atingidos.

#4 – Como o seu papel se relaciona com os demais do time Scrum?



Essa é mais uma pergunta para entender se o candidato tem o perfil colaborativo necessário para que um time Scrum funcione, bem como se ele domina o Scrum em sua plenitude, não apenas o seu ‘quadrado’.

#5 – Sua organização recentemente decidiu implantar o uso de metodologias ágeis no desenvolvimento de produtos. Que implicações isso pode trazer aos stakeholders?

Essa pergunta é decisiva para a contratação de um Scrum Master. Toda implantação de métodos ágeis implica em mudança cultural na empresa e, principalmente, afeta a forma como os stakeholders interagem com o time de desenvolvimento de produto, o que nem sempre é visto com ‘bons olhos’. Como Scrum Masters são responsáveis pela implantação do Scrum nas empresas, é dever deles saber do impacto que isso causa.

#6 – Como você organiza/gerencia a colaboração entre o time e os stakeholders?




Colaboração é a chave para o sucesso dos projetos, seja entre os membros do time entre si e os membros do time com os stakeholders. Lembra da pergunta #3? Essa tem um pouco a ver também.

#7 – Uma nova feature atrasou drasticamente devido a um débito técnico. Os stakeholders querem-na entregue mesmo assim, devido à quantia que já foi investida. Como você lida com isso?

Essa é a clássica pergunta sem resposta, mas que mostrará o raciocínio do candidato em situações complicadas como essa. Deve ele abrir mão da qualidade em prol do prazo? Deve dizer não aos stakeholders em prol da qualidade? O que o Scrum diz sobre isso?

#8 – O departamento de vendas têm vendido novas features sem falar com seu time, responsável pelo produto, primeiro. Como você lida com isso?



E nesse caso? O time de vendas “serve” ao time de produto, o contrário ou nenhum dos dois? Quem está certo e quem está errado? Perguntas complicadas, que o candidato não espera ter de responder, são as melhores para mostrar quem realmente ele é e como encara questões como trabalho em equipe, agile, etc.

#9 – Como é sua abordagem para lidar com roadmaps de produtos?

Uma questão muito boa para Product Owners e Scrum Masters, mas que pode ser usada também em devs, embora com propósito diferente. Tente descobrir que ferramentas o candidato já usou, como é um dia típico dele em relação ao roadmap de produto.

#10 – Como você refina a si mesmo e o seu papel dentro do time?

Os 3 pilares do Scrum são transparência, inspeção e adaptação e não podemos esperar menos do que isso em um candidato. Como que o candidato inspeciona seu desempenho e adapta-se visando melhoria contínua?

#11 – Como você lida com bugs + débito técnico vs novas features no dia-a-dia?

Outra pergunta essencial para Scrum Masters e POs, que geralmente lidam no dia-a-dia com esse conflito de aperfeiçoar o que já existe vs criar coisas novas. Como que o candidato ‘descobre’ o que é realmente mais importante nesse momento para a empresa?

O que achou? Tem alguma dúvida sobre alguma pergunta? Gostaria de adicionar alguma outra? Eu ia adicionar uma pergunta #12, sobre qual o melhor livro sobre Scrum do mercado, mas essa todo mundo ia acertar, não é mesmo?! 😉