Scrum não é bala de prata

Espantado com o título? Não fique, vou explicar. Para o Scrum funcionar bem e trazer um resultado positivo para a organização que está aplicando, são necessárias que várias questões sejam atendidas primeiro. 

À primeira vista, o Scrum é simples de entender, mas é difícil de implantar, porque a cultura organizacional tem que ser trabalhada para funcionar com qualquer modelo ágil.

Comando e controle

A começar pelo antigo comando e controle da sociedade industrial, que não funciona como cenário para o Scrum.

Em suma, uma vez que as equipes devem ser auto organizáveis e auto gerenciáveis elas querem autonomia para tomada de decisões, as lideranças precisam aprender a delegar.

Os executivos têm que entender que, não é saudável cobrar ou impor datas. Por que o Scrum não tem planejamento de longo prazo, somente de curto prazo, que é o tamanho da Sprint.

Não sabemos qual é a data final do projeto. A qualquer momento, essas entregas incrementais podem satisfazer a necessidade, sem ter que desenvolver tudo que se imaginou. Ou ao contrário também, pode-se entregar todas funcionalidades, e descobrir que mais precisa ser implementado.

E isso tudo é muito saudável, para real atendimento ao cliente, e entregar de fato algo para atender o objetivo estabelecido. Claro que há exceções, pode haver datas pré estabelecidas por conta de leis, que entram em vigor por exemplo.

Experimentação e Tolerância a erros

As equipes querem inclusive, poder fazer experimentação, tendo o direito de errar. E esperam que a única consequência disso, seja aprendizado para melhoria contínua, e não represaria ou apontamento de culpados.

Em síntese, é necessária conhecimento e aplicação de gestão 3.0 por parte de todos os líderes, facilitadores e da alta administração da organização, praticando fortemente a empatia.

A cultura deve ser tolerância ao erro, para que as pessoas não tenham medo de experimentar, e tenham chance de inovar nos produtos, nas soluções, na forma de desenvolver um trabalho.

Não tem como ter inovação e melhoria contínua se as pessoas tem medo de tentar algo novo.

Lean

Para ser ágil, é necessário ser lean, ou seja diminuir a quantidade de documentação, e fazer somente aquela imprescindível ao projeto.

Dessa forma, a alta administração, não deve esperar das equipes ágeis, relatórios constantes, documentação extensa de projeto etc.

Quer saber como anda o projeto? Procure a facilitação visual disponível e/ou faça um face-to-face com o Scrum Master, ele vai te dar todas as informações. Ou vai dizer, quem pode responder as suas questões, não se preocupe, o ágil presa pela transparência, nada será escondido.

Mudanças

Mudanças são bem-vindas no ágil. E isso facilita que o projeto acompanhe tendências de mercado, mudanças de leis, mudanças de estratégias etc, sem muito prejuízo.

Assim, as pessoas desde do alto escalão, devem ser abertas as mudanças: de escopo, na forma de trabalhar e na forma de fazer o projeto.

Valor

Todos precisam estar cientes que o retorno do Scrum as vezes é mensurado financeiramente, mas as vezes não é tangível.

Exemplo de não tangível: satisfação dos profissionais, aumento da quantidade de clientes, inovações surgindo com frequência e diminuição de desperdício de dinheiro, tempo e riscos.

Definitivamente, o Scrum evita desenvolver projetos longos, cujo resultado é um produto que é entregue só no final, e que normalmente, nem serve mais ao que se propõe. Ou por que, o problema já mudou ou  foi entregue algo que não era o esperado.

Parcerias

A alta administração tem que suportar e bancar a cultura ágil, frente as pressões de investidores e parceiros por datas, gráficos e relatórios.

Enfim, o ideal é que novos contratos comecem a ser feitos, com empresas que trabalhem nos moldes ágeis.

Humanização

A cultura deve estar fortemente humanizada, pois são pessoas (profissionais) construindo valor para pessoas (clientes). Por favor, não tenha um departamento com o nome de recursos humanos, não somos objetos, somos profissionais.

Logo, hora extra e ágil não se combinam, é necessário trabalhar de forma saudável e sustentável.

Diversão

A cultura da organização deve entender claramente, que trabalho as vezes, não parece ser trabalho. Existem formas divertidas de co-criar, de estimulo a inovação, de propiciar idéias para melhoria contínua.

Um bom exemplo disso, são as retrospectivas divertidas, com dinâmicas, jogos, brincadeiras e lanches. As vezes, até em conversas informais no corredor, podem trazer luz aos problemas e despertar alguma visão de solução.

Em suma, não é preciso manter as pessoas ocupadas, é preciso mante-las motivadas entregando VALOR para a organização.

Pois se as pessoas estão muito ocupadas com processos o tempo todo, numa cultura muito rígida, não sobra tempo para desenvolver grandes soluções e idéias.

Product Owner

O perfil de PO tem que ter muito entendimento do que o cliente quer. É ele quem prioriza as funcionalidades que serão desenvolvidas na Sprint, por tanto, ele deve escolher sempre o que for de maior valor para o cliente.

Antes de mais nada, se o PO não tiver claro, o que traz valor para o cliente, o resultado da Sprint não será positiva, por mais bem feito que possa ter sido o desenvolvimento. Haverá desperdícios de tempo, trabalho, dinheiro e irão culpar o Scrum por essa falha.

