Cultivando Squads – Dicas Práticas para Gerentes de Projeto e Líderes Técnicos

Conversando com um colega do mundo ágil, ouvi um relato interessante sobre um time que estava buscando introduzir práticas ágeis e foi denominado como um “Squad”. No meio de uma retrospectiva em uma sprint onde a performance foi baixa, uma analista que estava particularmente irritada começou a trazer incômodos pessoais e sugestões para o time aprender com alguns erros. No meio da sua fala essa pessoa foi abruptamente interrompida pelo gerente do projeto, que o repreendeu em público pela sua postura negativa. Esse comportamento se repetiu algumas vezes e gerou as seguintes consequências nessa analista: (1) medo de se posicionar publicamente, (2) silêncio sepulcral nas reuniões, (3) desmotivação e depois de alguns meses (4) demissão voluntária da empresa onde ela trabalhava. Ao ouvir esse relato, comecei a me lembrar dos casos similares que também presenciei em empresas onde trabalhei. E também de como também pude experimentar na pele esse sentimento em uma empresa cujo modelo gerencial era bastante autocrático.

Squads não são apenas pessoas trabalhando juntas. Existe uma grande diferença entre um grupo de trabalho e times de alta performance, que reside no conhecimento e aprendizado que emerge das relações entre os seus indivíduos. Esse conhecimento emergente cria uma dinâmica poderosa e permite que o desempenho do todo seja maior que as partes individuais. E essa dinâmica é necessária para conseguirmos operar em ambientes complexos. [1]

Diversas empresas tem aprendido que que a formação de times de alta performance depende da promoção da segurança psicológica e do estabelecimento de clareza de propósitos.

A segurança psicológica é a crença compartilhada pelos membros de uma equipe que a equipe é segura para assumir riscos interpessoais. Em outras palavras, é uma crença que as pessoas não serão repreendidas ou humilhadas por trazer ideias, questões, preocupações e por simplesmente errarem. Afinal, errare humanum est! 

Pesquisadores de eficiência organizacional na Google descobriram que indivíduos em equipes com maior segurança psicológica são menos propensos a sair do Google, são mais propensos a aproveitar o poder de ideias  diversas de seus companheiros de equipe, trazem mais receita e são classificados como duas vezes mais eficazes por seus líderes. [2]

A clareza de propósitos é a garantia que o time esteja plenamente alinhado sobre qual o propósito do trabalho sendo realizado e os mecanismos necessários para realizar esse trabalho. A esse respeito, um interessante relato de caso da gerente de engenharia de infraestrutura da empresa Slack mostrou que conflitos não construtivos normalmente ocorriam quando pessoas tentavam resolver problemas diferentes quando eles acreditavam que se tratava do mesmo problema. Quando temos clareza de propósito, as chances aumentam para que a agenda seja dominada pelos conflitos construtivos, que é muito saudável para o crescimento das pessoas e times.

A figura abaixo resume os nossos objetivos então, que são: (1) promover alta segurança psicológica e (2) criar clareza e alinhamento de propósitos. Sem um desses fatores, teremos times ineficientes, desmotivação trazida pelo modelo comando e controle ou anarquia.

Squads são times de alta performance. E três fatores críticos para isso requerem que o gerente:

  1. Enquadre o trabalho do seu time como um problema de aprendizagem, não um problema de execução. Sabemos que projetos dominados por alta atividade intelectual tem um alto nível de incerteza e variabilidade [1]. Se você, como gerente, cria um ambiente que tolera erros e que os erros são usados para melhorar o sistema, você incentiva que as pessoas se manifestem. Não à toa, a pesquisadora Amy Edmonson [3] mostrou que hospitais com times mais eficientes reportaram taxas de erros maiores que hospitais menos eficientes. Isso desafia o senso comum, e é um relato que atividades complexas como a gestão hospitalar requerem uma abordagem de aprendizado e experimentação, mais que um problema de planejamento e execução.
  2. Reconheça sua própria falibilidade. Ao fazer isso, você demonstra humildade e encoraja que pessoas argumentem livremente com você e com seus pares.
  3.  Estimule a curiosidade e faça muitas perguntas. Incentivar uma cultura de perguntas vai estimular diálogos e o aprendizado organizacional.

Finalmente, listo abaixo dicas gerenciais atestadas na prática de várias empresas que estão correlacionados com a criação de ambientes que estimulam a segurança e estão relacionados com a efetividade de times.

  1. Demonstre engajamento
    ● Esteja presente e concentre-se na conversa. Por exemplo, não fique lendo email durante reuniões. Isso passa uma mensagem ruim para as pessoas que estão tentando serem ouvidas.
    ● Faça perguntas com a intenção de aprender com seus colegas de equipe.
    ● Ofereça informações, seja interativo e mostre que você está ouvindo.
    ● Responda verbalmente para mostrar engajamento (“Isso faz sentido para mim. Conte-nos mais. Pode me dar um exemplo.”).
    ● Esteja ciente de sua linguagem corporal; certifique-se de inclinar-se para a pessoa que está falando, mas sem parecer agressivo.
    ● Faça contato visual para mostrar conexão e escuta ativa
  2. Mostre compreensão
    ● Recapitule o que foi dito para confirmar o entendimento e alinhamento mútuo (por exemplo, “O que eu entendi foi…”).
    ● Reconheça áreas de concordância, discordância e esteja aberto a perguntas dentro do grupo.Valide os comentários verbalmente (“Eu entendi”. “Eu compreendo o que você está dizendo”.)
    ● Evite atribuir culpa (“Por que você fez isso?”). Ao invés, concentre-se nas soluções. “Como podemos trabalhar para evitar esse problema da próxima vez? ”.
    ● Pense nas suas expressões faciais. Elas são involuntariamente negativas? Estudos já mostraram que cerca de 70% da nossa comunicação é expressa pela linguagem corporal.
    ● Acene com a cabeça para demonstrar compreensão durante conversas e reuniões
  3. Seja inclusivo nas relações interpessoais
    ● Compartilhe informações sobre seu estilo de trabalho pessoal e preferências e incentive colegas de equipe a fazer o mesmo. Pessoas são diferentes e entender essas diferenças é importante para criar ambientes produtivos.
    ● Esteja disponível e acessível aos colegas de equipe (por exemplo, reserve tempo para conversas um-para-um ou conselhos de carreira).
    ● Expressar gratidão pelas contribuições da equipe.
    ● Intervenha se os membros da equipe falarem negativamente sobre outro membro da equipe.
    ● Tenha postura corporal aberta (por exemplo: não vire as costas para parte do grupo).
    ● Construa rapport (por exemplo, converse com seus colegas de equipe sobre suas vidas fora do trabalho ou afinidades além do trabalho).
  4. Seja inclusivo na tomada de decisões
    ● Solicite opiniões e comentários de seus colegas de equipe.
    ● Não interrompa nem permita interrupções (por exemplo, intervenha quando alguém é interrompido e garanta que as ideias de todos sejam ouvidas).
    ● Explique o racional por trás de suas decisões (i.e., mostre para a equipe como você chegou a uma decisão)
    ● Reconheça a opinião de outras pessoas (por exemplo, destaque quando os membros da equipe contribuíram para o sucesso de entregáveis)
  5. Mostre confiança e convicção sem parecer inflexível
    ● Gerencie discussões em equipe (por exemplo, não permita conversas paralelas em reuniões da equipe, verifique se o conflito não é pessoal)
    ● Use uma voz clara e audível em um ambiente de equipe
    ● Apoie e representar a equipe (por exemplo, compartilhe o trabalho da equipe com a liderança sênior e dê crédito aos colegas de equipe)
    ● Convide a equipe a desafiar sua perspectiva.
    ● Incentive os colegas de equipe a assumir riscos e demonstrar riscos em seu próprio trabalho

 

