Categoria: Agile

Nesta quarta e última parte da minha série sobre as tendências em métodos e cultura de desenvolvimento de software para 2020 vamos explorar as duas últimas categorias de tendências segundo a pesquisa publicada pela InfoQ em março deste ano, cujo gráfico você confere abaixo.

Late Majority é, como o próprio nome diz, a maioria mais atrasada do mercado. Como bem apontado por G. Moore em Crossing the Chasm, não é apenas um crescimento comum de mercado sair do lado esquerdo da  Curva de Difusão da Inovação de E. Rogers para o lado direito. Existe um abismo que antecede a difusão de uma inovação de qualquer tipo para o grande mercado. Esse abismo se traduz como diferenças culturais gritantes entre os inovadores e os conservadores, se traduz no custo quando falamos de inovações em hardware e pode ser traduzido como também o “medo do novo”. Afinal, quem não lembra do medo de adotar métodos ágeis na primeira década deste século?

É importante ressaltar que, apesar de algumas tendências que você não conheça ou não pratique ainda estejam nesta última categoria, não as negligencie por elas não serem mais trendy. Scrum por exemplo, estar em Late Majority não indica que ele caiu em desuso, mas que sim, se tornou mainstream a ponto de estar sendo considerado como commodity em muitas empresas mais inovadoras e é uma tendência que acabara de chegar em empresas mais conservadoras.

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.

Late Majority, Antes tarde do que nunca…

E por fim, temos outra grande fatia do mercado que são a “maioria atrasada”. Você imagina descobrindo ou adotando hoje práticas e tecnologias dos anos 90? Pois é, estas empresas estão fazendo isso. Mas não julgue, não é uma questão de escolha, é uma forte pressão do mercado para que elas se modernizem.

Empresas que hoje, se recusem a entender a importância dos assuntos citados a seguir estão fadadas a caírem no ostracismo ou na categoria Laggards (retardatários), que a InfoQ nem mesmo perde tempo representando em seu gráfico. Apesar de estarem atrasadas, o fato de estarem olhando para estes assuntos já as põe em posição de se reinventarem, simbolizando uma luz no fim do túnel de negócios que possam estar estagnados e sofrendo com a forte concorrência.

Além disso, lembre-se que, todos estes assuntos já foram mega inovadores e são a base para entender o que veio depois deles. Pular etapas não é uma opção, na minha opinião, e se você ainda não domina eles, dificilmente conseguirá absorver os seus sucessores.

Scrum

O Scrum dispensa apresentações. Todas as pesquisas possíveis sobre métodos ágeis como a State of Agile e a State of Scrum mostram números gigantescos de adoção de Scrum nas empresas ao redor do mundo, superando 70% das empresas que dizem estar rodando algum método ágil.

Com isto, podemos dizer que o Scrum é o padrão de facto para desenvolvimento de software utilizando métodos ágeis e que toda empresa que estiver pensando em passar a desenvolver com agilidade deveria dar uma chance para este framework que já foi inovador e hoje se tornou mainstream.

Vanilla Agile

O termo Vanilla, na tecnologia, refere-se aos fundamentos de algo, fazendo uma alusão ao sabor de baunilha que é o mais genérico e básico possível dentre os sorvetes. Assim, Vanilla Agile refere-se à essência elementar da agilidade.

Aos poucos, mais e mais empresas estão descobrindo que ser ágil não é rodar Scrum. Estão descobrindo o Manifesto, descobrindo os princípios e incorporando um ou mais elementos no dia a dia.

O mais difícil, no entanto, tem sido elas não caírem em um GoHorse Gourmet como alguns estão chamando por aí. Ou seja, abrirem mão completamente de processos alegando que assim serão mais ágeis. Frameworks mais modernos como Modern Agile e Heart of Agile (este último criado por Cockburn, um dos signatários originais do Manifesto) tentam trazer um equilíbrio a essa nova situação que estamos vivendo, de descrença com algumas receitas e as armadilhas do Go Horse Gourmet.

