E cá estou eu novamente, trazendo para você a segunda parte da minha série de artigos sobre as tendências em métodos e cultura de desenvolvimento de software para 2020. Minhas pesquisas tiveram como base o report publicado pela InfoQ em março deste ano, cujo gráfico você confere abaixo.
Nesta segunda etapa, vou explorar as tendências que recentemente foram criadas pelos inovadores e agora já estão dentro de um volume maior de empresas, as Early Adopters, mas que ainda não se tornaram mainstream. Esses métodos e cultura de trabalho ainda têm muito o que conquistar de espaço no mercado para conseguir cruzar o abismo que separa as empresas de ponta do restante e se firmarem como padrões de fato.
Mas deixando a conversa de lado, vamos analisar um pouco de cada um dos itens da coluna Early Adopters do gráfico de difusão de tendências.
Tenham uma boa leitura!
Atenção: partes deste artigo são iguais a outros que escrevi em 2019, como esse para o blog da BossaBox e esse para o site Startupi, pois algumas das tendências ainda se mantém.
Algumas partes são citadas por mim também na palestra abaixo, onde passo superficialmente por vários itens.
Early Adopters, Os Entusiastas
As empresas nesta faixa são aquelas que ainda são consideradas inovadoras por nós, meros mortais, mas que não criam tendências. Ao invés disso, o seu papel na cadeia de difusão da inovação é separar o “joio do trigo” como diriam nossos avós. Ou seja, a faixa de reais Innovators cria muita “maluquice” corporativa que só funciona no contexto delas e que muitas vezes não se espalha para o mercado, sendo que o que realmente dura são as práticas largamente adotadas pelos Early Adopters, que impulsionam tendências mais pragmáticas (mas ainda sensacionalmente disruptivas para os padrões tradicionais) para além do abismo (chasm) cunhado por Geoffrey Moore.
Resumindo: o que você lerá a seguir não é futuro utópico, é a realidade em muitas empresas de ponta e que um dia você pode ver como padrão de mercado se estiver empregado em uma boa empresa de tecnologia.
Joyful Workplaces
As melhores organizações reconhecem cultura como uma vantagem competitiva uma vez que conseguem criar um local onde as pessoas podem ser elas mesmas e encontrar prazer no trabalho que eles fazem, trazendo grande retorno para a empresa.
Querer transformar empresas sem a cultura estar alinhada com o objetivo desta transformação é um “tiro no pé” muito comum atualmente, em especial nas empresas de tecnologia que estão migrando de modelos de trabalho falhos para outros mais modernos, mas ainda falhos, uma vez que a cultura permanece a mesma, sendo o core do problema.
Quer leituras específicas sobre Joyful Workplaces? Comece com Joy, Inc e depois vá para Chief Joy Officer, ambos de Richard Sheridan, CEO da Menlo Innovations, uma das empresas de software mais inovadoras do mundo.
DevEx/Employee Experience
DevEx ou Developer Experience é basicamente, para mim, como se toda a empresa trabalhasse como um grande Scrum Master, removendo os impedimentos do time de desenvolvimento. Em uma tradução mais didática, Developer Experience é sobre tornar mais fácil e simples as atividades de desenvolver, liberar e operar software. É sobre identificar e remover qualquer coisa que crie fricção no processo de construir software.
DevEx entende que, conforme o mercado exige um patamar cada vez maior de exigências em termos de tecnologia e processos, os ciclos de desenvolvimento se tornam mais lentos e mais custosos devido à alta carga cognitiva e ao overhead de processos. A empresa deve investir em ferramental e automações capazes de permitir que os ambientes e os processos de desenvolvimento sejam tão fluidos quanto possível.
Nesse podcast você aprende mais sobre este tópico com a responsável pelo assunto no Netflix.
#NoEstimates
#noestimates, cunhada por Woody Zuill, é sobre a também famigerada cultura de estimativas de software. Defensores desta contra-cultura atestam que as empresas não precisam de estimativas, mas de visibilidade do andamento e conclusão das iniciativas (não vou chamar aqui de projetos para não me contradizer em relação ao tópico anterior). Métricas como Throughput, Lead Time e Cycle Time são opções para dar previsibilidade de entregas mesmo sem precisar estimá-las, apenas baseando-se no empirismo de entregas anteriores do time.
Claro que é mais fácil falar que fazer, e esse tipo de abordagem exige times mais estáveis (missões de longo termo) e tamanhos aproximadamente iguais de atividades para que técnicas como essas funcionem. Para mais sobre este tópico e uma abordagem prática sobre o assunto, leia o excelente NoEstimates: How To Measure Project Progress Without Estimating.
Business Agility
Recentemente tem-se falado muito que os métodos ágeis teriam morrido e que no lugar estaria a Business Agility ou Agilidade de Negócios. Enquanto eu acredite que seja apenas mais uma jogada de marketing de gurus que querem vender novas consultorias e romper com o antigo mercado de agilidade em software (de tempos em tempos isso acontece), é fato que existe um movimento forte de Business Agility acontecendo.
O termos se refere à habilidade de um sistema de negócio (ou organização) se adaptar às mudanças de mercado rapidamente, aproveitando ao máximo as oportunidades e os recursos humanos existentes. Ou seja, pegue o conceito de agilidade que há décadas é muito popular junto a times de software e coloque-o na empresa como um todo, indo além do desenvolvimento.
O que é muito curioso é que, com o avanço das transformações digitais em mais e mais empresas, elas tem-se dado conta que estão cada vez mais se tornando empresas de software que prestam seus serviços originais através de plataformas tecnológicas construídas dentro de casa. Olhando por esse prisma, é muito natural que elas passem cada vez mais a abraçar os valores da agilidade no dia a dia.
Team Self-selection
De acordo com o relatório anual The State of Agile, o desenvolvimento ágil de software se tornou mainstream nas empresas; com práticas como Scrum e Kanban largamente adotadas em maior ou menor grau por times ao redor do mundo. No entanto, práticas do Extreme Programming ainda são a exceção. Ao que parece, nós sabemos exatamente como construir softwares melhores, mas não temos o apetite por realmente empoderar os times e fazer as transformações necessárias para obter os mesmos benefícios que as empresas mais inovadoras do mundo obtêm dessas práticas.
Não apenas o XP, mas muitos frameworks promovem práticas verdadeiramente mais eficientes que os meios tradicionais e mesmo assim são ignorados. Uma dessas práticas é o Team Self-Selection ou Time Auto-Selecionável. Ao invés de gestores construírem os times, eles mesmo se constroem baseados nas suas competências individuais e na missão que está sendo proposta. Ao invés de apenas aspectos extrínsecos serem levados em conta (o que normalmente é a esfera de entendimento do gestor tradicional), o próprio profissional tem suas motivações e interesses respeitados, o que pode fazê-lo desejar ou não entrar no time que está se formando.
Se não sabe por onde começar, esse workshop aqui deve te ajudar. Agora se não acredita que isso é possível, saiba que em 2012 eu fazia isso na RedeHost, uma startup de Web Hosting e Cloud Computing do Rio Grande do Sul, e nem sabia que isso tinha um nome bonito.
Deliberate Culture Design
A cultura de uma empresa é um dos (senão o maior) patrimônio da mesma. No entanto, é extremamente curioso o quanto muitas empresas dizem se preocupar com a sua cultura e não fazem absolutamente nada para, deliberadamente, projetá-la rumo a um futuro próspero e saudável.
Deliberate Culture Design tem a ver com, intencionalmente, ajudar a forjar a cultura da sua organização em cima de valores sólidos, propósitos inspiradores e clareza do que podemos esperar ou não, enquanto clientes e funcionários dela. Trabalhos como o dos professores de Harvard, Kegan e Lahey, incentivam este tipo de abordagem ao invés de linhas mais tradicionais de pensamento que cultivam culturas emergentes ou orgânicas.
O fato é, e se a cultura emergente da sua empresa não for boa, você não faria nada para mudá-la?
Product Management over Product Ownership
Esta tendência parte do pressuposto que os métodos ágeis corrigiram muitos problemas do processo e cultura de desenvolvimento de software. No entanto, eles apenas arranharam a superfície da gestão de produtos. O product ownership pregado pelo Scrum é tão vago que ele não chega nem perto de conseguir resolver o grande problema de “desenvolver a coisa errada”.
Já escrevi aqui no blog sobre Product Manager vs Product Owner, inspirado em artigos do Roman Pichler, e gostaria de indicar hoje outra leitura dele, o livro How to Lead in Project Management. Ele foi entrevistado pela InfoQ recentemente.
Neste outro artigo, outro famoso gerente de produto, Jeff Patton, fala sobre como preencher este vazio do ownership com product management. Patton é o criador da famosa técnica de User Story Mapping, uma das ferramentas que acabaram inspirando o Lean Inception.
Enterprise Startups
Imagine que você fosse abrir uma startup, mas já contasse com a ajuda de consultores experientes, profissionais qualificados e…grana de uma empresa que estivesse patrocinando o seu negócio. Pois é, esse é o conceito por trás de Enterprise Startups. Grandes corporações tem feito spin offs de seus negócios em startups separadas, derivando iniciativas de maior risco ou que exigem maior velocidade de prototipação e/ou construção de MVPs.
Você acha que somente um dos lados está se beneficiando dessa conexão? Pensou errado. Lembre-se que 90% da startups falham e que 40% das maiores empresas do mundo deixarão de existir em 10 anos. Inovar não é algo opcional, e ser lento e burocrático demais está arruinando grandes negócios.
Ethics
Todo mundo já deve ter visto filmes futuristas cheios de tecnologia como “Matrix”, “Eu, Robô” e “O Exterminador do Futuro”, certo? O que esses filmes possuem em comum além do cerne distópico de suas tramas? Debates éticos sobre a relação homem-máquina.
Conforme a tecnologia avança em um passo assustador (ou empolgante, para os mais entusiastas), questões de ética em software têm-se tornado cada vez mais comum. Para dar apenas um exemplo, em uma situação de atropelamento iminente, quem um carro autônomo deve escolher para ser atingido? E o caso recente do sistema de estabilização da Boeing que nada mais é do que um assistente para o piloto?
Não é apenas uma questão de saber a quem culpar em casos como esses, mas sim de entender que conforme avançamos em tecnologias como Inteligência Artificial, Blockchain, Robótica, etc temos de entender o impacto social na vida das pessoas, o impacto no comportamento social humano, que é o núcleo da ética. Alguém lembra dos Ludditas? Pois é, se não discutirmos esses delicados tópicos propostos por ética em software, teremos uma reencarnação do Luddismo.
Mob Programming
Você se lembra do início dos anos 2000 quando o Extreme Programming causou estranheza mundial ao promover práticas como Pair Programming, onde dois programadores trabalham na mesma máquina, um de cada vez digitando, mas ambos concentrados? Pois é, Mob Programming é pegar esse conceito e levá-lo a outro nível, fazendo o time inteiro trabalhar no mesmo computador, para resolver uma única coisa ao mesmo tempo.
As origens desta prática remontam ao chão de fábrica japonês, quando se parava a linha de produção quando se encontrava algum defeito e todos trabalhavam para encontrar e corrigi-lo, para só então a fila continuar. Conceitos mais modernos, do Kanban de David Anderson, trazem o WIP Limit como um mecanismo para gerar esta tipo de comportamento do time se ajudar mais para resolver seus problemas ao invés de cada um fazer a sua parte e esperar que o todo seja entregue. Mesmo no XP, menciona-se a ideia e o próprio termo Mob Programming em Extreme Programming Perspectives que mais tarde seria melhor elaborado por Woody Zuill (sim, o mesmo do movimento #noestimates).
A prática pode ser utilizada para mais do que apenas codificação, mas também para trabalhos afins como especificação de requisitos (User Stories?), UX e muito mais. Quer você busque a solução de um problema, o compartilhamento de conhecimento (similar a um Coding Dojo) ou aumento na qualidade do software, existem vários motivos pelos quais você deveria estar usar essa e outras Mob técnicas, como Mob Testing.
Facilitation skills for technologists
Cada vez mais organizações e times de produto estão usando de práticas ágeis e técnicas de facilitação para desenvolver times mais ágeis, eficientes e inclusivos.
A percepção de quão importante a facilitação pode ser está aumentando rapidamente. Para atividades em time como retrospectivas ágeis, team building e refinamento de produto, é essencial que se tenha uma cultura segura. Bons facilitadores, aqueles que se demonstram neutros podem rapidamente melhorar o resultado de tais eventos e algumas das práticas em seus arsenais são core protocols, liberating structures, gamification, e self-selection.
Trabalho remoto, por exemplo, está em ascensão. Técnicas que são usados em times presenciais agora estão sendo adaptadas para uso em trabalho remoto e alguns exemplos incluem retrospectivas remotas, pareamento remoto, mob programming remoto, mob testing remoto, treinamentos e coaching online.
O número de certificações em métodos ágeis e pessoas buscando tais certificações está crescendo exponencialmente e as empresas tendem a incluir tais requisitos em suas vagas. No entanto, discute-se muito atualmente o valor destas certificações, uma vez que não provam as habilidades de seus detentores, o que faz parecer que a indústria da certificação tem se focado mais na quantidade e não na qualidade.
E com isso, encerramos a segunda parte desta série de artigos.
No próximo artigo, falaremos dos métodos e elementos culturais que já cruzaram o abismo, falaremos dos elementos já consolidados, que provavelmente você já está utilizando (ou deveria) e o que deve acontecer com eles nos próximos anos.
Até lá!
Quer um material de referência para Transformações Ágeis em empresas? Conheça meu livro sobre o assunto clicando no banner abaixo.
Olá, tudo bem?
O que você achou deste conteúdo? Conte nos comentários.