Referências

[1] Snowden, David. “Cynefin: a sense of time and space, the social ecology of knowledge management.” (2000).

[2] Edmondson and Lei (2014). “Psychological Safety: The History, Renaissance, and Future of an Interpersonal Construct,” Annual Review Organizational Psychology. Um vídeo excelente no TedTalk com o relato dos hospitais está disponível aqui no YouTube.

[3] Mendes, Marco.  O que faz o gerente na minha Squad?

Afinal, o que faz o gerente na minha Squad?

O modelo de Squads advoga que você aproxime as pessoas que estejam no núcleo da entrega e sustentação de seus produtos de negócio. Essas pessoas trabalham juntas em forte cooperação técnica, fazem uso de métodos ágeis como Kanban, Lean, Scrum ou LESS e entregam produtos para os seus usuários com boa frequência.

Ao mesmo tempo, as Squads são constituídas sobre estruturas organizacionais já existentes. E nessas estruturas temos muitos gerentes, dispostos em silos funcionais e com receio que alguém mexa em seus domínios.

Ouvi recentemente a dúvida de um gerente de uma dessas empresas com muitos gerentes.  – “Qual o papel do gerente nas Squads?”.

Como a pergunta não tem uma resposta trivial ou única, compilo aqui algumas respostas que o mercado tem trazido para essa questão.

O Gerente em Projetos Tradicionais

Tradicionalmente, os gerentes estão frequentemente envolvidos em decidir qual é o trabalho a ser feito e estão também envolvidos na decisão de como fazê-lo.  Entretanto, gerentes não são necessariamente excelentes analistas de negócio. E ao usar o seu poder para decidir qual o trabalho deve ser feito, eles podem deixar escapar a oportunidade de aplicar a melhor engenharia de valor em seus produtos.

Gerentes também não são normalmente excelentes técnicos e ao tentar dizer como um técnico deveria fazer o seu trabalho eles realizam micro-gerenciamento. Microgerenciar pessoas está correlacionado com frustração, desmotivação e até mesmo demissões voluntárias.

O Gerente nos Métodos Ágeis 

Nos métodos ágeis, o papel do gerente não é mais responsável por definir qual é o trabalho a ser feito. A decisão sobre o que a equipe deveria trabalhar não está mais sob o controle do gerente, mas é decidida pelo Dono do Produto. Ele tem uma visão geral do produto e o que é mais valioso para os clientes. E portanto ele prioriza o trabalho que a equipe deve fazer.

E o papel do gerente nos métodos ágeis também não é responsável por definir como um trabalho vai ser feito. A decisão sobre como a equipe deve funcionar é delegada à equipe. A equipe é uma equipe de autogerenciamento e, juntos, precisa refletir sobre o que deve ser feito e decidir como farão isso e como vão melhorar continuamente o seu trabalho.

Mas, então, o que o gerente deve fazer?

O papel da gerência intermediária é enxergar o todo e melhorar a capacidade da organização em construir produtos de excelente qualidade. Ele deve ajudar a equipe e o Scrum Master na remoção de obstáculos e melhorias. Ele deve ensinar a equipe a melhorar e como resolver seus próprios problemas. Ele deve ir e ver (Genchi Genbutsu) para entender o que realmente está acontecendo no local de trabalho, e ver como ele pode ajudar melhor a equipe a melhorar seu trabalho.

O papel da alta administração é menos alterado, pois ainda estão envolvidos com decisões estratégicas relacionadas à empresa e seus produtos. Ao mesmo tempo, é também o papel da alta gerência  ensinar aos gerentes intermediários como ensinar as pessoas. Ele também precisam ajudar seus subordinados na resolução de problemas e como podem se tornar melhor no treinamento dos seus times.

O Gerente nas Squads – O Que Tenho Observado

Modelo 1 – Gerente Como Dono do Produto

Em muitas empresas, os gerentes intermediários são pessoas centralizadoras devido à cultura gerencial instalada. E nesse tipo de cenário tenho visto gerentes acumulando também o papel do PO. Isso dá a eles autonomia sobre o que fazer sem violar práticas de métodos ágeis como o Scrum.

O risco aqui é que o gerente simplesmente use o seu bom senso para trabalhar a priorização do produto. Não à toa, o próprio PMI reconheceu a importância dos gerentes conhecerem mais sobre os seus produtos de negócio, realizar engenharia de valor e usar técnicas provadas de análise de negócio. A certificação de Analista de Negócio do PMI é um movimento nessa direção e hoje já existem excelentes cursos de pós-graduação para a formação de analistas de negócio.

Modelo 2 – Gerente Como Scrum Master

Para Squads menores e onde o gerente tenha um domínio técnico do assunto sendo tratado pude já observar o gerente assumindo também o papel do Scrum Master.

Isso pode ser positivo para limpar impedimentos em organizações muito hierarquizadas, onde o crachá gerencial é fundamental para conseguir ajuda de outras áreas.

Existe aqui o risco do gerente atuar como um decisor técnico e inibir o desenvolvimento do time. E nesse modelo devemos ter extremo cuidado para não reforçar ou manter os cacoetes de microgerenciamento.

Modelo 3 – Gerente Como Agile Coach da Tribo

Nesse modelo o gerente se desapega do trabalho operacional e começa a atuar como um construtor de capacidades do time no nível da tribo. Com isso ele consegue atuar em várias Squads e estabelecer uma consistência do trabalho.

