2.6 Os princípios fundamentais do Scrum

 

O tabuleiro do jogo Scrum na figura 2.5 não apenas mostra os elementos formalmente prescritos do Scrum, mas também três princípios básicos subjacentes ao Scrum:

❖ Espaço de trabalho (Visual) compartilhado ❖ Auto-organização;

❖ Empirismo (conhecido como ‘controle de processo empírico’).

 

2.6.1 Espaço de Trabalho (Visual) Compartilhado

 

As equipes, para funcionar adequadamente e crescer em termos de eficácia e desempenho, precisam de um espaço de trabalho compartilhado para suas interações e colaboração. O time organiza seu próprio espaço de trabalho para otimizar diálogo, comunicação e colaboração. Isso inclui a remoção de barreiras - físicas ou mentais - que obstruem o fluxo de informações. O espaço de trabalho compartilhado facilita que o time e seus membros tomem decisões rápidas e engajadas. Embora não seja obrigatório, a co-localização física acaba sendo mais ideal do ponto de vista da dinâmica de equipe. Mas, mesmo quando não está trabalhando colocada, um time precisa de um espaço de trabalho compartilhado, incluindo todos os recursos de comunicação modernos necessários para superar a distância física da melhor maneira possível.

Dentro do espaço de trabalho, um time deve ser capaz de se concentrar em atividades de valor agregado. Todo o trabalho administrativo e indireto é mantido a um mínimo. Isso inclui o armazenamento de informações. As equipes precisam de acesso rápido a todas as informações do time, para criar, manter e compartilhar, e agilizar todas as decisões que serão tomadas baseadas nessas informações. É por isso que as equipes preferem técnicas de gerenciamento visual. Um espaço de trabalho compartilhado tem muitos radiadores de informação [Cockburn, 2002]. Os radiadores de informação limitam o tempo de transmitir informações e concentram-se no time como uma unidade, o que é crucial quando se realiza um trabalho complexo.

Uma visão geral de tarefas, definições de equipe, padrões e acordos, artefatos de processo e tendências de progresso são disponibilizados e visíveis dentro do espaço de trabalho compartilhado, publicando-os nas paredes da sala; em quadros brancos, flip charts ou outros meios. Isso inclui todas as informações que o time julgar apropriadas para visualizar, como desenhos e modelos, análises de impacto, impedimentos, a Definição de Pronto, os padrões de desenvolvimento, etc.

Ao entrar na sala toda a informação está prontamente disponível, a sala a irradia para o leitor interessado. O leitor não é forçado a entrar em sistemas eletrônicos, obter autorizações, autenticá-las, procurá-las, procurar a versão mais recente ou até mesmo perguntar sobre elas. As equipes mantêm todas as informações cruciais dessa forma visualizada para compartilhá-las dentro e além dos membros do time, e usá-las para inspecionar e adaptar.

A informação não é estática. Ela reflete constantemente o atual estado de coisas, onde o estado atual pode ser usado para projetar previsões para o futuro.

 

2.6.2 Auto-organização

 

O Scrum prospera na colaboração diária das três funções pares. Cada papel tem claras responsabilidades dentro do time bem como em sentido da organização. O Scrum Team e, dentro dele, o Development Team são unidades de pessoas auto organizadas.

A auto-organização não é apenas o grau de liberdade que é permitido. A auto-organização não é sobre delegação. A auto-organização é, acontece. A auto-organização não é sobre habilitar ou empoderar, não existe autoridade superior que a conceda. A capacidade de se auto organizar realmente requer a remoção de muitas barreiras existentes que impedem as pessoas de se comunicar, interagir, obter insights e colaborar. É assim que autoridades externas são mais eficazes; removendo barreiras organizacionais ou processuais para melhor facilitar as equipes.

A auto-organização não é sobre anarquia ou liberdade ilimitada. A auto-organização tem e exige limites, limites dentro dos quais a auto-organização acontece. As regras do Scrum são um dos principais limites dentro dos quais uma equipe auto organiza seu trabalho:

