5 Fatos sobre a transformação ágil

Nunca fui fã de filmes de terror. Mas sempre achei o Halloween fantástico. Quando criança, adorava vestir fantasias assustadoras e assustar meus amigos e outras pessoas. E admito que gosto da adrenalina de entrar numa casa mal-assombrada bem preparada no Halloween.

No entanto, em toda transformação ágil também existem aspectos que podem causar arrepios – e esses momentos não são tão emocionantes assim.

Então vamos juntos tirar o medo dessas cinco coisas e conversar sobre o que exatamente elas são e por que não são tão assustadoras assim quando você realmente as entende.

1) Ahhh! No Agile não existe fase de Design!

Frequentemente, arquitetos e colaboradores do departamento de desenvolvimento ficam preocupados porque no Agile não existe uma fase de design explícita. Mesmo que seja verdade que equipes ágeis evitam fases de design no início de um projeto, isso não significa que o design seja negligenciado.

O design em um projeto ágil é caracterizado por duas características: é emergente e intencional.

O design emergente surge com o tempo. Em vez de uma fase de design inicial, o design é um processo contínuo. O design surge durante a criação do software.

Mas o design também é intencional. Isso significa que o design não surge por acaso. O design é orientado pelos colaboradores técnicos seniores de um projeto ou até mesmo por um arquiteto específico.

Se essas pessoas estão preocupadas com uma parte específica do sistema, o Product Owner deve priorizar um ou dois [Product Backlog Items]( "Product Backlog Item") dessa área. Assim, a equipe tem a chance de conhecer melhor essa parte do sistema, desenvolvendo uma pequena parte dela. Isso vai ajudar a encontrar o design correto para ela.

Quando o design surge dessa forma através das decisões da equipe, o fato de não existir uma fase de design explícita no Agile já não é mais tão assustador.

2) Socorro! Estou me tornando um generalista!

Um dos mitos mais difundidos no Agile é que equipes ágeis não querem especialistas e, em vez disso, preferem que todos na equipe sejam generalistas.

Isso assusta muitas pessoas por dois motivos: Primeiro, nem todo mundo gosta de fazer qualquer tipo de trabalho. Segundo, existe frequentemente a preocupação de que, no futuro, isso possa afetar a empregabilidade se alguém souber fazer quatro coisas mais ou menos bem em vez de uma coisa extremamente bem.

A ideia de que todos em uma equipe ágil precisam ser generalistas está errada. Quando faço coaching de uma equipe que tem o melhor profissional de JavaScript do mundo, quero que essa estrela faça coisas incríveis com JavaScript e não que aprenda a se tornar administrador de banco de dados.

Sim, em equipes ágeis você quer ter membros com as mais diversas habilidades: por exemplo, o testador que também consegue desenvolver um pouco de código. A forma mais simples é ter alguém que consiga fazer os dois tipos de trabalho igualmente bem. Se a sua equipe tem, por exemplo, um desequilíbrio entre trabalho de programação e de testes, é útil ter alguém na equipe que saiba tanto programar quanto testar.

Um objetivo no Agile é a formação de equipes interdisciplinares. Isso significa que uma equipe possui todas as habilidades para criar um incremento de produto finalizado e funcional em uma iteração. Mas isso não significa que cada membro da equipe precisa possuir todas as habilidades necessárias na equipe interdisciplinar.

Se o pensamento de se tornar um generalista te deixa de cabelo em pé, você ficará aliviado em saber que especialistas também são bem-vindos em equipes interdisciplinares.

3) Oh não! Não temos nem planos nem previsões!

Frequentemente, gestores se assustam com a ideia de que uma equipe ágil não consegue fazer planos ou previsões além da iteração ou sprint atual.

Felizmente, isso não é bem assim.

Sim, equipes ágeis abrem mão do falso conforto de projetos super planejados com diagramas de Gantt confusos e cronogramas exatos projetados para um futuro distante. Mas isso não significa que equipes ágeis não sejam capazes de planejar e prever o futuro.

Uma grande vantagem dos métodos ágeis é que a equipe revisa e ajusta todo o processo de desenvolvimento a cada iteração. Ela pega uma ideia na forma de uma simples User Story e implementa essa funcionalidade. Isso significa que as equipes podem medir seu progresso a cada poucas semanas. Assim descobrem quanto trabalho conseguem realizar.

Compare isso com um projeto de desenvolvimento tradicional, que talvez tenha uma fase de análise, uma fase de design, uma fase de codificação e, por fim, uma fase de testes. Quando essas equipes querem medir seu progresso, só conseguem verificar quão rápido executam uma (ou talvez duas) dessas atividades. A velocidade de uma equipe no design não diz nada sobre quão rápido ela avança com o código ou os testes.

