Resolvi criar esse material sobre Scrum porque, há muitos anos atrás, foi através dele que tive meu primeiro contato com o mundo da gestão e desenvolvimento ágil de projetos. Ele surgiu e é muito utilizado no mundo de desenvolvimento de software, mas ele também é utilizado em diversos tipos de trabalho diferentes, por vários tipos de empresa.
O Scrum me ajudou muito a enxergar que várias coisas em que eu acreditava não funcionavam mais, era necessário uma outra forma de pensar. A estrutura de trabalho do Scrum pode trazer vários benefícios ao resultado do seu trabalho e também para seus clientes.
Se a equipe entender os benefícios que o Scrum pode trazer, e conseguir extrair o melhor dele na prática, pode apostar que essa equipe vai entregar um produto que atende melhor as necessidades dos clientes, desenvolvido muito provavelmente com esforço otimizado pela própria equipe.
Claro, entregar o maior valor para o cliente é o principal para qualquer negócio, mas uma coisa que me chama atenção na estrutura do Scrum são os Sábios da Gestão Moderna que ele ajuda a fortalecer na cultura de trabalho da equipe.
O Scrum é bastante difundido em desenvolvimento de software, mas podemos pensar nele como uma estrutura para gerenciar qualquer processo.
Vou descrever o Scrum da forma mais simples possível, para que você possa entendê-lo mesmo que nunca tenha tido nenhum contato com esse framework anteriormente.
Sugiro a leitura deste material para quem:
Como você está lendo é sinal que possui interesse no assunto, então vamos lá.
Após a leitura deste texto, que procurei deixar bem completo, caso você queira se aprofundar ainda mais, minha sugestão seria você fazer como eu e acessar direto a fonte: Jeff Sutherland, um dos criadores do Scrum.
Todo o conteúdo abaixo é baseado nas experiências práticas que tive introduzindo e facilitando o Scrum nas equipes com que trabalhei, e também no conhecimento que adquiri com a leitura deste livro. Dessa forma acredito que esse texto que elaborei contém tudo o que você precisa para começar a trabalhar com Scrum, mas recomendo muito que você faça a leitura do livro Scrum - A Arte de fazer o dobro do trabalho na metade do tempo caso queira se aprofundar ainda mais.
O Scrum foi criado por Ken Schwaber e Jeff Sutherland há mais de 20 anos atrás, como uma alternativa mais rápida, confiável e eficiente de desenvolver software.
Nessa época praticamente todo projeto de desenvolvimento de software utilizava o formato cascata.
Chamamos de formato cascata quando o projeto é concluído em etapas distintas, passo a passo, até finalmente chegar na mão dos usuários ou clientes.
Esse tipo de processo normalmente resulta em grandes atrasos de planejamento, é lento, e muitas vezes resulta em um produto que as pessoas não querem ou não estão dispostas a pagar.
Por qual motivo fazemos planejamento gigantes? Por que tentamos prever todas as situações futuras possíveis para um projeto?
Talvez por que a ideia de ter todo o trabalho a ser feito em um novo projeto, esmiuçado com datas de início e fim, seja muito tentadora.
Mas infelizmente ela não funciona!
Esses planos caem por terra tão logo o projeto se depara com a realidade. Ou assim era, até surgir o Scrum.
O termo Scrum vem do esporte, do rúgbi mais precisamente, se referindo a maneira como um time se une para avançar a bola pelo campo.
Na essência, o Scrum se baseia em uma ideia simples.
O Scrum pode ser usado em qualquer tipo de projeto, desde fabricação de carros, gerenciamento de fast food, construção de foguetes, até mesmo na organização de um casamento.
Segundo Jeff Sutherland, ele criou o Scrum para ser uma estrutura onde fosse possível colocar os valores do Manifesto Ágil em prática.
Fiz abaixo uma imagem da estrutura básica do Scrum como exemplo, não se preocupe pois vou detalhar melhor tudo isso.
Posso dizer que o Scrum é totalmente voltado para equipes, na minha opinião somente isso já é uma coisa muito boa. Não gosto de abordagens onde a gestão se concentra apenas nos indivíduos, ainda mais quando a produção é um trabalho em equipe.
A ideia é que as equipes Scrum ideais possuam não mais do que 7 integrantes, podendo variar em no máximo 2 para menos ou 2 para mais.
O Scrum vai ajudar a formar equipes que sejam transcendentes, autônomas e multifuncionais.
Equipes que tenham uma noção de propósito que vai além do comum. Esse objetivo autoconcebido permite ultrapassar o básico e alcançar o extraordinário.
Quantas vezes você já teve que realizar um trabalho sem saber exatamente o motivo?
Equipes auto-organizadas, que se auto-gerenciam, podem decidir como executar o trabalho e tem o poder de fazer com que suas decisões sejam respeitadas.
Se você está pensando em fortalecer sua Cultura Organizacional, lembre-se que uma excelente equipe precisa poder decidir como concretizar as metas que foram estabelecidas.
Um dos conceitos chaves do Scrum é que os integrantes da equipe decidam sozinhos como irão trabalhar.
A responsabilidade da definição dos objetivos estratégicos fica a cargo da gerência, mas é incumbência da equipe decidir como atingir esses objetivos.
Outro ponto importante no Scrum é que a equipe tenha as competências necessárias para conseguir realizar todo o trabalho.
Em uma situação cascata podem existir várias equipes, uma responsável por cada parte do projeto. Nesse tipo de formato o projeto somente é entregue quando passar por todas as etapas realizadas por diferentes especialistas, mas nenhuma dessas equipes é capaz de finalizar o produto por conta própria.
No Scrum em vez de manter equipes separadas por especialistas que quase nunca trocam informações, existe uma equipe multifuncional que tem as habilidades necessárias para executar o trabalho de forma completa, do inicio ao fim.
As equipes Scrum costumam utilizar gestão visual para deixar claro o fluxo de suas atividades.
Veja no simples exemplo que fiz abaixo, onde o quadro Scrum possui três status para as tarefas: A Fazer, Fazendo e Feito.
A utilização do quadro permite que todos os integrantes da equipe possam ver exatamente quanto trabalho precisa ser feito na sprint, o status de cada atividade e quem está trabalhando nela. Isso gera uma transparência muito grande.
O backlog é onde ficam todas as atividades, ele pode conter centenas de itens ou apenas os próximos a serem trabalhados. Uma coisa muito importante, nem tudo que está no backlog será realmente realizado.
No Scrum existe um papel responsável por isso.
Uma das principais diferenças entre o Scrum e o Método Kanban é que enquanto o Método Kanban não altera os papéis já existentes na equipe, o Scrum trás com ele alguns papéis necessários.
O papel de Product Owner, como o próprio nome já diz é quem controla o backlog do produto. Ele decide o que entra no backlog, e como ele é priorizado, porém não atua como um gerente da equipe, na verdade ele é quem precisa estar disponível para a equipe.
O Product Owner deve conhecer a fundo a necessidade do cliente e deve servir como uma ponte entre o cliente e a equipe, passando feedback para a equipe a cada entrega de sprint.
O cliente nesse caso é quem irá receber o valor daquilo que é feito pela equipe.
O Product Owner precisa ser alguém que consiga se colocar no lugar de quem receberá o valor produzido.
Ele é quem deve saber qual é a visão do produto e deve trabalhar para ajudar a equipe a alcançá-la, estando sempre disponível, explicando o que precisa ser feito e por quê.
O Scrum Master é quem garante que o processo funcione.
Acho importante ressaltar que estamos falando de um líder aqui e não de um gerente com status superior a equipe.
Alguém para conduzir todas as reuniões, se certificar de que houve transparência e, o mais importante, ajudar a equipe a descobrir o que está atrapalhando o andamento do trabalho.
É tarefa do Scrum Master guiar a equipe em direção ao aperfeiçoamento contínuo, perguntar regularmente:
Como podemos fazer melhor aquilo que fazemos?
Um dos maiores erros que podemos cometer em um projeto é desenvolvê-lo sem receber feedback sobre o que estamos fazendo. Quanto mais tempo ficamos sem saber se estamos no caminho certo, maior será o tempo desperdiçado.
Todos nós já ouvimos histórias de projetos que iniciaram seu desenvolvimento como sendo uma excelente ideia, mas quando finalizados não eram mais necessários.
Eles existem aos montes!
O tempo passa, as coisas mudam, o contexto muda, as necessidades mudam, aquilo que o cliente antes tinha certeza, já não tem mais.
Eu posso dizer que feedback constante não é aconselhável, é uma necessidade. Quanto mais cedo você receber feedback sobre o trabalho, mais rápido você pode saber se o que você está fazendo vai ser útil para alguém.
Sprint é a forma com que o Scrum aborda isso.
Segundo um dos criadores, Jeff Sutherland, foi batizado de Sprint para remeter a intensidade. A ideia é trabalhar a todo o vapor durante um curto período de tempo e então parar para verificar em que ponto se encontra.
As sprints precisam ter uma duração definida, não se faz uma sprint com duração de uma semana e depois uma com três semanas. É preciso ser coerente. O ritmo de trabalho é essencial, para que com o tempo, as pessoas descubram quanto conseguem fazer nesse tempo e busquem melhorar.
Uma das coisas que o Scrum coloca como crucial é que após a equipe se comprometer com aquilo que será feito durante o sprint, nada mais pode ser acrescentado por alguém de fora da equipe.
A comunicação diária de uma equipe Scrum é muito importante, ela deve ocorrer a todo momento, porém existe um momento onde isso é feito de forma oficial no Scrum.
Existem algumas boas práticas para a cerimônia diária, ou “Daily Scrum” , como por exemplo, todos os integrantes do time devem estar presentes.
Para que seja possível estabelecer um ritmo regular para a equipe, é importante que independente da hora selecionada, a cerimônia diária ocorra sempre no mesmo horário. Outra coisa importante, essa reunião não deve ser demorada, o tempo ideal de duração tem que ser no máximo de uns 15 minutos.
O Scrum coloca como importante que essa reunião seja feita em pé justamente por isso. É uma forma de evitar divagações e conversas desnecessárias.
Para incentivar que todos participem da conversa, a ideia é que cada integrante da equipe responda 3 perguntas:
Um dos problemas mais comuns, e que por experiência já vi acontecer, é quando a equipe trata essas perguntas como um relatório individual.
Fiz isso, vou fazer aquilo, próximo..
Esse problema é muito comum de ocorrer, a passividade ou comportamento preguiçoso de integrantes da equipe pode atrapalhar o desempenho do resto do grupo. Dessa forma é preciso estar atento para identificar e eliminar esses comportamentos.
Essa reunião serve para a equipe debater rapidamente como alcançar o objetivo. É preciso sair dela sabendo quais são as coisas mais importantes a serem realizadas naquele dia de trabalho.
É preciso interagir, se uma pessoa fala que determinada tarefa levará o dia, outra pode saber como fazê-la em menos tempo. Se alguém tem um problema, outros podem saber como ajudar.
A equipe precisa ter a vontade de querer ser excelente!
Essa é uma reunião estratégica, um comportamento robótico ou apenas de prestação de contas não acrescenta em nada aos objetivos da reunião.
Se você já tentou estimar quanto tempo uma atividade vai levar já sabe que nós, os seres humanos, não somos bons nisso. Mas somos bons em fazer comparações, comparar um tamanho com outro, por exemplo. Quando você olha uma camiseta tamanho M e uma tamanho G você consegue dizer a diferença.
O Scrum sabendo disso nos apresenta uma forma que pode ser muito mais útil de se estimar uma atividade sem a necessidade de ser 100% exato. Isso é feito utilizando a sequência de Fibonacci, quando usamos a sequência de Fibonacci para comparar quanto tempo vamos levar para terminar uma tarefa, isso nos permite não ser 100% exatos.
Não precisamos saber a diferença de um 5 para um 6, seria muito pequena para identificarmos, mas temos ideia se uma tarefa é um 5 ou um 8 por exemplo, comparando com outras que já fizemos.
Usando esses números podemos obter a opinião de todos os integrantes da equipe sobre o tamanho de uma atividade usando aproximadamente a mesma escala de medida.
Como saber se minha atividade é um 3 ou um 8? E se não houver consenso? E se alguém estimar errado?
O Scrum nos ajuda na árdua tarefa de estimar utilizando uma prática muito criativa chamada de pôquer do planejamento (planning poker).
A ideia é simples, cada integrante do time utiliza um baralho de cartas contendo os números da Sequência de Fibonacci: 1, 2, 3, 5, 8, 13 etc. Veja no exemplo acima que utilizei números redondos a partir do 13 apenas para facilitar.
Caso tenha interesse faça o download do arquivo contendo as cartas para impressão do Baralho para Planning Poker Scrum ao final desta página.
Uma tarefa é avaliada por vez, cada integrante do grupo separa a carta que considera corresponder a tarefa e coloca virada para baixo na mesa. Na sequência todos devem mostrar a sua carta selecionada ao mesmo tempo, isso evita que alguém seja influenciado pela escolha do outro.
É importante lembrar que nesse momento não devemos estimar em horas, já falamos como nós seres humanos não conseguimos fazer isso com precisão. Estamos utilizando pontos para comparar as coisas de modo relativo, da mesma forma que fazemos quando estamos comparando dois tamanhos de camiseta por exemplo.
Outro ponto importante é que toda a equipe participa, compartilhando conhecimento e opinião. É essencial que a estimativa seja feita por quem irá realizar o trabalho e não por uma pessoa considerada “ideal”.
Ao final da sprint saberemos quantos pontos a equipe fez, isso vai servir de base para a próxima. Não precisamos saber quantas horas uma atividade vai levar.
Quando as cartas selecionadas pelos integrantes forem muito distantes uma das outras, quem selecionou a mais alta e a mais baixa deve explicar seu raciocínio para os demais. Dessa forma é realizada outra rodada.
Quando as cartas selecionadas são próximas em até 2 números (3, 5 e 8 por exemplo), a equipe pode somar e fazer a média para ter o resultado.
Tratar estimativa dessa forma deixa claro que se trata apenas disso, uma estimativa e não um cronograma detalhado que não condiz com a realidade.
No Scrum tratamos os itens de trabalho como histórias.
Quando estamos fazendo um trabalho, nem todos da equipe possuem o mesmo conhecimento sobre o motivo de cada atividade ser realizada. Muitas vezes não estamos envolvidos com tudo de forma a saber qual é o resultado desejado.
Quantas vezes em seu trabalho você já teve que fazer tarefas e não sabia o motivo? Aposto que algumas.
Dessa forma é preciso deixar claro todas as informações necessárias para que o trabalho seja realizado. O Scrum faz isso através de narrativas chamadas histórias.
Já ficou provado que as pessoas tem muita facilidade em entender o que precisa ser feito quando conseguem compreender intimamente as motivações, desejos e personagens envolvidos.
Para que possamos estimar com mais facilidade é essencial que o escopo das histórias seja o menor possível.
Um exemplo errado de história seria o seguinte:
Como líder, quero uma empresa onde todos amem trabalhar, para criarmos as coisas mais incríveis possíveis.
Essa narrativa sem dúvida resume muito bem o propósito da Amo Onde Trabalho, mas é uma narrativa com escopo muito grande, não saberíamos por onde começar.
Abaixo um exemplo mais correto.
Repare que essas atividades possuem o escopo em um tamanho ideal para que a equipe execute como achar melhor.
É possível debater sobre elas, não dizem Como fazer, mas podemos colocá-las em prática.
Também é comum adicionarmos critérios de aceitação no verso do cartão, para sabermos se estamos entregando o valor necessário, veja um exemplo a seguir.
Como líder, quero uma empresa onde todos amem trabalhar, para que possamos criar as coisas mais incríveis possíveis.
Essa narrativa anterior com escopo muito grande poderia ser o conjunto de histórias, que quando reunidas, poderiam se tornar a ideia de uma empresa com uma cultura organizacional excelente.
Chamamos isso de Épico.
Essa é a reunião onde fazemos o planejamento, dessa forma ela ocorre uma vez por sprint.
Durante a reunião de planejamento de sprint, o Product Owner descreve os recursos de maior prioridade para a equipe utilizando as histórias.
A equipe toda tem então a oportunidade de fazer perguntas suficientes para transformar uma história de usuário de alto nível, que está no backlog do produto, em tarefas mais detalhadas que vão entrar na sprint.
A equipe precisa sair dessa reunião com dois artefatos definidos:
Todos precisam saber qual o objetivo, e facilita também na hora de reportar aquilo que está sendo feito para quem está fora da sprint. Outros interessados não precisam ouvir detalhes sobre cada item do backlog do produto (história do usuário).
Já o backlog da sprint é uma lista dos itens de backlog do produto que a equipe se compromete a fazer durante a sprint.
Um ponto importante que reforço aqui, a equipe é quem seleciona quanto trabalho eles podem fazer, isso não é determinado pelo Product Owner.
Vamos considerar que nossa sprint tenha uma semana de duração.
Quando ela for finalizada iremos saber quantos pontos o time conseguiu fazer, isso nos dá uma ideia de qual é a velocidade do time.
A partir daí podemos trabalhar para otimizar e chegar na velocidade desejada no decorrer de outras sprints, coletando feedback e fazendo ajustes.
A equipe pode fazer isso na reunião de retrospectiva da sprint com apoio do Scrum Master.
Ao final de cada sprint a equipe faz uma reunião chamada de Revisão da Sprint. É o momento para o time mostrar o que foi feito durante a sprint e avaliar se os objetivos foram atingidos.
O legal dessa reunião é que além da participação do Product Owner, do time e do Scrum Master, é possível que outros interessados participem também. Como por exemplo a gestão da empresa, clientes e integrantes de outros times e projetos.
Lembre-se de que não é necessário que a equipe tenha completado cada um dos itens trazidos para fazer parte da Sprint.
O importante mesmo é que a equipe tenha atingido o objetivo geral definido para a sprint.
Uma parte importante do Scrum é a melhoria contínua.
Qual a pequena mudança que podemos fazer nesse momento que trará uma melhoria para a próxima sprint?
Ao final de uma sprint já temos uma imagem de como as coisas foram, o que funcionou, o que não deu certo, onde podemos fazer alguma melhoria.
O foco da reunião de retrospectiva deve ser o que podemos melhorar no processo, não é o foco fazer reclamações ou apontar culpados. Acredite, já vi isso se tornar comum em equipes que trabalhei quando o ambiente não tinha a confiança necessária.
Problemas podem ser discutidos desde que o foco seja a equipe e não o indivíduo. É importante que todos tenham a oportunidade de dar sua opinião sobre um possível problema.
Outra coisa que vi acontecer bastante é a equipe levantar vários problemas ocorridos e não traçar ações para corrigir os problemas na próxima sprint. Nesses casos, com o tempo, a reunião acaba virando apenas um momento para lamentações, dessa forma é necessário que o Scrum Master fique atento a isso.
Essa é a pessoa que tem a visão daquilo que a equipe irá desenvolver.
Ele precisa entender os riscos e também qual o maior valor a ser entregue, precisa ter a paixão pela visão daquilo que se busca.
Quem serão as pessoas que vão realizar o trabalho.
Uma coisa importante que já mencionei antes, a equipe selecionada precisa ter todas as habilidades necessárias para poder realizar a visão que o Product Owner possui.
Times de 5 a 7 pessoas são o ideal, mas não é uma regra, você pode tentar com menos ou mais pessoas.
Essa pessoa vai precisar saber bem como funciona a estrutura do Scrum, pois será ela que irá treinar os demais.
Também deverá ajudar a eliminar obstáculos e facilitar as cerimônias durante o dia a dia de trabalho.
Será necessário ter uma lista daquilo que é necessário fazer para que a visão do Product Owner se torne realidade.
Esse backlog deve ser atualizado durante todo o tempo. É muito importante que ele sempre esteja ordenado de acordo com as prioridades do Product Owner.
O Product Owner deverá definir e tomar decisões sobre como realizar a priorização dos itens do backlog.
Essa atividade precisa ser realizada pelas pessoas que de fato irão trabalhar nos itens.
É a equipe também que deverá identificar se algum item solicitado pelo Product Owner não pode ser realizado por algum motivo.
É importante que todos da equipem tenham a mesma definição daquilo que é considerado feito.
Quais são os critérios de aceitação? A tarefa está entregando o valor que se propõe?
Não estime em horas, será muito difícil ser assertivo. Utilize o Planning Poker para ter um tamanho relativo para cada tarefa.
O planejamento é a primeira cerimônia do Scrum. Todos precisam participar, a equipe, o Scrum Master e o Product Owner.
Vimos antes que a Sprint precisa ter uma duração determinada, e é importante que ela seja sempre a mesma. Dessa forma é possível acompanhar a velocidade da equipe. Minha sugestão é que a Sprint tenha de 1 a 2 semanas de duração no máximo, mas novamente, não é uma regra.
Na hora de incluir histórias na sprint a equipe precisa ter uma ideia de quantos pontos é possível fazer no decorrer do período da sprint. Conforme sprints forem sendo feitas existirá um histórico para usar como base.
A sprint precisa ter uma meta! Todos da equipe precisam saber como os itens da sprint irão contribuir para a visão do produto se tornar real.
É necessário tornar o trabalho visível para todos, a melhor forma de fazer isso é utilizando um quadro, que podemos chamar de quadro Scrum.
No Scrum utilizamos apenas 3 colunas para o fluxo do trabalho: A Fazer, Fazendo e Feito.
Também é comum uma coluna para o backlog, conforme no exemplo que mostrei anteriormente.
Os post-its irão servir para representar os itens de trabalho.
A cerimônia diária, que deve ocorrer sempre no mesmo horário, será o lugar para deixar toda a equipe ficar por dentro do que está sendo feito. Isso é feito com todos participando e informando a equipe.
Essa cerimônia deve durar no máximo 15 minutos, todos em pé ajuda na hora de ser objetivo.
Evite comportamentos robóticos, imagine essa reunião como o intervalo de um jogo de futebol, onde a equipe tem 15 minutos para melhorar sua estratégia para o jogo.
A Revisão da Sprint é o momento para que a equipe apresente aquilo que foi realizado durante a sprint.
Todos podem participar, inclusive interessados que não façam parte do time, como os próprios clientes e gestão da empresa.
Importante: se algum item de trabalho não atendeu aos critérios de feito, não está concluído, deve ficar fora da apresentação.
Utilize as Retrospectivas da Sprint para pensar no que deu certo, no que deu errado e principalmente, o que pode melhorar para as próximas sprints.
Não é o momento de apontar culpados, sempre pense no que pode ser feito para melhorar o resultado do time como um todo.
No final da retrospectiva o Scrum Master e o time devem ter chego a um acordo sobre qual é a melhoria a ser realizada durante o próximo ciclo.
A utilização do Scrum fornece a equipe a possibilidade de escolher a forma como deseja trabalhar para atingir o objetivo proposto para a sprint. A própria equipe se compromete com o trabalho a ser realizado no início de cada sprint, não existe necessidade de realizar microgerenciamentos pois todas as informações sobre o andamento das atividades estão visíveis a todo o momento no Quadro Scrum. A própria equipe é quem realiza as checagens e tratamento de problemas relacionados ao trabalho.
Como mencionei antes, o Scrum é totalmente voltado para equipes, dessa forma a Colaboração é essencial. Não gosto de abordagens onde a gestão se concentra apenas nos indivíduos, ainda mais quando a produção é um trabalho em equipe. Utilizando o Scrum a Colaboração será reforçada diariamente na cultura da sua equipe.
Uma das principais vantagens por trás da gestão visual é a Transparência, e o Scrum fornece isso através do seu quadro. Outro ponto importante é a Transparência que o Scrum fornece a todos os interessados no trabalho que está sendo feito, suas cerimônias consistem em trazer transparência durante todas as etapas, inclusive para o próprios clientes.
A equipe vai se sentir empoderada pois ela vai participar de todo o processo ativamente, dando sua opinião, ajudando a estimar e resolvendo problemas. O comprometimento com as atividades que serão desenvolvidas é realizado no começo da sprint e a própria equipe se coordena para escolher a melhor forma de realizar o trabalho.
Toda a sprint deve ter um objetivo, uma meta, um propósito. Esse objetivo deve ficar visível durante o trabalho, tornando claro para todos onde as atividades que estão sendo realizadas durante a sprint estão impactando nos objetivos maiores da equipe. Isso é muito importante para que as pessoas não se tornem apenas executoras de atividades.
Você pode fazer o download das cartas para o Planning Poker Scrum ao final da página.
Como descrevi anteriormente, o Scrum teve origem no mundo de desenvolvimento de software, porém hoje ele é utilizado em uma infinidade de outros ambientes de trabalho.
O Scrum pode trazer resultados importantes ao seu trabalho, ajudando a equipe a entregar maior valor aos seus clientes, otimizando o time para que consiga entregar o trabalho mais rapidamente.
Mas não esqueça que além do resultado para o cliente, o Scrum também estará reforçando comportamentos diariamente, e são esses comportamentos que formam a cultura do seu time ou empresa.
Empoderamento, Propósito, Transparência, Confiança, Colaboração.
Espero que tenha gostado das dicas e também da leitura.
Um grande abraço e até a próxima!