❖ O Development Team seleciona colaborativamente o trabalho conforme

ordenado e expresso pelo Product Owner, cria colaborativamente

atividades acionáveis para a sua projeção da Sprint e replaneja o trabalho

diariamente em uma Sprint com time-box para otimizar o resultado. ❖ O Product Owner interage com usuários, stakeholders e gerentes de

produtos para identificar o trabalho mais valioso e conta com

Development Team(s) multifuncional para a entrega real disso em

Incrementos de produto. Os stakeholders ajudam a moldar o futuro

produto em cada Sprint Review.

❖ O Scrum Master não tem interesse direto no escopo, orçamento, entrega

ou tarefas, mas treina e facilita o ecossistema completo no uso do Scrum

para gerenciar esses fatores.

Pessoas organizadas em equipes têm maior coesão, confiança mais profunda e interconexões mais eficazes quando o tamanho do time totaliza em torno de cinco a sete membros. Embora o Scrum estabeleça uma expectativa de que o tamanho do Development Team seja entre três e nove membros, não há necessidade de um processo formal para impor isso. Através da auto-organização, uma equipe ajustará seu tamanho de forma autônoma até que o desempenho ideal seja atingido. Isso até acontecerá entre equipes trabalhando juntas. Não existe um órgão externo que saiba organizar melhor o trabalho do que as pessoas que realmente realizam o trabalho.

Em seu livro ‘Drive’ [Pink, 2009], Daniel Pink elabora a evidência científica do que motiva as pessoas. Ele descreve como a ‘auto-dirigência’, a capacidade das pessoas dirigirem seu próprio trabalho, é um dos três motivadores cruciais no trabalho criativo e cognitivo. ‘Maestria’ e ‘Propósito’ completam a lista. Juntos, eles decifram o que Pink identifica como o terceiro impulso (drive), o modelo de motivação humana que segue o primeiro impulso de sobrevivência e o segundo impulso de esquemas tayloristas industriais que implementam recompensas por ‘incentivos e penalização’. A auto-organização do Scrum é, assim, confirmada como crucial para a motivação dos jogadores no trabalho criativo, exigindo habilidades cognitivas.

No entanto, autonomia e auto-organização não resolvem todos os problemas. Alguns problemas vão além da auto-organização do Development Team. O Scrum os chama de ‘impedimentos’.

A definição geral de um impedimento é uma ‘obstrução; empecilho; obstáculo’. Um impedimento no Scrum é um fator que bloqueia o time na criação de uma versão valiosa do produto em uma Sprint, ou que restringe a equipe a atingir seu nível intrínseco de progresso. É a responsabilidade do Scrum Master em remover impedimentos.

Vamos ilustrar isso com o exemplo de um conflito de equipe, um conflito entre os membros do time.

Uma equipe pode ter problemas para resolver um conflito interno e chamar o conflito de impedimento, esperando que o Scrum Master o remova para eles. Em outras palavras, eles esperam que o Scrum Master resolva o conflito.

No entanto, trabalhar em equipe inclui, inevitavelmente, conhecer uns aos outros, encontrar formas de construir versões dos produtos, explorar formas diferentes de colaborar, encontrar consenso sobre ideias diferentes, superando o desejo de heroísmo pessoal. Em seu livro, ‘Coaching Agile Teams [Adkins, 2010], Lyssa Adkins elabora sobre ‘desacordo construtivo’ como uma necessidade para as equipes. Este nível mais baixo de conflito conecta-se com a ‘instabilidade embutida’ observada e descrita por Takeuchi e Nonaka [Takeuchi & Nonaka, 1986] como o solo fértil para o desenvolvimento bem-sucedido de produtos complexos. É uma parte natural da liberdade dada a um grupo de pessoas descobrir conjuntamente as melhores maneiras de seguir em frente, na ausência de uma autoridade externa que prescreva a solução.