Realizar esse trabalho é árduo e requer uma mudança nos modelos mentais preestabelecidos. No nível gerencial, a principal função a ser buscada é desenvolver pessoas. E no nível do time, a principal função a ser buscada é operar como uma unidade autogerenciada de alta performance  e que busque melhorias contínuas no seu processo de trabalho.

Existe um risco no exercício dessa função que lida com o paradigma de gestão. Pessoas não devem ser gerenciadas. Ao invés, o gerente deve cuidar do sistema em torno das pessoas e nos incentivos que irão permitir que as pessoas se motivem. E não falo aqui de incentivos financeiros. Para trabalhos de natureza intelectual, já foi demonstrado que o aspecto mais importante na motivação de pessoas é a autonomia na tomada de decisões.

Vamos tomar um exemplo de uma ideia gerencial que parece ser boa mas que pode ser usada de forma inadequada, que são as reuniões individuais de acompanhamento. Se o gerente usa as reuniões um-para-um para estabelecer objetivos individuais e posteriormente solicita atualizações de status para as pessoas ele estará apenas reforçando o relacionamento superior-subordinado que é típico nas organizações de comando e controle.

Everyone should learn how to manage the system, not the people, Jurgen Appelo

Quando um gerente decide atuar como Agile Coach, ele deve usar práticas gerenciais que:

  • envolvam as pessoas e promovam as suas interações;
  • permitam ao time melhorar o sistema;
  • ajudem a engajar e aproximar os clientes do time e do produto sendo construído.

Uma prática gerencial importante e que atende a essas condições são retrospectivas.  Um outro exemplo é a prática Vá Ver (Genchi Genbutsu), que permite que os gerentes acompanhem os seus times no trabalho real e possam discutir formas de melhorar o sistema.

O portal do Management 3.0 traz uma excelente coleção de práticas que atendem aos requisitos acima e pode ser usada para que gerentes migrem do nocivo modelo comando e controle (Management 1.0) para um papel mais próximo ao de coaches.

Modelo 4 – Simplesmente Reduzir o Número de Gerentes na Organização

Quando olhamos as organizações que migram de modelos hierárquicos e silos funcionais para o modelo de squads, observamos que algumas gerências simplesmente deixam de existir.

Vou trazer um exemplo no contexto de QA e testes de software. Em empresas hierarquizadas, temos gerentes de testes que chefiam um pool de pessoas e gerenciam filas de requisições para prestar serviços de verificação e validação de sistemas para outras áreas da organização. Quando operamos por Squads, os analistas de testes estão agora dentro das Squads. E agora os próprios analistas de testes se reunem periodicamente (ex. comunidade de práticas de testes) para realizar retrospectivas do seu trabalho e também para desenvolver a competência organizacional de testes na organização.

Esta visão vai na direção da descentralização gerencial e que é bastante enfatizada por Neils Pflaeging no seu excelente livro – Organizar para a Complexidade. E o mantra aqui é: Mais Gestão, com Menos Gerentes.

Captura de Tela 2018-06-28 às 00.55.58


 

 

Como operacionalizar Squads na sua empresa

O conceito de Squads foi popularizado na Spotify ainda em 2012 e tem sido experimentado em muitas empresas Brasileiras como um facilitador para a escalar a agilidade.

Squad (do francês: esquade)

Um Squad é semelhante a um time Scrum, mas é projetado para se sentir como uma mini-startup. Eles se sentam juntos e têm todas as habilidades e ferramentas necessárias para projetar, desenvolver, testar e  liberar aplicações para produção. Eles são uma equipe auto-organizada e decidem sua própria maneira de trabalhar – alguns usam sprints do Scrum, alguns usam o Kanban, alguns usam uma mistura dessas abordagens.

Se o termo ainda é novo para você e você gostaria de estabelecer uma fundação conceitual, recomendo a leitura do excelente artigo de Henrik Kniberg & Anders Ivarsson  publicado ainda em 2012.

Nesse post, vou discutir algumas das implicações da adoção de Squads e como lidar com isso na sua realidade.

DESAFIO 1: Orientação por produto e os desafios com o PMO da sua organização

Em empresas tradicionais, times são mobilizados através de projetos. A criação de um projeto é o que forma um time. E quando um projeto termina o time é desmobilizado.

Quando falamos de Squads, buscamos times permanentes que constroem e sustentam produtos de negócio. Enquanto o produto de negócio existir, haverá uma ou mais Squads que irão cuidar desse produto de negócio.

Observe que temos aqui uma impediência entre a nova linguagem (de produtos) versus a linguagem antiga (de projetos). E como podemos lidar com essa diferença?

Algumas abordagens para lidar com essa questão incluem:

  1. Operar abaixo do radar do PMO (mais conservadora).

    Quando você tem um PMO muito arcaico ou resistente, pode ser impossível buscar uma mudança de abordagem.Operar abaixo do radar implica que você possui Squads internamente dentro da sua TI com o propósito de evoluir produtos de negócio, mas a linguagem de comunicação com a empresa e interessados de negócio ainda será a linguagem de projetos. Isso exige que você faça uma prospecção ativa de projetos para conseguir garantir a orçamentação do seu Squad ou de pelo menos uma parte das pessoas do seu Squads.  Isso pode implicar em que sua Squad precise cuidar de mais de um produto para que seja possível financiá-la.
  2. Negociar a orçamentação anual por produtos de negócio, mas estabelecer uma lógica de desembolso centrada em projetos.

    Nessa abordagem o PMO tem ciência dos Squads e do seu propósito. E ao mesmo tempo você não quer mudar a lógica de funcionamento de um PMO, que poderia gerar muita resistência. Em conjunto, vocês e a diretoria buscam estabelecer um limite orçamentário para um produto ao longo de um ano fiscal. E esse orçamento será investido através de projetos do PMO que irão financiar uma Squad durante esse ano fiscal.Observe que nessa abordagem não basta medir o sucesso financeiro baseado em métricas míopes de projetos como o CPI ou SPI. Devemos ir além e medir o retorno financeiro trazido para a organização no investimento em um produto de negócio. Squads devem ser medidas, primordialmente, pelos resultados de negócio que seus produtos trazem.

  3. Transcender com o conceito de projetos. #NoProjects  (mais agressiva).

    Algumas empresas  sublimaram o conceito de projetos e trabalham com o conceito de fluxo continuado de valor de negócio. Nessa abordagem você estabelece em base periódica (ex. trimestre) uma orçamentação para uma Squad. Você prioriza os itens mais importantes do bacilo que cabem naquele período de tempo. E você mede periodicamente como foi a agregação de valor de negócio por essa Squad. Se a agregação de valor foi frutífera, você coloca mais investimento naquela Squad. Se os resultados na perspectiva de negócio são ruins, você desmobiliza a Squad e reorienta o seu dinheiro para onde fizer mais sentido.O excelente eBook chamados #NoProjects , publicado em 2016, traz casos reais e como esse polêmico princípio poderia ser discutido em organizações mais ousadas.

