Desmistificando o Assessment de Times de Tecnologia

Compartilhe:

Diferente do trabalho das consultorias tradicionais, a K21 não aplica fórmulas prontas na Transformação ou Expansão Digital Ágil. Entendemos que cada cenário é diferente e, assim, trabalhamos a quatro mãos com o cliente para combinar e customizar nossos serviços de forma a melhor atender às suas necessidades. Além disso, o trabalho a quatro mãos leva ao alinhamento contínuo ao longo da execução, o que reduz riscos para ambos os lados.

vantagens

Como resultado desta forte sinergia entre K21 e Cliente, estamos constantemente nos adaptando para gerar resultados impactantes de acordo com a realidade particular de cada cliente. Desta forma, aplicamos a melhoria contínua a todo momento, o que nos leva até mesmo a criar novas dinâmicas de grupos e ferramentas durante nossa atuação no dia a dia dentro das organizações.

Uma das práticas que o Lula e eu mais gostamos dentro do processo de desenvolvimento individual e em grupo é a provocação através de reflexões. Sabe aquele momento o qual os olhos brilham, a ficha cai, você nota que um novo aprendizado realmente faz sentido e instantaneamente pensa “EITA PORRA!”?

Que tal aproveitar esse momento único para criar um plano de ação tangível e com suporte teórico e prático rumo ao estado desejado?

O Team Coaching Assessment é uma ferramenta reflexiva e provocativa facilitada por um coach capacitado com a finalidade de:

  • Facilitar uma autoavaliação do time para que os gaps entre a sua realidade e o cenário ideal sejam percebidos por todos os membros;
  • Gerar um Backlog de Treinamento/Aprendizado priorizado, com base nos gaps percebidos pelo próprio time;
  • Conduzir sessões de Agile Coaching, unindo teoria e prática, sobre cada item priorizado;
  • Promover compartilhamento diário, entre todos os membros do time, dos aprendizados, resultados e próximos passos.

Desta forma, acreditamos que é possível criar rapidamente um ambiente propício à experimentação, incentivando o time a sair de sua zona de conforto mas sem causar estresse, através de um equilíbrio sadio entre desafio e segurança.

Assessment

Assessment

Mas antes de detalharmos o nosso assessment é importantíssimo um alinhamento de expectativas quanto ao uso da ferramenta. Ela não deve ser utilizada para comparar times e reforçar qual é o melhor. Utilizamos o assessment como uma ferramenta de apoio para identificação de pontos de melhorias e excelência, reforçando as práticas e comportamentos que já impactam positivamente o dia a dia das pessoas, e também criando um plano de ação para lidar com os fatores que atrapalham o andamento da realização do trabalho desejado. A única comparação que visamos é do time consigo mesmo, ou seja, ao refazer o assessment depois de determinado período de tempo o time reflete sobre como foi sua evolução no último ciclo e como pode melhorar para o próximo.

As informações coletadas podem ser utilizadas diretamente no desenvolvimento do times e também no desenvolvimento da organização, caso analisadas de forma mais sistêmica. Desta forma, também podemos incentivar a troca de conhecimentos entre times, onde as prática as quais ele já é referência podem ser compartilhadas dentro da organização. Desta forma começamos a incentivar com que os times e a própria organização aprendam a aprender.

Assessment

Entendendo a Escala

Logo que pensamos na auto-avaliação, decidimos criar uma escala de fácil compreensão na qual as pessoas pudessem facilmente entender seu momento atual em cada um dos tópicos abordados.

Para isso, decidimos criar níveis que representassem desde a importância de uma prática no contexto do time, sua utilização no dia a dia de trabalho e o nível de maestria para compartilhar os aprendizados decorridos diante de suas experiências.

Desta forma, os níveis escolhidos foram:

  • Não pratica: não sabemos direito como colocar este item em prática no nosso contexto. É algo novo para o nosso time, ou não consideramos relevante para o nosso contexto.
  • Novato: descobrimos que este assunto é relevante para o nosso time recentemente, e estamos dando os primeiros passos.
  • Aprendiz: definitivamente este assunto é algo que devemos levar em conta. Estamos decididos a começar a nos aprofundar nele. Estamos pesquisando e descobrindo empiricamente como aplicar.
  • Praticante: isso faz parte do nosso cotidiano. Ainda temos algumas dificuldades, mas esta prática já é algo normal para nós.
  • Experiente: pratico isto a tempo o suficiente para dizer que conheço. Estamos frequentemente discutindo com outros times e pessoas sobre este assunto com certo nível de maturidade. Dificilmente é algo que nosso time deixará de fazer porque acreditamos nesta prática.
  • Referência: dominamos tanto este assunto que se qualquer um quiser aprender como fazer, é só vir aqui para ver. Nos sentimos confortáveis o suficiente para submeter palestras ou dar aulas sobre este assunto, por exemplo.