Conflitos são uma parte natural do trabalho com pessoas, do trabalho em equipe. É uma parte essencial da auto-organização. Se um membro traz um conflito interno para ciência do Scrum Master, este deve se perguntar qual é o problema real. É o papel do Scrum Master resolver o conflito? Ou seria uma intervenção indesejada no ecossistema de auto-organização, minando a honestidade futura, a aprendizagem e o auto aperfeiçoamento? Como o Scrum Master pode facilitar a auto-organização? Oferecendo às equipes uma desculpa, uma decisão externa de se esconder?

Um Scrum Master, como promotor do Scrum e auto-organização, considera como ajudar um time a resolver seus próprios problemas e oferecer quaisquer ferramentas, treinamento e insights sobre a melhor forma de fazer isso, sobre como se autodesenvolver.

 

2.6.3 Controle de processo empírico

 

O desenvolvimento de novos produtos é uma atividade complexa por si e serve para fornecer produtos complexos em circunstâncias complexas.

Uma perspectiva sobre o grau de ‘complexidade’ refere-se ao número de parâmetros, variáveis e eventos que influenciam uma atividade e seu curso. No desenvolvimento de produtos, alguns dos parâmetros mais conhecidos são as expectativas e requisitos do usuário, habilidades, disponibilidade e experiência de pessoas organizadas em equipes, tecnologia, integrações técnicas, condições de mercado e concorrência, regulamentos e dependências.

No entanto, não é apenas o número de parâmetros conhecidos que é importante, mas também o conhecimento disponível, bem como o conhecimento necessário desses parâmetros. Qual é o nível de detalhe necessário para compreender uma variável, bem como o comportamento futuro dessa variável? Mesmo que um parâmetro seja conhecido, o nível de detalhe pode ser muito profundo para poder gerenciá-lo e controlá-lo. E então, é claro, o comportamento do parâmetro ainda não é necessariamente previsível. Uma variável conhecida pode ainda se comportar de maneira completamente diferente do esperado.

‘Complexidade’ também é dependente da natureza da atividade em si. Os resultados exatos e detalhados do desenvolvimento do produto são difíceis de descrever e prever antes ou até mesmo no início do desenvolvimento real. As etapas, tarefas e atividades combinadas que compõem o trabalho atual não são previsíveis com qualquer grau de alta precisão. Pessoas as executam e o envolvimento das pessoas depende de muitas circunstâncias. Além disso, também há o trabalho com a tecnologia em si, em que a tecnologia evolui constantemente e é dependente da particularidade do ambiente de uma organização.

As etapas, tarefas e atividades de desenvolvimento de produtos não são previsíveis em um alto grau de precisão porque não são repetíveis. Cada ‘produto’ sendo desenvolvido, que não é mecanicista ou industrial, é único. Novas tecnologias surgem, novas interfaces precisam ser construídas, novos plug-ins são usados, novas integrações precisam ser configuradas, novos insights e técnicas para o desenvolvimento são descobertas regularmente, enquanto o trabalho já está sendo realizado.

O grau de dinamismo de um problema ou atividade requer que o processo correto esteja em vigor para se ter o controle correto sobre a atividade:

❖ Em um sistema de ciclo aberto, todas as variáveis são coletadas

antecipadamente porque elas precisam ser apresentadas ao sistema como

entrada, antes que uma única das etapas seja executada, resultando em

um resultado previsto. Para poder prever o resultado e o tempo decorrido,

esse tipo de controle de processo assume um alto grau de previsibilidade

das variáveis que influenciam o processo, bem como das próprias

atividades do processo.

Para obter controle sobre problemas grandes ou complexos, usando o

pensamento de ciclo aberto, os subsistemas são criados onde cada

subsistema é um sistema de ciclo aberto separado. A entrada de cada

subsistema é a saída do subsistema anterior. Em situações de maior