DESAFIO 2: Construção e Sustentação de Produtos

Em empresas tradicionais, a área de desenvolvimento desenvolve produtos. E uma outra área, chamar de sustentação, sustenta produtos. Isso parece natural, mas é uma dicotomia que gera um sistema de incentivos que leva que:

  • uma parte das pessoas busque entregar código o mais rapidamente possível em produção, mesmo que seja lixo.
  • e uma outra parte que é paga para atender incidentes em produção.

Esse modelo cria dedos apontados para os “culpados” pelos problemas de qualidade e incidentes.

Em Squads, temos um time que cuida do desenvolvimento de novas funcionalidades e da sua sustentação. Mas isso não é fácil. Isso exige muita maturidade.

Algumas abordagens que podem ajudar na implementação desse modelo incluem:

  1. Possuir uma pessoa dedicada para sustentação na Squad (mais conservadora)

    Temos aqui em uma Squad uma ou mais pessoas que irão cuidar da evolução do produto na perspectiva de negócio. E teremos outras pessoas que irão cuidar do atendimento a incidentes de produção e manutenções adaptativas.

  2. Possuir uma ou mais pessoas dedicadas para sustentação na tribo.

    Nessa abordagem temos uma pessoa dedicada, mas ela é da tribo e é compartilhada pelo conjunto de Squads que compõem essa tribo. Isso dilui o custo da sustentação entre Squads e permite que a pessoa da sustentação lide com mais assuntos.
  3. Possuir pessoas dedicadas para sustentação em uma Squad, mas com rotação de papéis.

    Se uma pessoa que não foi contratada como analista de suporte ficar muito tempo cuidando de defeitos ele pode ter o seu moral reduzido e perder a motivação. E então você pode experimentar o “motorista da rodada”, i.e., alguém que ficará apenas alguns dias ou semanas cuidando da sustentação. Depois dessa período, outras pessoas assuem o papel da sustentação.

  4. Estabelecer que todas as pessoas criam novas funcionalidades mas também sustentam os produtos da Squad. (mais agressivo)

    Isso é complexo e requer que:

    • O time entregue já código de excelente qualidade em produção, de foram que os incidentes sejam eventuais e o time seja pouco impactado por mudanças emergenciais.
    • O tamanho da mudança evolutiva seja pequena. Grandes mudanças evolutivas trazem impacto maior em ambiente de produção e isso acarreta em um maior número de incidentes, que impacta o planejamento e o moral do time.
    • O time use estratégias modernas de implantação como Implantações Canário. Discuti essa técnica aqui no contexto de práticas DevOps.

 

DESAFIO 3: Time de especialistas generalistas

Na maior parte das TIs os arranjos são funcionais. Isso é, existe a área de analistas, a área de desenvolvimento. Existe a área de qualidade ou a área de implantação. E eles se comunicam primordialmente pela ferramenta inventada pelo capeta corporativo, o famoso e-Mail. É mais que provado que essa separação de funções é ruim financeiramente falando e cria apenas silos gerenciais, disputas de poder e burocracia desnecessária.

Squads não operam de forma funcional. Em Squads maduras, temos todas as competências necessárias para criar e sustentar os nossos produtos de negócio.

Mas não é fácil chegar aqui e precisamos de abordagens intermediárias. Algumas delas incluem:

  1. Estabelecer Squads de Suporte globais para funções raras na organização. (mais conservadora) Por exemplo, poucas TIs possuem uma profusão de especialistas de segurança. E isso pode impedir que na prática tenhamos Squads com um especialista dedicada para segurança da informação.Um Squad de suporte é um tipo particular de Squad que oferta funções especializadas para outros Squads. Esses squads podem possuir modelos de trabalho baseados em sistemas Kanbans, que lidam com demandas em base diária e promovem a vazão e o aumento da velocidade no atendimento a essas demandas.Outros exemplos de funções que normalmente podem ser acomodados nesta configuração incluem Squads de Infraestrutura, Squads de Designers Gráficos ou Squads de Arquitetura.
  2. Estabelecer Squads de Suporte em tribos para funções com baixa disponibilidadeVamos assumir que você tenha uma tribo com 25 pessoas, mas possua apenas 3 analistas de testes, Nesse cenário você estabelecer uma Squad de Suporte de Testes que irá ofertar funções para a sua tribo. Como a sua tribo cuida de produtos de negócio correlatos, não é difícil que analistas de testes possam transitar entre essas Squads e com isso ofertar uma economia de custos sustentável.
  3.  Aceitar os limites da sua Squad conforme o orçamento da sua organização.
    No mundo ideal,  a sua Squad terá analistas de requisitos, engenheiros de usabilidade, arquitetos, desenvolvedores, testadores, especialistas em segurança da informação e analistas de infraestrutura.No mundo real, você provavelmente terá muito menos papéis disponíveis. Aceite a realidade e cresça a maturidade da sua Squad ao longo do tempo.

    DESAFIO 4: Vencer o “modelo comando e controle”

Tradicionalmente, os gerentes estão envolvidos em decidir qual é o trabalho real e na decisão de como fazê-lo.No contexto de Squad, a decisão do que a equipe está trabalhando não está mais sob o controle do gerente, mas é decidida pelo Product Owner. O PO  tem uma visão geral do produto e o que é mais valioso para os clientes, e ele prioriza o trabalho que a equipe realizar.E a decisão sobre como a equipe deve funcionar é delegada à equipe. A equipe é focada no autogerenciamento e, juntos, precisam refletir sobre o que deve ser feito e decidir como farão isso e como vão melhorar.Mas o que faz o gerente no mundo ágil?

Os gerentes atuam como construtores de capacidade. O papel da gerência intermediária é enxergar o todo e construir a capacidade da organização de construir ótimos produtos. Ele deve ajudar a equipe e o Scrum Master na remoção de obstáculos e melhorias. O Gerente deve ensinar a equipe a melhorar e resolver problemas, além de verificar formas para entender o que realmente está acontecendo no local de trabalho e ver como ele pode ajudar melhor a equipe a melhorar seu trabalho.