Scaling Frameworks

Escalar métodos ágeis em grandes organizações é hoje uma arte que a todo custo estamos tentando transformar em ciência. Da adoção de agilidade pelo PMI à criação de grandes empresas em torno de frameworks como a Scaled Agile Inc, todos estão tentando resolver essa equação, de como escalar o ágil sem torná-lo outro waterfall.

Médias e grandes empresas que estão iniciando hoje suas transformações digitais tendem a assumir abordagens bimodais como a proposta do Gartner, enquanto outras tentam ir para o chamado “modelo Spotify” de escalar o ágil. Só o tempo dirá se teremos um vencedor ou se criaremos ainda outros modelos e receitas de escalar o ágil. O que não faltam hoje são opções além e SAFe e Spotify: Less, Scrum at Scale, Nexus, DAD, etc.

ALM Tools

ALM é uma sigla para Application Lifecycle Management ou Gestão do Ciclo de Vida de Aplicação. Do início dos anos 2000 para cá evoluiu-se muito em termos de ferramental para fazer a gestão das nossas aplicações. Com a popularização de arquiteturas mais modularizadas como microservices e nanoservices (serverless) e de tecnologias que elevaram essa modularização a um nível nunca visto antes, como Docker e Kubernetes, tivemos o surgimento de uma nova disciplina chamada DevOps, cada vez mais na boca dos profissionais de tecnologia de todas empresas.

Conceitos como Infra as a Code e Continuous Delivery não são mais “rocket science” e finalmente são objetivos alcançáveis a baixo custo. Absolutamente todas empresas que trabalham com software já ouviram falar disso e mesmo a categoria Late Majority deve investir pesado em pipelines e nuvem neste ano de 2020.

Cross-functional Teams

Agilidade é sobre times e quando se fala de times ágeis a primeira coisa que vem em mente é a pluralidade de habilidades. Times cross-funcionais ou multi-funcionais são aqueles que possuem todas as competências necessárias para entregar uma solução fim-a-fim (os chamados Feature Teams). É o contraponto à organização tradicional de times em silos, onde temos os especialistas de cada tecnologia ou camada de aplicação em cada silo, gerando extrema dependência de um time do outro e desacelerando a possibilidade de entregar valor em um lead time mais curto.

No famoso artigo de 1986 de Takeuchi e Nonaka, The New New Product Development Game, já se falava do poder que os times multi-funcionais estavam trazendo às empresas que adotavam esse modelo de trabalho à época. Não à toa que esse artigo inspirou o desenvolvimento do framework ágil Scrum, trazendo o conceito de time esportivo (rugby nesse caso) ao mundo do software, onde são necessárias diferentes habilidades em um mesmo time para conseguir vencer a partida. Já imaginou ter um time de futebol com 11 atacantes? Será que ele venceria todas partidas? E porque algumas empresas ainda insistem em ter times com apenas programadores de backend ou frontend? Ao menos a grande maioria já entendeu isso, segundo a pesquisa da InfoQ.

Justamente uma das principais competências trabalhadas na BossaBox é a construção de times multi-funcionais para atender às necessidades de desenvolvimento dos clientes, pois entende-se que esse é o caminho para a agilidade na entrega de valor.

E com essa quarta parte nós encerramos esta série sobre tendências em métodos e cultura de desenvolvimento de software para 2020. De forma alguma esta série cobriu tudo o que está acontecendo neste mundo de TI, e nem mesmo deu uma compreensão aprofundada de cada um dos tópicos apresentados. E a ideia nem era essa.

Se você terminou de ler com o sentimento de que tem muita coisa para aprender ainda, pois é, somos dois e estou muito feliz que eu não seja o único. Esse era meu objetivo principal: tirar você da incompetência inconsciente para a incompetência consciente. Agora com essa to-do list de coisas a estudar, espero que possa se antever às mudanças que estão chegando, além é claro de buscar o que pode ter deixado para trás por descuido.

Um abraço e até a próxima!