Entendendo melhor o domínio de Negócios

É o domínio responsável pela eficácia, composto por assuntos relacionados aos produtos e objetivos da empresa, como cálculos de ROI (Return On Investment) do produto e suas próximas funcionalidades, priorização, planejamento das próximas releases e eventualmente contratos no contexto Ágil.

É o domínio no qual os Gestores de Produtos ou Product Owners atuam como um verdadeiro FDP, calma lá que não é nada do que você está pensando. Eles fatiam, descartam e priorizam, dando sentido ao trabalho realizado na organização.

Dentre os principais pontos de reflexão neste domínio, costumamos destacar:

  • Visão clara do produto: todos sabem, exatamente, como o produto pretende gerar valor? Qualquer integrante do time consegue formular prontamente um elevator pitch para o produto trabalhado? A relação entre cada linha de código escrita e o impacto na estratégia da empresa é clara para todos os integrantes do time? Temos clareza dos caminhos que estamos seguindo com o produto e os porquês que o permeiam?
  • Fatias finas: os itens de negócio que o time pega para trabalhar, são itens pequenos o suficiente para deixarem de ser complexos e tornarem-se simples? Começar e acabar um item de negócio em 1 dia, por exemplo, é algo que parece impossível, ou é algo que parece normal? Os itens de trabalho individualmente, agregam valor ao negócio, ou são somente partes técnicas que depois precisaremos juntar para entregar valor? O quanto “fatiar fino” é algo normal no dia-a-dia do time? O time está, a todo momento, focando nos 20% do trabalho que trarão 80% do retorno, ou geralmente procuram o 100%?
  • Métricas de produto: o time possui números que sinalizem se estão “acertando o alvo” a cada entrega? O trabalho é guiado por dados sobre o uso dos nossos produtos e sobre os nossos usuários, ou o caminho é definido na base do achismo? Funil de conversão e métricas do pirata são termos que todo o time entende, ou são termos novos? O time é guiados por números ou pelo que a pessoa hierarquicamente superior considera melhor? Todo o time acompanha estes números, ou somente o P.O. / Gestor de Produtos?

Entendendo melhor o domínio Cultural

Este domínio possui como foco principal as relações humanas e o nível de empoderamento das pessoas para que possam tomar decisões sobre seu trabalho, promovendo a auto-organização e a motivação dos indivíduos.

Este domínio também é composto por dois assuntos extremamente importantes para a Agilidade: a quebra de paradigmas e a melhoria contínua. Ao abordar o domínio Cultural, comumente conversamos sobre:

  • Envolvimento no Negócio: quão próximo do Negócio o time está? É falada fluentemente a linguagem de negócios, ou o idioma do time é o Técniquês? A única fonte de acesso ao negócio é o P.O., ou todos do time sentem-se a vontade para buscar informações de negócio fora do time? O time se vê como um time “de desenvolvedores” simplesmente, ou um time “de negócios” que, por acaso, desenvolve software?
  • Envolvimento dos usuários: o time conhece seus usuários? Conhecem o perfil de quem está usando ou vai usar o produto? Possuem feedbacks reais destes usuários? Têm contato pessoal com algum deles para buscar feedback? Somente o P.O. tem acesso a eles, ou o time como um todo possui?
  • Entrega vs Ocupação: não faz sentido trabalhadores do conhecimento serem cobrados pela quantidade de horas que trabalhou, ou pela quantidade de linhas de código produzidas, por exemplo. O time é cobrado e valorizado por horas trabalhadas, ou por valor entregue e seu impacto no negócio? Estar ocupado ainda é importante para quem nos cobra?

Entendendo melhor o domínio Organizacional

Este domínio é mais ligado a como a empresa está estruturada e a forma de trabalho dos times: quais métodos o time usa, como é o ciclo de desenvolvimento, o processo iterativo e a distribuição das pessoas. É o domínio que visa a eficiência, mas sempre alinhada com a eficácia citada no domínio de Negócios.

Gostamos muito de frisar este relacionamento entre eficiência e eficácia porque muitas vezes, devido a forte influência de formas mais tradicionais de trabalho, somos cobrados por fazer mais rápido mesmo sem conhecer o por que ou o impacto que pretendemos alcançar com o esforço realizado.