Algumas abordagens para vencer o modelo “comando e controle” incluem.

  1. Definir o gerente de projeto como SM (mais conservadora)Como o SM participa em base diária do trabalho do time, isso pode acalmar o ímpeto do comando e controle de gerentes mais centralizadores. Ao mesmo tempo, devemos ficar atento e impedir que os gerentes façam micro-gerenciamento (decidir como um participante do time deve fazer o seu trabalho técnico).
  2. Definir o gerente de projeto como PO
    O PO tem controle sobre o backlog e isso também pode ajudar que pessoas mais centralizadoras topem participar dentro de uma dinâmica ágil.
  3. Adotar práticas do Management 3.0 (mais agressiva)O Management 3.0 é um conjunto de práticas gerenciais centradas em uma mentalidade moderna de gestão.. Essas práticas podem ser adotadas individualmente ou em conjunto e permitem que o modelo de autonomia seja gradativamente instalado na Squad.Listamos aqui esse conjunto de práticas com os links para a sua descrição e uso.
    1. Business Guilds & Communities of Practice
    2. Celebration Grid
    3. Copilot Programs
    4. Competency Matrix
    5. Corporate Huddles
    6. Culture Books
    7. Delegation Board
    8. Exploration Days
    9. Feedback Wraps
    10. Happiness Door
    11. Identity Symbols
    12. Improvement Dialogues
    13. Improv Cards & Storytelling
    14. Internal Crowdfunding
    15. Kudo Box
    16. Meddlers
    17. Merit Money
    18. Metrics Ecosystem
    19. Moving Motivators & CHAMPFROGS
    20. OKRs (Objectives & Key Results)
    21. Personal Maps
    22. Project Credits
    23. Problem Time
    24. STAR Behavioral Recruitment Questions
    25. 12 Steps to Happiness
    26. Salary Formula
    27. Scoreboard Index
    28. Unlimited Vacations
    29. Value Stories
    30. Visual Goal Setting
    31. Work Expos
    32. Work Profiles
    33. Yay! Questions

A implantação de Squads é um movimento importante na evolução da agilidade em organizações. Ao mesmo tempo, os modelos de implantação não são únicos e é fundamental você conduzir experimentações dentro da realidade da sua organização.

E, dentro da sua realidade, o que tem funcionado no contexto de Squads? Quais tem sido os seus desafios? Compartilhe aqui com a gente.

O trem ágil chegou! Em qual estação você vai embarcar?

Gosto muito do conceito da difusão de inovações de Rogers, que mostra como inovações são adotadas ao longo do tempo por uma audiência potencial. A figura, reproduzida abaixo a partir do trabalho original de Everett Rogers de 1962, traz a hipótese que existem cinco perfis no ciclo de adoção de uma nova tecnologia, processo ou produto.

curva-de-adoção-de-novos-produtos-receita-x-tempo
Fonte: blog.cicloagenciadigital.com.br

Os dois primeiros públicos, ou mercado inicial, são os perfis desbravadores que experimentam um novo processo, produto ou tecnologia. Se os seus relatos e resultados obtidos forem bons, a inovação vence o abismo e avança para a maioria inicial e com nova confirmação de sucesso ela avança posteriormente para a maioria tardia.

Por curiosidade, comparei a tendência de pesquisa de termos comuns na esfera gerencial como PMBOK, Scrum e Lean. Os resultados estão abaixo mostraram ao longo dos últimos anos uma inversão da procura ao longo dos últimos anos. Os números mostram um que o Scrum ou o Lean trazem mais curiosidade que o PMBOK no Brasil.

Captura de Tela 2018-05-07 às 16.30.03

Fonte: Google Trends

Baseado também no que tenho observado na minha rede de gestores, arrisco dizer que o método ágil já venceu o abismo da incredulidade no Brasil no público gerencial. A aceitação dos métodos ágeis está cada vez maior e mesmo aqueles que ainda não estão usando estão querendo se informar.

Ao mesmo tempo, não devemos confundir métodos ágeis com Scrum. Existem muitos tipos de métodos ágeis e cada empresa pode se beneficiar de um tipo distinto de método para a sua realidade. Não é porque o método ágil venceu o abismo que ele vai ser aceito pela maioria tardia, que é um público muito mais cético.

Para lançar alguma luz nos diversos métodos ágeis, compilei um mapa ferroviário com as linhas onde correm alguns três ágeis populares no mercado.

O mapa está abaixo  e disponível aqui em alta resolução, que você pode baixar e abrir em uma janela própria do seu computador. Eles contém mais de 70 conceitos usados dentro do mundo ágil em escolas diversas de pensamento.

Trem Ágil

Cada linha é representada por uma cor distinta e contém conceitos, papéis ou termos fundamentais para o entendimento daquele trilho. O objetivo é lhe dar um mapa para você navegar no mundo ágil, reconhecer e correlacionar conceitos comuns falados nos corredores e times ágeis de todo o Brasil.

Destaco aqui pontos importantes do mapa:

  • Linha Vermelha – Representa o trem do Scrum, o método mais popular do mercado ágil no Brasil, Aqui você vai encontrar termos como Backlog do Sprint, Planejamento de Sprint, Revisão ou Retrospectiva
  • Linha Amarela – Representa o trem do dono do produto e do desenvolvimento de produtos. Contem termos importantes como Backlog do Produto, VPD, Design Sprint e Design Thinking.
  • Linha Laranja – Representa a metodologia Kanban, que vai além do quadro Kanban. A linha laranja evolui para a linha do Lean, a linha Roxa.
  • Linha Roxa – Representa a linha dos métodos lean e traz conceitos fundamentais como a redução de lotes, redução do tempo de ciclo, teoria de fila e controle empírico de processo.
  • Linha Azul – Representa a linha dos times ágeis e traz ideias poderosas como Squads e o Management 3.0.
  • Linha Preta – Aqui temos a agilidade para dezenas ou centenas de pessoas, chamada de agilidade em escala. Escolhi representar aqui os principais conceitos de um dos métodos mais poderosos para a agilidade em escala no mercado, que é o SAFE.
  • Linhas Verde Escura, Verde Clara e Azul. Se você é de TI, vai gostar dessas linhas. Elas trazem os conceitos de DevOps, Automação de Testes e Arquiteturas Ágeis.

O mapa é uma abstração apenas e deve ser enriquecido ao longo do tempo com novos termos, conceitos e relações. Se você já trabalha com métodos ágeis, sugestões são muito bem vindas.

E como me aprofundo em cada trilha?

Se você quer navegar com mais profundidade por uma dessas trilha, tomo a liberdade de lhe recomendar alguns livros essenciais para iniciar ou reforçar o seu aprendizado em um dos trens do mundo ágil.