Quer um material de referência para Transformações Ágeis em empresas? Conheça meu livro sobre o assunto clicando no banner abaixo.

Nesta terceira parte da minha série sobre as tendências em métodos e cultura de desenvolvimento de software para 2020 vamos explorar a penúltima categoria de tendências segundo a pesquisa publicada pela InfoQ em março deste ano, cujo gráfico você confere abaixo.

Early Majority é, como o próprio nome diz, a maioria do mercado mais ligada em inovação. Como bem apontado por G. Moore em Crossing the Chasm, não é apenas um crescimento comum de mercado sair do lado esquerdo da  Curva de Difusão da Inovação de E. Rogers para o lado direito. Existe um abismo que antecede a difusão de uma inovação de qualquer tipo para o grande mercado. Esse abismo se traduz como diferenças culturais gritantes entre os inovadores e os conservadores, se traduz no custo quando falamos de inovações em hardware e pode ser traduzido como também o “medo do novo”. Afinal, quem não lembra do medo de adotar métodos ágeis na primeira década deste século?

É importante ressaltar que, apesar de algumas tendências que você não conheça ou não pratique ainda estejam nesta penúltima categorias, não as negligencie por elas não serem mais trendy. 

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 Majority, Os Pragmáticos

Empresas nesta categoria são o grande filão do mercado, empresas que acabaram de perceber o que de fato está acontecendo com o desenvolvimento de software e, uma vez que muitas das empresas que eles admiram (innovators e early adopters) estão comprovadamente tendo sucesso na adoção de novas práticas, passam a adotá-las também.

Empresas pragmáticas não seguem tendências até que elas tenham cruzado o abismo, ou seja, que tenham se provado ao longo de algum tempo em diversas outras empresas. Na atualidade, são todas aquelas empresas que estão passando por transformações digitais, por exemplo, mas que em sua maioria não nasceram de tal forma.

Remote-Only Teams

Times remotos. Atire a primeira pedra qual desenvolvedor de software nunca sonhou trabalhar de casa ou de qualquer outro lugar do mundo. Existem empresas com políticas flexíveis para homeoffice e existem empresas que de fato abraçaram o jeito remote-only de se trabalhar, como a BossaBox (que atua justamente na mediação dessa relação) e outras mais icônicas como Basecamp (que inclusive lançou um livro específico sobre o assunto).

Para os desenvolvedores, a flexibilidade de horário, a economia de tempo com o commuting, a ausência de dress code, silêncio, seu café e suas regras de Internet, são alguns dos benefícios, além da tão almejada geoarbitragem (gastar em Reais e ganhar em dólares ou outra moeda forte).

Para a empresa, redução de custos com infraestrutura, maior facilidade de atrair talentos de todos os cantos do mundo e, para empresas globais, a tão sonhada produtividade 24×7 (profissionais em diferentes fusos gerariam um fluxo de trabalho ininterrupto 24h por dia).

Obviamente existem desafios, mas hoje, com a situação mundial da pandemia do Covid-19, absolutamente todas empresas que desenvolvem software já estão praticando o home office e até o desenvolvimento de projetos de todos os tamanhos usando times remote-only. 

Pragmatic Agility

Pragmatismo é a palavra-chave que separa os Early Adopters da Early Majority, certo?

Nada é mais pragmático do que olhar a agilidade com um viés de “caixa de ferramentas” e, dadas as suas necessidades, escolher aquelas mais se adequem às suas necessidades. A velha guerra das metodologias, que ainda não acabou, não produz nada de benéfico uma vez que as pessoas parecem tender a uma “futebolização” dos métodos, como se eles estivessem no mercado para competir uns contra os outros. Perguntas como: qual o melhor, Scrum ou Kanban? não possuem uma única resposta, a não ser que você esteja perguntando a um dos muitos “especialistas” que costumam ser vendedores da empresa A ou B.

Agilidade é sobre reagir à mudança. O Manifesto não fala nada sobre seguir uma única cartilha como se ela fosse a verdade universal.