O mais importante na transformação ágil é abraçar a incerteza – admitir que é impossível conhecer todas as funcionalidades antes do início do projeto – e então escolher uma das muitas formas de se adaptar a isso. Quando as equipes entendem isso e medem a quantidade de trabalho em cada iteração, isso deveria tranquilizar a gestão e levar a um planejamento confiável.

4) Socorro! Vou perder meu emprego!

A ideia de uma transição ágil de uma equipe ou de uma empresa inteira pode assustar bastante alguns gestores, já que muitos têm medo de que seu cargo se torne dispensável após a transição.

Isso é compreensível. Claro que seria terrível iniciar uma transição sabendo que isso tornará o próprio papel obsoleto.

No entanto, nunca ajudei uma empresa na transformação ágil e presenciei alguém dizer: "Ok, pessoas com tal ou qual função não precisamos mais. Todos serão demitidos." Isso não vai acontecer. Claro que pode ser que um determinado cargo não seja mais necessário ou adequado, mas essas pessoas ainda terão um emprego. Acredito inclusive que, na maioria dos casos, elas acabam com funções melhores e mais adequadas do que antes. Certamente pode acontecer de algumas pessoas ficarem frustradas por terem menos controle direto sobre colaboradores e decisões – às vezes tão frustradas que deixam a empresa.

Como nunca vi pessoas com determinadas funções ou habilidades serem simplesmente demitidas durante uma transformação ágil, acho que esse medo é tão descabido quanto o de um apocalipse zumbi.

5) Uhhh! No Scrum existem reuniões demais!

Como a maioria das pessoas, eu odeio reuniões. De modo geral, o que me importa é por que faço o que faço. Na maioria dos dias, não tenho reunião nenhuma. Que sorte.

Ainda assim, até eu consigo admitir que algumas reuniões são importantes e úteis. Isso inclui as quatro reuniões padrão do Scrum: a Reunião de Sprint Planning, o Daily Scrum, a Review e a Retrospectiva.

Só de pensar em todas essas reuniões, algumas pessoas já começam a suar.

E o problema com as reuniões do Scrum: elas têm um nome. Quando algo tem um nome, é mais fácil atacar. Na minha experiência, a maioria das equipes tinha mais reuniões antes do Scrum. Mas essas reuniões não tinham nomes e geralmente eram realizadas de forma espontânea para esclarecer determinadas questões.

Você pode verificar isso rapidamente com um experimento. Procure no seu calendário qualquer mês em que você ainda não trabalhava com Agile. Some o tempo que você passou em reuniões nesse mês. Depois some o tempo que você agora passa em reuniões do Scrum e compare os dois números.

Acredito que você ficará surpreso com o resultado. Como as reuniões da época antes da transformação ágil não eram realizadas de forma regular e recorrente, elas não tinham nomes e por isso também não ficavam na memória como, por exemplo, uma "Reunião de Sprint Planning".

A dica mais importante para não ter mais medo de passar tempo demais em reuniões é mantê-las curtas. De vez em quando trabalho com equipes que preciso incentivar a dedicar um pouco mais de tempo às suas reuniões.

A maioria das equipes, porém, passa tempo demais nas reuniões do Scrum. Assim que você conseguir mantê-las curtas e objetivas, elas não deveriam mais assustar ninguém.

Conclusão: Relaxa... esses fantasmas não são reais!

Andar por uma casa mal-assombrada e se fantasiar é divertido porque todos sabemos que é tudo de mentira. Os fantasmas, monstros, vampiros, lobisomens e loucos com motosserra não são reais.

E os cinco mitos ágeis descritos aqui também não são. Não há nada de errado em ter um pouco de medo no início. Mas conhecimento e experiência vão desmascarar esses mitos rapidamente e te dar uma sensação de segurança.

Se você quiser formar sua própria opinião sobre a realidade ágil e os mitos sobre Scrum & Co, dê uma olhada na nossa Agile Journey, onde apresentamos os papéis em detalhes, ou torne-se agora um Scrum Master certificado ou participe do nosso Treinamento de Agile Leadership.

Este texto é do blog de Mike Cohn e foi traduzido por nós para o alemão.

Inovação na empresa

=> O que caracteriza empresas inovadoras?

Estratégia Vivida

=> Descobre como levar a tua estratégia empresarial para um novo patamar.

Empresas Invencíveis

=> Como é a gestão moderna de inovação nas empresas?