Linha Vermelha – Scrum

514ZCPRQ-bL._SX337_BO1,204,203,200_71nHi9Q2t6L._AC_US436_QL65_

Linha Amarela – PO – Dono do Produto

51oQRBYUxeL._SX381_BO1,204,203,200_61K0l8DfyCL._AC_US436_QL65_

Linha Laranja – Kanban

616tkWkRWjL._AC_US436_QL65_51hocASZ3bL._AC_US436_QL65_

Linha Roxa – Lean

41FItt2UB8L._AC_US436_QL65_51O-pgPIYAL._AC_US436_QL65_

51pgq089gIL._AC_US436_QL65_-2

Linha Azul

516O25pIrgL._AC_US436_QL65_71tMlME3L6L._AC_US436_QL65_

Linha Preta

511nXu28UIL._AC_US436_QL65_51zOpwQvJNL._AC_US436_QL65_

Linhas Verde e Azul – Para você que é de TI e estava se sentido esquecido

A evolução dos servidores Web, o que usar e o que aposentar na sua empresa

Servidores Web já existem há quase 30 anos e são a peça mais importante para suportar a Internet como a conhecemos. Embora muitos desenvolvedores não deem a devida importância para eles, é fundamental conhecer essa importante fauna e como podemos tirar vantagens de algumas tecnologias modernas para o suporte a estilos modernos como APIs e microsserviços.

Primeira geração – Servidores Web Baseado em processos

Reconstituição de trilobites vivos.

Anos de atividade: 1990 a 2000
Status: Extinto

O primeiro servidor Web foi desenvolvido a partir do utilitário inetd do Linux, que é um programa utilitário que responde requisições de um cliente em um certo porto e faz o despacho da requisição para um programa.

No começo dos anos 90, um programa específico foi desenvolvido para lidar com requisições http. Esse programa se chama httpD (Http Daemon), desenvolvido pela NCSA (National Center for Supercomputing Applications da Universidade de Illionis.

Como aplicações Web tendem a gerar um tráfego alto composto por múltiplas requisições de tempo de vida curto, esse tipo de mecanismo não é usado para fins profissionais. Com o tempo, peças específicas de software foram desenvolvidas para tratar com escalabilidade e segurança requisições HTTP. Ao mesmo tempo, é importante destacar o servidor Web mais popular do planeta, o Apache HTTP Server, foi desenvolvido a partir do utilitário NCSA httpD.

Segunda geração – Servidores Web baseados em Threads

Um Carcharias taurus.

Anos de atividade: 1995 – atual
Status: Em plena atividade

A história desses servidores se confunde com a história do Apache HTTP Server. Em linhas gerais, o Apache HTTP Server  surgiu a partir de utilitários simples para responder a requisições HTTP e foi evoluído para incluir características hoje fundamentais em aplicações Web tais como suportar:

  • Múltiplos clientes simultâneos através de multi-threading;
  • APIs de extensibilidade para a construção e distribuição de novos módulos;
  • Transporte seguro (SSL) e mecanismos de autenticação e autorização de páginas.

Esses servidores se tornaram dominantes na Web ainda nos anos 90 e exemplos de servidores dessa categoria incluem o Microsoft IIS  e NGINX. Enquanto o primeiro servidor é dominante para aplicações desenvolvidas em ASP e ASP.NET, o segundo foi desenvolvido como uma opção mais performática do Apache HTTP Server.

Servidores Web de Terceira Geração – Os temíveis e monstruosos Servidores de Aplicação 

Elephant white background.png

Anos de atividade: 2000 – atual
Status:  Em risco de extinção

A tecnologia Java EE era no final dos 90 o esforço mais sofisticado de organização de plataformas servidoras, inspirados por modelos hoje legados como o CORBA. Servidores Java EE trazem, por especificação, uma enorme coleção de serviços embutidos (out of the box), tais como linguagens de páginas dinâmicas, gerência de memória, operação clusterizada, controle transacional distribuído, modelos de componentes distribuídos e conectores com plataformas legados, entre outros).

Como consequência dessa enormidade de serviços, empresas como IBM, BEA, SUN, TIBCO, Fujitsu, Oracle e JBOSS, entre outras, começaram a desenvolver servidores Web com esteroides. Essas peças foram apelidadas de “servidores de aplicação” e são servidores Web que foram desenvolvidos para rodar aplicações servidoras.

No mundo Microsoft, a combinação do IIS, .NET Framework, MSMQ e Windows pode ser vista, com alguma liberdade arquitetural, com um servidor de aplicação Microsoft que hospeda e roda aplicações .NET

A história do Java EE e .NET se confundiu durante muito tempo com esses tipos de servidores Web. Algumas servidores de aplicações populares incluem:

  • IBM Websphere Application Server
  • Oracle Internet Applicaton Server (antigo BEA Weblogic)
  • Redhat Wildfly  (JBOSS Application Server)
  • Microsoft IIS + MSQM + .NET Framework
  • Microsoft BizTalk

Servidores Web de Quarta Geração – Servidores Leves Embarcados em Aplicações

Anos de atividade: 2010 – atual
Status: Em plena atividade

A partir de 2010, um movimento de minimalismo começou a tomar conta da comunidade de desenvolvimento Web. Os motivos estão ligados a problemas de escalabilidade e o peso de várias soluções dos servidores de terceira geração. Alguns desses servidores de terceira geração exigem pelo menos 1 GB de memória para funcionamento, ocupam dezenas de gigabytes de espaço em disco, requerem processadores de última geração para performer e alocam centenas de threads quando são instanciados.

Um exemplo de servidor Web de quarta geração é Express do Node.JS. Ele é um servidor minimalista que opera junto da própria aplicação .JS que está sendo executada. Ele ocupa um espaço mínimo de memória (entre 10 a 20 megabytes), poucos megabytes de espaço disco e usa recursos mínimos de CPU.

E as próprias comunidades Java EE e .NET começam a desenvolver soluções minimalistas para servidores Web.

No mundo Java EE, a Spring (hoje Pivotal) entregou soluções minimalistas como o Spring Boot . O Eclipse Jetty  e o KumuluzEE  são outras soluções nesse sentido.

No mundo .NET, a versão mais recente do ASP.NET e o projeto .NET Core são exemplos nesse sentido com os servidores leves e embarcados como o Kestrel e o HTTP.sys. Aplicações ASP.NET Core podem rodar sem a necessidade de servidores como o IIS. Essa nova geração de servidores Web elimina o modelo tradicional e empacotamento e distribuição de aplicações (assemble & deploy). Ao invés, a própria aplicação Java, C ou JS servidor é executada como um servidor Web em um modelo chamado de aplicação auto hospedada (self-host application). Essa nova geração é útil para o desenvolvimento no estilo arquitetural de microsserviços.