Craftmanship

Craftsmanship é um termo apresentado em 2000 no livro Software Craftsmanship de Pete McBreen e propõe uma nova abordagem de ver o desenvolvimento de software, mais ligada ao artesanato do que a uma fábrica de software. McBreen disserta muito sobre essa ser uma profissão onde se evolui na base da mentoria, como os antigos artesão faziam, e não de maneira formal. De que não temos como aplicar a mesma solução para problemas diferentes, o que faz com que cada projeto seja único, como uma obra de arte. O que temos em comum entre eles? Princípios de desenvolvimento.

Fortemente baseados nestes princípios, os software craftsmen ou apenas crafters, constroem uma solução adequada para o problema do cliente, de maneira extremamente pragmática, utilizando as melhores ferramentas para o problema em questão e jamais o contrário. Colocar a tecnologia antes do problema é o primeiro passo para o fracasso técnico de um projeto.

Mais tarde, Robert C. Martin (Uncle Bob), levou adiante esses conceitos carregando muito do discurso de craftsmenship em suas obras e dissertações como Clean Code, Clean Architecture e na construção do SOLID. Por vezes Bob é assumido como idealizador do movimento, mas não o é como ele mesmo admite.

É importante ressaltar que, apesar do ‘man’ no nome, a ideia não é gerar exclusão de gênero. O termo craftsperson tem sido mais utilizado hoje em dia por ser mais inclusivo neste sentido.

BDD/DDD

Behavior Driven Development (BDD) e Domain Driven Design (DDD) são duas siglas técnicas muito populares no meio de desenvolvimento de software tem vários anos e não cabe a mim tentar explicá-las no detalhe em um artigo como esse, então me aterei a resumi-las, para fazer você ter uma ideia do motivo pelo qual as empresas pragmáticas estão adotando-os este ano.

O Desenvolvimento Orientado a Comportamento (BDD) criado por Dan North, é tida por muitos como uma evolução do TDD (Desenvolvimento Orientado a Testes). Não apenas uma mudança no hábito de programar, partindo dos testes, mas uma mudança no jeito de pensar especificação de software (de maneira colaborativa entre análise, desenvolvimento e testes) e construção do mesmo baseado no que esperamos que os usuários façam no sistema. Afinal, construímos os sistemas para eles, e não para nós, não é mesmo?

Já o Desenvolvimento Orientado a Domínio (DDD) criado por Eric Evans, é uma abordagem de desenvolvimento de software focada no domínio da aplicação. Um domínio pode ser uma atividade-chave ou uma área de conhecimento, por exemplo, o que quer dizer que o software deve se focar em atender a esse domínio acima de tudo.

Estas duas práticas tem muito a ver como a maioria das empresas de mercado tem se reinventado na forma de vender seus serviços e de projetar seus softwares, de maneiras mais centradas nas necessidades e satisfação de seus clientes e objetivos de negócio. BDD e DDD ajudam muito neste sentido.

Coaching/Mentoring

E meio a tantas hard skills dentro das corporações, duas soft skills têm ganhado muita popularidade nos últimos anos: coaching e mentoring, em especial a primeira.

Eu falei bastante de coaching no primeiro capítulo desta série. Já o mentoring é o processo de ajudar um indivíduo com orientação em uma área de conhecimento específica, de domínio do mentor. Um mentor é um profissional experiente em um determinado campo de estudo ou competência que ajuda seu aprendiz a não cometer os mesmos erros, a aprender mais rápido e a ter resultados parecidos com os seus ou até melhores. Note que na maioria dos casos o mentor já trilhou o caminho que o aprendiz está trilhando naquele assunto, sendo um profissional procurado em busca de respostas.

Processos de mentoria e coaching estão cada vez mais comuns em empresas de todos os tamanhos. É uma resposta rápida para acelerar o crescimento dos profissionais, o atingimento de metas e até mesmo para práticas mais modernas de gestão e desenvolvimento de pessoas. Não à toa, caiu nas graças da grande maioria das empresas modernas. 