Dentre os principais tópicos deste domínio, gostamos conversar sobre:

  • Métricas de time: quais são os parâmetros utilizados para saber se o time está melhorando com o passar do tempo ou não? O time possui números, gráficos e indicadores para acompanhar sua evolução? Estes números são acompanhados de perto? Só o gerente olha, ou todo o time é responsável por isso? Só o gerente coleta e analisa, ou todo o time? O time possui o seu histórico de Lead Time? E um Cumulative Flow Diagram?
  • Cerimônias e papéis: o time executa as cerimônias previstas nos métodos ou frameworks que utiliza? Isso é feito de forma consciente, entendendo o propósito de cada cerimônia, ou ainda é feito de forma mais robótica, para tentar entender como funciona? Os papéis utilizados são claros para todos os membros do time? Eles são úteis? É explícito exatamente o que é esperado de cada um?
  • Visibilidade: Se alguém chegar ao local de trabalho do time, consegue entender o que está acontecendo? Se alguém do time sair de férias, quando voltar vai precisar conversar com outra pessoa para entender o que aconteceu desde então e como estamos hoje, ou só pela visibilidade do que está exposto já consegue saber exatamente como onde está? As informações visuais são informações úteis, ou estão mais para poluição visual? Existe muita coisa velha e inútil pendurada na parede?

Entendendo melhor o domínio Técnico

Este domínio visa entender a busca do time por sua excelência técnica, focando na forma como o trabalho é feito. A automação é um conhecimento fundamental nesse domínio, pois se reflete nos demais assuntos técnicos: qualidade, padrões, ferramentas etc… Na área de TI, as boas práticas de engenharia de software trazidas pelo XP estão no domínio técnico.

  • Qualidade: o time está preocupado em cuidar da saúde do produto? Coletam métricas para apoiar este movimento? Comumente é refatorado código com bad smells? Adotam técnicas de revisão de código e trabalho em pares? O código é limpo ou documentação complementar é necessária para compreendê-lo?
  • Autonomia Técnica: tecnicamente o time faz o que outros times, departamentos ou pessoas mandam, ou fazem o que acham ideal fazer? Possuem autonomia para escolher a melhor forma técnica de implementar os sistemas? Se precisarem colocar a mão no código de outro sistema, possuem permissão? Qualquer um do time consegue colocar a mão em qualquer código do time sem ter que pedir permissão? Eles podem escolher as tecnologias a serem utilizadas?
  • Automação: o time implementa testes automatizados? Pensar em testes automatizados faz parte de sua cultura? Testam o que fazem no nível mais apropriado para o contexto (unidade, integração, serviço, interface, etc…), ou a maior parte é manual? Possuem todo o conhecimento necessário para automatizar os testes? Eles também focam em automatizar o trabalho repetitivo para que possam focar no trabalho criativo?

Conclusão

Muitas vezes a Agilidade é entendida de forma equivocada, levando organizações e times a focarem apenas na velocidade. Os 4 domínios da Agilidade criados pela K21 ajudam na compreensão da importância do balanceamento entre Eficácia (Negócio), Empoderamento (Cultural), Eficiência(Organizacional) e Excelência (Técnica) para a formação de times de alta performance, que aprendem continuamente através de entregas constante de valor à seus usuários.

A utilização do Assessment nos 4 domínios da Agilidade é uma excelente oportunidade de proporcionar um momento de reflexão em conjunto, onde os integrantes de um time realizarão uma auto-avaliação de sua atuação. Desta forma, pontos de excelência e de melhorias emergirão naturalmente através da dinâmica, permitindo com que times iniciantes em Agilidade ou até mesmo os que já possuem o mindset propício conscientizem-se de seu momento atual para entender como desenvolver-se melhor.

Um bom Facilitador com experiência em Agilidade pode potencializar ainda mais esse encontro explorando o estado da arte dentro dos quatro domínios.

Sobre o autor(a)

Agile Expert e Trainer na K21

Iniciou sua carreira desenvolvendo produtos digitais em 1999 atendendo a diversos nichos de mercado. Teve seu primeiro contato com Agilidade em 2003 e desde então trabalha com lideranças e mudanças organizacionais. Tornou-se praticante do Management 3.0 em 2016 e desde então participou de diversas transformações digitais utilizando este modelo de gestão e liderança.

Artigos relacionados

Nas discussões e workshops sobre OKRs que fazemos nas empresas, um conceito sempre aparece: Estão faltando métricas de guard rail para equilibrar esses OKRs! As Métricas de saúde (ou Guard Rails) ajudam a liderança e as equipes a manterem um…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

O que é gargalo Quando falamos sobre Kanban um dos nossos principais objetivos é identificar onde está o gargalo do nosso fluxo. O gargalo é a etapa em que os itens permanecem por mais tempo. É fundamental resolver os gargalos…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

Seja em treinamentos, consultoria ou até mesmo com meus times de desenvolvimento. Uma coisa fácil de perceber é o desconforto causado quando comento sobre a necessidade de limitação de WIP. É algo que me causa estranheza. Por que as pessoas…

Avelino segurando um microfone e uma camiseta preta escrita Agile. Ele é pardo, barba e cabelos grisalhos.

No artigo anterior, comentamos sobre o que era o Kanban, qual problema ele resolve e os princípios que norteiam esse método de gestão de trabalho. Este artigo é um complemento ao primeiro e nele quero tratar as práticas que o…