Comparação da Fauna de Servidores Web

Para facilitar a sua escolha e evolução arquitetural, montei uma tabela de referência aqui.

E você, que fauna está alimentando na sua empresa?

Tecnologias Web em 2018: O que escolher ao começar um novo projeto

Tomar decisões sobre que tecnologias usar em um novo projeto Web não é simples. A indústria de software apresenta opções como nunca antes e é facil ficar perdido dentro de tantas opções de bibliotecas, componentes, frameworks, IDEs e ferramentas de scaffolding.

Observo em base diária o que colegas, parceiros de negócio, clientes e pessoas da comunidade estão usados. E com base nessas observações expresso aqui algumas opiniões fundamentadas para facilitar a sua jornada na escolha de novas tecnologias Web.

  1. Considere o uso profissional de tecnologias JavaScript

JavaScript? Sei não? Isso é realmente sério?

Sim. Javascript é somente a linguagem mais usada no mundo Web hoje para o desenvolvimento de aplicações. Por exemplo, uma pesquisa com 64 mil desenvolvedores realizada pelo sítio StackOverflow mostrou o JS sendo por 67% dos desenvolvedores.

E veja. Não estou falando apenas de bibliotecas acessórias como jQuery e jQueryUI. Afinal, estas boas bibiotecas já são usadas no Brasil há mais de 10 anos.

Estou falando aqui dos seguintes aspectos:

  • substituição de tecnologias de apresentação com o padrão arquitetural MVC (ex. JSF, ASP.NET Razor) pelo padrão arquitetural MVVM (ex. Google Angular 5, Facebook React ou VueJS);
  • uso de frameworks de testes de unidade em JavaScript. Bons exemplos incluem o CucumberJS, Jasmine, Karma ou Protractor;
  • uso de ferramentas para distribuição eficientes dos pacotes JavaScript com uso de recursos de minificação e embaralhamento do código. Ferramentas particularmente úteis nesse aspecto incluem o WebPack3 e o Parcel.
  • uso de linguagens baseadas em JavaScript que aumentam o nível de abstração e possuem compilação estática de código. A linguagem Microsoft TypeScript tem expandido a sua popularidade e se consolidado neste aspecto.
  • depuração eficiente de código cliente (logging). Ferramentas com o LogRocket e o Elmah são uma ajuda e tanto neste contexto.
  • uso de IDEs leves e modernas. Brilham aqui IDEs como o Visual Studio Code e WebStorm.

Ao adotar um ecossistema JavaScript sólido, você terá em sua mão o que as melhores empresas do mundo estão usando para desenvolvimento Web. Terá também tecnologias mais simples e eficientes e mais capacidade de se adaptar aos próximos anos.

Deixo aqui uma referência para um relatório bem legal chamado The State of Javascript 2017 e alguns gráficos interessantes desta pesquisa.

Popularidade de frameworks JavaScript para Front-end — https://stateofjs.com/2017/front-end/other/
Popularidade de frameworks JavaScript Back-end— https://stateofjs.com/2017/back-end/other/
Popularidade de frameworks para Testes em JavaScript — https://stateofjs.com/2017/testing/other/
Popularidade de ferramentas de build em JavaScript — https://stateofjs.com/2017/build-tools/other/

2. Use APIs REST para expor suas funcionalidades de negócio

Não importa se você desenvolve em PHP, Python, C# ou Java. O que você deve evitar é que a camada Web faça acesso direto a funcionalidades backend sem o uso de APIs.

O código servidor não deve ficar preso ao código HTML (o JSF e o ASP.NET Web Forms são contra-exemplos desta recomendação). O código servidor deve ser escrito com a possibilidade de reuso por aplicaçõees móveis e também aplicativos de internet das coisas, conforme mostrado na figura abaixo.

Aplicações Web modernas devem expor APIs

Ao fazer isso, você trará os seguintes benefícios para a sua empresa:

  • Potencializar o uso de código legado. APIs REST podem encapsular códigos em tecnologias antigas como PL-SQL, COBOL, Natural.
  • Habilitar competências específicas no seu time. Não é incomum que pessoas que conheçam muito bem Java, C# ou PL-SQL não consigam ter o mesmo nível de excelência em desenvolvimento moderno Web com React ou Angular5. E isso permite que você tenha dois perfis distintos nesta situação, que são os Back-end developers e Front-end developers.

Se você já começou a usa jornada com APIs, use este estilo de forma consistente. Deixo aqui algumas recomendações de tecnologias de suporte para testes e aperfeiçoamento das suas APIs:

3. Evolua as linguagens do lado servidor

Se você trabalha com Java, não deixe de usar os diversos recursos funcionais do Java 8. Embora os recursos já existem desde 2014, muitos desenvolvedores não estão fazendo uso destes elementos. E considere o uso de recursos recém lançados do Java 9 tais como melhorias na API de Streams, distribuição modular, cache e suporte a JavaScript servidor.

Se você trabalha com C#, é hora de considerar o novo ecossistema de tecnologias do .NET Core e .NET Standard, que está na sua segunda geração já.

O ASP.NET Core, por exemplo, tem obtido apoio muito forte da comunidade e conta com os primeiros projetos em produção no Brasil.

E, com o .NET Core 2, foi lançado também a biblioteca do .NET Standard que permite que desenvolva ou refatore módulos que poderão operar simultaneamente na nova arquitetura do .NET Core, arquitetura legada do .NET Framework e também o próprio Xamarin para aplicaçativos móveis.

Se você trabalha com linguagens dinâmicas, considere o Python 3. Esta linguagem tem experimentado um crescimento expressivo devido ao mercado de ciência de dados e big data.

4. Simplifique a sua distribuição com aplicações auto-hospedadas e contêineres

Entre 1995 e 2010, o mercado foi domaindo pelos servidores de aplicação clássicos, como por exemplo o Microsoft IIS, Apache Tomcat, JBOSS Application Server e produtos similares de empresas como IBM ou Oracle.

Nos últimos dois anos, temos observados muitas empresas usando soluções mais simples em ambientes de produção com o uso de tecnologias diversas tais como:

Dentro das tecnologias de conteineres, começe a adotar o Docker e considere tecnologias de suporte para o gerenciamento de conteineres como por exemplo o Rancher e orquestração de contêineres como o Google Kubernetes.

5. Considere estilos arquiteturais complementares