turbulência e mudança frequente, desvios e variações se acumularão ao

longo da cadeia de subsistemas, inerentemente muito além de níveis

aceitáveis, e somente serão detectados no fim do subsistema final.

Planos preditivos são expressões do paradigma industrial e das

implementações da corrente de pensamento de ciclo aberto. Planos

preditivos podem incluir apenas variáveis conhecidas e seu

comportamento esperado. Planos preditivos criam a ilusão de que o

comportamento das variáveis conhecidas é entendido com precisão e que

outras variáveis são inexistentes. Planos preditivos convidam a uma

longa consideração inicial de todos os elementos que devem fazer parte

do plano e, em um contexto complexo, tentam prever o imprevisível.

Para controlar variáveis não previstas ou comportamento inesperado, são

necessários procedimentos pesados para verificar, manter e atualizar o

plano preditivo.

❖ Em um sistema de ciclo fechado, o resultado real do sistema é

regularmente comparado ao resultado desejado, a fim de eliminar ou

diminuir gradualmente quaisquer variações indesejáveis. Nem todas as

variáveis e parâmetros precisam ser conhecidos com precisão e em

detalhes antecipadamente, pois o processo aplica a autocorreção e leva

em consideração parâmetros novos ou variáveis. Essa técnica de

inspeções regulares requer e cria transparência. A situação real é

inspecionada e exposta, de modo que as adaptações mais apropriadas

possam ser realizadas para preencher a lacuna entre os resultados

efetivos e esperados. As pessoas que realizam as inspeções, os

inspetores-jogadores, precisam de padrões claros e acordados para

realizar suas inspeções. Daí a necessidade de transparência do processo e

de todas as suas variáveis para todos os membros envolvidos.

O Scrum reconhece que a complexidade do desenvolvimento de produto

requer o processo correto, ou seja, feedback em ciclo fechado. O Scrum

substitui os ciclos abertos dos processos tradicionais pelo empirismo dos

sistemas de ciclo fechado. O Scrum implementa oportunidades regulares

de inspeção e adaptação, para que os jogadores possam aprender da

inspeção, coletar feedback dos resultados e melhorar. O Scrum traz o

controle baseado na realidade para o trabalho complexo.

O Scrum implementa dois ciclos específicos de feedback de ciclo fechado. Uma Sprint forma um ciclo de ‘inspecionar e adaptar’ que envolve as ‘inspeções e adaptações’ a cada 24 horas na Daily Scrum:

❖ Na Daily Scrum, o Development Team inspeciona seu progresso e planeja

seu próximo trabalho dentro do contêiner da Sprint. Eles usam o Sprint

Backlog e o Objetivo da Sprint, como inicialmente definidos na Sprint

Planning e uma tendência de progresso para considerar o trabalho

restante. Isso garante que eles não saiam de sincronia entre si no time e

com o Objetivo da Sprint por mais de 24 horas. ❖ Uma Sprint é um ciclo que começa com a projeção do trabalho e termina

com reflexões sobre o que realmente foi construído, o Incremento do

produto, e como ele foi construído, o processo, as interações do time e a

tecnologia.

Os eventos do Scrum definem a frequência da inspeção e adaptação, onde os artefatos contêm as informações a serem inspecionadas e adaptadas:

O Scrum prevê esses eventos formais como oportunidades para inspecionar e adaptar-se à situação real, de modo que a arte do empirismo seja realizada no mais tardar durante esses eventos. Isso não deve impedir que os membros da equipe busquem melhorias e progridam sempre que necessário. Em um mundo do alto dinamismo que leva ao uso do framework Scrum, seria muito estranho que as equipes não aproveitassem novas informações e insights que melhorassem sua vida profissional tão logo possível.

 

Nenhum desses eventos foi projetado para fins de relatar status. Todos os eventos no Scrum são projetados para serem voltados ao futuro. A capacidade de adaptação define o nível de agilidade alcançado.

 

OceanofPDF.com