Além disso, o PO deve estar empoderado, para de fato tomar decisões e poder fazer essa priorização, cortando funcionalidades, e entregando o que de fato é relevante e faz a diferença. Principalmente se por algum motivo, houver uma data fim pré estabelecida, como alguma nova lei a ser atendida.

Equipes multifuncionais e auto-contidas

Equipes devem ser multifuncionais e auto contidas, bem como, tem que ter os profissionais necessários para desenvolver o que se propõe.

Dessa forma, não devem haver só profissionais especialistas, que só fazem determinado trabalho e nada mais. Pois isso acaba transformando as Sprints em Mini Waterfall, entregando um pedaço de alguma coisa que não é executável e testável.  Ex: uma Sprint para UX, uma Sprint para front-end, e várias Sprints para back-end.

Equipes grandes ocasiona de aumentar a quantidade de canais de comunicação, e isso dificulta a comunicação, além de diminuir performance.

Troca de pessoas nas equipes constantemente, tira o senso de pertencimento do profissional. Sob o mesmo ponto de vista, quanto mais tempo uma composição de equipe, mais tempo as pessoas se conhecem na forma de trabalho, mais confiam uns nos outros e mais adaptados uns aos outros eles ficam. Assim, a performance aumenta.

Quando sai alguém desnecessariamente e entra alguém novo, cai a performance da equipe. Pois as pessoas não ficam a vontade, é preciso conhecer esse novo integrante e demora até estabelecer confiança. É preciso se adequar a forma de trabalho dessa pessoa, em fim, é preciso reaprender a trabalhar nessa nova formação.

Equipes independentes

Desde já, não pode haver dependência externa da equipe, pois a cada dependência diminui a velocidade da equipe, pelos impedimentos, e que em alguns casos podem travar a Sprint. Enfim, isso afeta as entregas de valor das Sprints, afeta a moral do time e traz a incapacidade de execução ágil.

Qualidade

Em síntese, é preciso ter qualidade no desenvolvimento, para que volte o mínimo de erros possíveis para a equipe. O retorno de muitas correções, atrapalham o desenvolvimento de valor das Sprints.

Práticas XP

Frequentemente, as práticas de XP (extreme programming) unidas ao Scrum ajudam  na agilidade, exemplo TDD (Test-Driven Development) , Testes automatizados, Pair Programming, integração contínua etc.

Não ao Bimodal

Definitivamente, projetos conduzidos de forma Bimodal, causam muitos, se não todos, os transtornos citados acima, dependências, impedimentos, excesso de documentos, datas impostas etc.

Empresa integrada

De antemão, os departamentos devem colaborar entre si, para que seja uma empresa integrada, e com cultura ágil.

Imagina que uma equipe Scrum, precise de um profissional novo na equipe. E o meu departamento de pessoal, que deve me ajudar com isso, leve meses para conseguir. Eu preciso de um profissional sendo contratado de forma ágil, para a equipe poder entregar produtos ágeis.

A empresa necessita que o setor de marketing trace uma estratégia ágil, para lançar o produto que eu desenvolvi de forma ágil. E a logística da empresa tem que ser ágil, para distribuir o produto que foi lançado.

Em conclusão, se todos esses departamentos tiverem uma cultura ágil, e trabalharem em paralelo de forma integrada, teremos uma empresa ágil.

Contratação

Antes de mais nada, se você quer mudar sua cultura para implantar ágil, tem que mudar o comportamento, comece a contratar profissionais que pensem diferente das pessoas que você tem na sua empresa hoje, para que elas possam te ajudar.

Por onde começar?

Ai alguém se pergunta, mas se eu quiser começar pequeno, de forma discreta com uma equipe apenas, até que eu traga um resultado bacana e consiga vender o ágil para a organização?

Na minha humilde opinião, num primeiro momento vai funcionar, porém se a cultura organizacional não suportar uma mudança real, o caos vai se instaurar.

Um exemplo clássico, é que num primeiro erro de uma equipe que estava em busca de inovação, a organização vai procurar culpados, vai punir, colocar a culpa no Scrum.

Em suma, a medida que todos os cenários que eu listei acima forem ocorrendo, vai gerar insatisfação e confusão.

Como vender o Scrum?

Para vender o Scrum e o ágil, e mostrar que vale a pena, mostre dados e fatos com números do Scrum e ágil versus metodologia tradicional, você vai achar aos montes estudos com esses números na internet.

Porém, é preciso muita transparência, mostrando todos esses fatores culturais que eu listei nesse artigo. Se a questão da cultura organizacional não for muito bem tratada, o Scrum é como uma ferrari presa num trânsito comum da cidade.

Minha inspiração

Minhas inspirações vêem de muita leitura de livros, sites conceituados e leitura de posts de alguns agilistas aqui mesmo no Linkedin.

Também vou a muitos eventos de agilidade onde assisto palestras e troco experiências com profissionais de várias empresas. Fiz alguns cursos bacanas também.

“Eu posso não saber o que fazer, mais sem exatamente o que não fazer.”

Espero que tenham gostado e que eu agregado valor a vocês!

---

Informações sobre a autora:

Jacqueline Viana é Scrum Master na Concrete Solutions, e é apaixonada por agilidade.

Cofundadora Agile Pink