O uso dos padrões MVC e MVVM ainda é dominante no desenvolvimento Web. Para para problemas alternativos temos vistos estilos arquiteturais complementares tais como:

  • Microsserviços, que permitem escrever novos produtos como um conjunto de serviços pequenos e independentes. Tenho um artigo introdutório ao tema aqui (Não Alimente Seus Paquidermes). Tecnologias como o Lumen, Flask, SpringBoot e .NET Core são mais interessantes para este cenário.
  • Nanosserviços (ou serverless ou funções como serviços), que são tipos de microsserviços que operam sobre nuvem públicas sem a necessidade de aluguel de máquinas. Você cria e distribui o seu código e é tarifado pelo uso de CPU e memória do seu código em ambiente de produção. O AWS Lambda, Azure Functions e Google Functions são exemplos muito promissores destas tecnologias.
  • Segregação de comandos e consultas (CQRS), cujo objetivo é acelerar a performance de aplicações através da segregação do código de consulta dos códigos de comandos de atualização do banco de dados.
Padrão Arquitetural CQRS — https://martinfowler.com/bliki/CQRS.html
  • Persistência poliglota, que consiste do uso de diferentes estratégias e tecnologias de persistência de dados para situações específicas em aplicações Web. Por exemplo, armazenar e indexar um conjunto de imagens ou criar um cache pode ser eficientemente resolvido em bancos de dados do tipo chave/valor como por exemplo o Redis. Um exemplo prático é a arquitetura da Stack Overflow, mostrada no esquema abaixo.
Arquitetura Web do Stack Overflow — https://nickcraver.com/blog/2016/02/17/stack-overflow-the-architecture-2016-edition/

Iniciando a transição

Antes de adotar em larga escala novas tecnologias, é sempre importante lembrar de algumas recomendações arquiteturais:

  • Faça provas de conceitos para reduzir riscos e testar estas novas tecnologias na sua realidade;
  • Faça treinamentos e garanta que cada pessoa do seu time tenha sido devidamente treinado;
  • Não deixe que o conhecimento de uma tecnologia fique na mão de um especialista — pessoas vem e vão e você pode ficar em maus lençóis se confiar em apenas uma única pessoa.
  • Não adote tecnologias apenas porque elas estão populares. Veja como elas podem resolver os problemas reais de negócio da sua organização. Faça testes e esteja preparado para o pior.

Como matar uma iniciativa DevOps em sete passos.

A TI é afeita a termos e letrinhas que surgem de tempo em tempo. No momento atual, os termos “transformação digital”, “microsserviços” e “DevOps” são tão modinhas quanto as músicas de qualidade ruim da Anitta.

E o problema das modinhas é que que todos querem dizer que estão fazendo, mesmo que tenham uma ideia distorcida do que estão realmente fazendo. A este respeito, tenho observado excelentes oportunidades DevOps sendo jogadas nos lixo por implementações equivocadas em pequenas e grandes empresas.

E se é para nos equivocarmos, gostaria de ajudar também. Vamos direto ao ponto e criar um guia rápida de como fracassar com DevOps.

É fácil. Siga os sete passos abaixo e falhe na sua implementação DevOps. É fracasso garantido ou o seu dinheiro de volta.

  1. Contrate um “Analista DevOps”

Existem sim líderes técnicos, desenvolvedores, testadores e profissionais de qualidade, entre outros, que praticam DevOps. Ao mesmo tempo devemos nos lembrar, desde o início, que o DevOps é uma cultura. Ou seja, não existem *Analistas DevOps*.

Acreditar que você vai encontrar um “Analista DevOps” já é ruim. E para piorar alguns gestores acreditam que contratar um “Analista DevOps” é o suficiente para ter a sua implementação DevOps realizada.

2. Crie uma área especialista para fazer DevOps

Erro clássico, embora muito comum. Criar mais um silo em um departamento de TI que já tem áreas de gestores, analistas, desenvolvedores, testadores, homologação e produção trabalhando em locais diferentes definitivamente não irá ajudar.

O DevOps prega a quebra das paredes (físicas e invisíveis). E não adicionar mais uma área funcional dentro da sua TI.

3. Estabeleça um pipeline DevOps dentro da área de qualidade ou governança

Qualquer iniciativa de centralizar uma esteira DevOps vai intensificar o oposto do que a cultura DevOps promove. O DevOps é uma cultura que promove comunicação ampla e a quebra de silos.

Que fique claro: o DevOps ocorre NOS PROJETOS e não em uma torre de marfim de qualidade.

4. Mantenha testadores e desenvolvedores trabalhando em áreas diferentes

Apartar (no espaço e no tempo) testadores e desenvolvedores é um dos piores erros que gestores podem cometer. Isso gera adiamento na resolução dos defeitos, desalinhamento e dedos apontados sobre as culpas no final do projeto. E isso também mantem a nefasta cutural funcional e os malefícios que os processos cascata nos impuseram ao longo dos últimos 40 anos.

5. Não envolva o time de infraestrutura. Ou não envolva o time de desenvolvimento

DevOps sem Ops soa estranho, certo? Assim como uma iniciativa DevOps sem Dev. E mesmo assim estamos vendo muitas implementações DevOps que ocorrem apenas dentro da área de desenvolvimento ou da área de operações.

6. Implante as ferramentas DevOps em primeiro lugar

Muitos gestores acreditam que ferramentas como VSTS, Chef, Puppet, GitLab, Docker ou Ansible já trazem o DevOps dentro dela. É como se você comprasse uma panela de cerâmica laranja e esperasse que o seu jantar vá ter qualidade de restaurante três estrelas Michelin.

Embora estas e outras ferramentas sejam excelentes devemos nos lembrar que no mundo DevOps devemos:

  • primeiro trabalhar as pessoas e a cultura,
  • depois as práticas;
  • e finalmente as ferramentas.

7. Venda o DevOps como a bala de prata que irá matar os lobisomens da sua organização

Não, o DevOps não é uma bala de prata. Ele não irá revolucionar a sua TI, não irá zerar o backlog e os defeitos, não irá garantir todas as entregas dentro dos prazos e também não irá fazer que pessoas deem as mãos em harmonia.

Apesar disso,  o DevOps pode lhe ajudar sim no contínuo caminho da melhoria contínua que buscamos nos ensinamentos do sistema Toyota de Produção e nas práticas Lean.

Algo está errado se os trabalhadores não olham ao seu redor cada dia e não encontram coisas tediosas ou aborrecidas para depois reescreverem eles mesmos os procedimentos. Mesmo o manual do mês passado deveria estar desatualizado hoje, Taiichi Ohno