Curiosamente, o Agile Coach, papel cada vez mais comum em empresas passando por transformações digitais, tem um pouco dos dois: ele é um mentor de agilidade e um coach de pessoas. 

Full-Stack Product Teams

Se temos uma máxima em times ágeis é que eles precisam ser multi-funcionais, certo? No entanto, o que mais se vê por aí são os times pseudo-multi-funcionais, ou seja, que possuem todas as skills de programação presentes mas pecam no restante do ciclo de desenvolvimento do produto quando se olha o todo. Afinal, quem dá o suporte ao produto? Quem faz o marketing do mesmo? Quem mantém a infraestrutura operando e monitorada? Entre outras tantas questões.

Dos clássicos times multifuncionais da Toyota ao vídeo do Spotify Engineering Culture, não é de agora que se fala da necessidade de se quebrar silos e construir esse tipo de time. Nesse artigo você encontra dicas práticas de quem já está fazendo isso. Nesse outro, o que se espera de um profissional full-stack de produto. Já esse outro questiona se isso é viável ou mesmo necessário, afinal, precisamos de pontos de vista diferentes, não é?

DevSecOps

No passado nós tínhamos dois departamentos muitas vezes rivais dentro da TI: desenvolvimento e infraestrutura/operações. Eram disciplinas e cultura completamente diferentes, havia pouca colaboração e cada cuidava apenas do seu “quadrado”.

Então surgiu a cultura DevOps e seu conjunto de ferramentas que tornaram a cultura de operação (Ops) mais próxima da desenvolvimento (Dev) e vice-versa. Com as tecnologias cada vez mais Cloud Native por causa da containerização/Dockerização de tudo, surgiram termos como Infra as a Code (Infraestrutura como Código), onde os servidores são “programados” ao invés de “configurados na mão”, versionamento de bases de dados assim como se fazia com código de programação, testes por todo lado, deploy com um clique e muito mais.

Mas e quanto à segurança disso tudo? Não lhe parece que tem gente demais “metendo a mão” nos servidores? Não estariam estas ferramentas de DevOps abrindo brechas de segurança nos ambientes? Não estaríamos deixando segregado outra disciplina importantíssima de TI que é a segurança?

É com este pensamento que o termo se adequou para DevSecOps, englobando a segurança no dia a dia dos times de solução, afinal, o freio não é colocado no final da linha de produção do carro, não é mesmo?

Para saber mais sobre DevSecOps, sugiro começar por esse material aqui.

Digital Transformation

Esse é um termo que está cada vez mais famoso no Brasil, certo? Mesmo por aqui, Transformações Digitais estão eclodindo em todas grandes empresas que não querem ficar de fora da profusão de matérias sobre o tema e da atenção dos investidores. No entanto, ser digital está longe de apenas informatizar processos manuais e trocar tecnologias, exige um redesenho da organização e uma evolução de sua cultura, dois elementos muito mais delicados.

A questão é que transformações de negócios, de qualquer tipo, são extremamente custosas e arriscadas. Para um negócio se tornar digital, não basta adicionar uma camada de tecnologia, você tem de inserir a mesma nas entranhas das camadas já existentes. Não é algo que você resolve investido no departamento de TI da empresa, mas distribuindo a TI por toda a empresa. Ou então o contrário, distribuindo business por toda TI. Não importa.

A InfoQ construiu um Framework de Transformação Digital que, caso você esteja passando por isso ou planeja passar em breve, vale uma leitura, para jogar um pouco mais de luz sobre o assunto e organizar uma virada menos dolorida. Eu traduzi partes dele aqui no blog.

E com isso, encerramos a terceira parte desta série de artigos.

No próximo e último artigo da série (clique para ler), falarei dos métodos e elementos culturais que já chegaram até mesmo na maioria tardia, elementos extremamente consolidados e que se você não conhece ou não aplica, atenção!.

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.

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.

Clique aqui para ler.

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.